chompi / openrtb2x Goto Github PK

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=3

Original author: [email protected] (July 22, 2011 21:18:12)

In the OpenRTB Mobile specification, the site and app objects had attribute “keywords”. In this spec, that attribute has been removed and added to the “content” object of which there is 1 per site or app object. It was also renamed to “keyword” unless that’s a typo (a similar attribute in the “user” object is correctly still called “keywords”). This creates an unnecessary point of backward incompatibility. Please restore the “keywords” attribute to the “site” and “app” objects. If someone feels strongly about also having it in “content”, I would not object although it seems redundant.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=27

Original author: [email protected] (March 02, 2011 18:09:59)

This issue is to serve as a reference point for the publisher-centric API addition proposal.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=4

Original author: [email protected] (July 22, 2011 21:31:59)

Referring to the reference data for Ad Position (Section 6.4) and No-Bid Reason (Section 6.6), each has a value 0 that means “unknown”. However, a broad concept throughout OpenRTB attributes, other than block or white lists, is that an omitted optional attribute means “unknown”. For this reason, other attributes do not have an explicit value to mean “unknown”. For consistency, these should be removed as well.

The 0 = unknown value existed in the OpenRTB Mobile specification for No-Bid reason, but since an exchange would likely also interpret an undefined value as “unknown”, this should not cause a backward compatibility issue.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=35

Original author: [email protected] (March 21, 2011 16:21:42)

1. Do you have plans to add user matching in the spec? If so, when
   could we expect to see a draft of it?
2. Have you considered custom data? By that I mean if the buyer wants
   to add cookie-like data to be added in the user matching step or in
   the response of a bid, and then expect it to be available in the next
   bid request originating from the same user.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=6

Original author: [email protected] (May 18, 2011 23:00:15)

• standardize real-time bidding calls
• incorporate Mobile, Video, Display
• provide an extensible spec for wire-level messages

Original issue: http://code.google.com/p/openrtb/issues/detail?id=11

Original author: [email protected] (August 02, 2011 14:39:31)

Background/Problem Description:
Publishers might not pass along lat/lng, and DSP wants to target at hyperlocal(true lat/lng) instead of reversed lookup by zip, or city.

Proposed Solution:
optional field "type" that specify what type of location geo object truly comes from

Original issue: http://code.google.com/p/openrtb/issues/detail?id=38

Original author: [email protected] (May 19, 2011 22:05:10)

Background/Problem Description:
There are issues with different JSON implementations
ordering elements differently
Proposed Solution:
Drop md5 signature; authentication should be done at HTTP level

Original issue: http://code.google.com/p/openrtb/issues/detail?id=12

Original author: [email protected] (July 22, 2011 21:57:00)

The latitude in the geo object indicates -180 to 180. It should be -90 to 90.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=36

Original author: [email protected] (July 22, 2011 21:06:22)

The OpenRTB Mobile specification included an optional “restrictions” object that carried two optional blocklists (i.e., string arrays): “bcat” for blocked content categories for which values would be from Section 6.1 of the 2.0 draft, and “badv” for blocked advertiser domains. I understanding that the OpenRTB preferred means of communicating such restrictions is a non-RT API and this it is in our near term roadmap to support this in our exchange. However, not all exchanges and not all bidders will prioritize building support for those APIs. Our experience and that of several bidders who are buying from us is that it is easier to get started with the restrictions in the bid request albeit less efficient from a bandwidth perspective.

We have built into our exchange the ability to include/exclude these restrictions on a bidder by bidder basis. This way, when we complete our non-RT sync APIs, bidders will have the choice of how to receive restrictions. Furthermore, we want to reserve the right to suppress restrictions from the bid request only after we’re satisfied that a given bidder is properly using the non-RT sync. We can’t necessarily force a bidder to act on restrictions however they are sent, but we need to represent to our publishers that we as their SSP are doing what we can.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=20

Original author: [email protected] (July 20, 2011 08:09:22)

Hi, looking at the new 2.0RC spec, I have a proposal to include the language from the user's browser in the bid request. This could be different from the user's location, and could be good to target ads in the user's own language, and not the language of country the user happens to be in.

Patrik
Admeta

Original issue: http://code.google.com/p/openrtb/issues/detail?id=18

Original author: [email protected] (July 22, 2011 21:30:35)

Referring to the reference data for Content Categories (Section 6.1), the tier-1 IAB values have been changed from the OpenRTB Mobile specification unnecessarily. The 2.0 draft adds tier-2 codes which is great. However, in the OpenRTB Mobile specification, IAB-24 was “Uncategorized” which is noted in the IAB reference in sequence as the 24th tier-1 category and it has IAB-25 and IAB-26 as “Non-Standard Content” and “Illegal Content”, respectively. The 2.0 draft not only eliminates “Uncategorized”, but renumbers the latter two as IAB-24 and IAB-25.

The tier-2 codes under IAB-1 through IAB-23 are fine, but the aforementioned OpenRTB Mobile definitions of IAB-24, IAB-25, and IAB-26 should be restored to avoid a needless point of backward incompatibility.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=34

Original author: [email protected] (April 26, 2011 05:17:50)

I'd like to suggest the addition of a list of allowed currencies
in the offline synchonization. The list could be sorted so that the preferred currency is at the top of the list.

Today the bidder can specify any currency in the bid, and it would help if the exchange could specify which currencies it allows the bidder to use instead of just rejecting the bid due to an unsupported currency.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=7

Original author: [email protected] (March 21, 2011 12:45:26)

When a DSP queries the SSP whether an advertiser is in any publisher's block list, it would be convenient if a status code is returned if the advertiser is blocked.

The main reason for this is:

• The publisher may want to manually verify the advertiser and thus respond with a "pending verification" to indicate that the DSP should check again once the verification has taken place (by polling as described in the documentation.)

A second reason may be to indicate that the advertiser is permanently blocked by a publisher. A possible scenario when an advertiser is not permanently blocked might be if all premium advertising space is bought by some company and competing brand advertisers may not be accepted on the site while this campaign is running.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=5

Original author: [email protected] (May 17, 2011 12:20:09)

Background/Problem Description:
On line no. 70 and 98 in Class Signable , we are Hex encoding shared secret like:
Hex.encodeHex(sharedSecret)

I want to propose a change that would change this call to :
Hex.encodeHex(sharedSecret, true)

Please refer Java docs for this method :
http://commons.apache.org/codec/apidocs/org/apache/commons/codec/binary/Hex.html#encodeHex(byte[])

The change is suggested to use all lower case letters (or may be upper case) while encoding in hex to make encoding consistent.We are generating token using the same hex encoded shared secret. As the algorithm used to generate token is MD5, case sensitivity of source string matters.

This would be a breaking change for those who use opposite kind of letter case.
Please let me know your suggestions about this change.

Thanks,
Vaibhav Kamble

Original issue: http://code.google.com/p/openrtb/issues/detail?id=10

Original author: [email protected] (February 15, 2011 21:32:54)

Background/Problem Description:

Proposed Solution:

Implementation Notes:

Original issue: http://code.google.com/p/openrtb/issues/detail?id=1

Original author: [email protected] (April 20, 2012 13:45:54)

On page 19 of OpenRTB 2 RELEASE, the wording, "If blank or 0, extension is not allowed," suggests that the JSON could be formatted something like {"maxextended":}, which is invalid. Instead, it should probably read, "If null or 0..."

Jeff

Original issue: http://code.google.com/p/openrtb/issues/detail?id=43

Original author: [email protected] (July 22, 2011 21:25:15)

There have been recent developments in how device IDs are produced and consumed with respect to how they are hashed. In the OpenRTB Mobile specification, we considered SHA1 and MD5 had a strong consensus for SHA1. Over recent months, however, there seems to be broad interest in both. Google for example announced that they are going with MD5, but neither seems to be fading.

Therefore, I suggest we support passing both for each of the two flavors of device IDs currently supported (i.e., true device equipment ID such as IMEI; platform ID such as UDID for iOS or Android ID). My proposed names are: “didmd5” (device ID using MD5), “didsha1” (device ID using SHA1), “dpidmd5” (device platform ID using MD5), and “dpidsha1” (device platform ID using SHA1).

Original issue: http://code.google.com/p/openrtb/issues/detail?id=29

Original author: [email protected] (July 22, 2011 21:05:11)

The version attribute should be removed from the bid request. As it is, by the bidder has read that version attribute, the it will need to have already bound or otherwise interpreted the top level bid request object. This makes its usefulness problematic or at best limited, especially if considering binary formats.

I suggest moving it to an HTTP header called “x-openrtb-version”. Together with the “content-type” header, the bidder now has full information on exactly what specification and format it needs to crack open from the POST body.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=19

Original author: [email protected] (July 22, 2011 21:29:41)

The bid array (Section 4.3.2) is specified as required as is its parent. This makes sense, since a no bid can be expressed as a completely empty bid response. Our experience in integrating bidders to our OpenRTB Mobile compliant exchange, however, is that some send empty responses, some send an empty seatbid array or no seatbid array, some send seatbid objects without bid objects. We found that it is acceptable simply to interpret the absence of any of these essentials as a valid no-bid. There’s really nothing else for the exchange to do; if it doesn’t have the essentials for a bid, then it’s a no bid.

Based on this, the bid and seatbid arrays are not technically required since the bidder is not required to make a bid. I would update the spec to reflect this, but I would also recommend adding a “Best Practice” statement indicating that the preferred means of expressing a no-bid is the bandwidth friendly empty response.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=33

Original author: [email protected] (November 08, 2011 11:42:24)

Field in Device object: "didsmd5" should be named "didmd5", since other field names are: "didsha1, dpidsha1, dpidmd5"

Device object: "language" should be List of strings and not string, since browser in many countrys sends more than 1 language. As we proposed in one of previous examples (switzerland normaly has 3 official languages, and many users use 2 as their defaults in browsers)

Table 6.15 location type: - we propose to add new value 4: IP adress anonymized. Reason: In europe many countries have decided that IP adress is personal data. Therefore exchange must use and send data based on partial IP adress (normally in IPv4 last 2 bytes are replaced with zero eg.: 123.123.123.123 to 123.123.0.0. Same policy is also applied in one of the biggest adexchanges.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=40

Original author: [email protected] (April 20, 2012 13:51:19)

Currently there is no easy way to determine what the audience's local time is. A GMT Offset or Local Time field could be a great enhancement to the OpenRTB spec. GMT offset would be preferred, since it could be an integer field that give the difference in minutes between GMT and the audience's local time. Minutes is preferable to hours, since some time zones differ from GMT by not whole numbers of hours.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=44

Original author: [email protected] (July 22, 2011 21:07:34)

In the bid request object, the bidfloor value can be qualified by bidfloorcurrency. First, to be consistent with the bid object which expresses bid currency as “cur”, this long name could be shortened to bidfloorcur. As an aside, I think the term floor in the context of RTB would be no less clear as bidfloor. Thus, these could be called floor and floorcur.

But my real question with bidfloor is that unlike the bid price, bidfloor it cannot be qualified by units; it seems to be CPM only. For consistency, we should add bidfloorunits (or floorunits if we use the short names), which would follow the values of Price Units (Section 6.5), which defaults to CPM.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=21

Original author: [email protected] (July 22, 2011 21:12:31)

are several attribute and object names that have been altered from the OpenRTB Mobile specification for seemingly stylistic preferences. However, this creates needless points of backward incompatibility for exchanges and bidders that are presently operating. A couple instances of this have been referenced in other issues where it seemed more appropriate to mention them there. Here are the rest; please restore them:

• “site.sitecat” should be restored to “site.cat”.
• “app.appcat” should be restored to “app.cat”.
• “user.gen” should be restored to “user.gender”, and restore the “O” value option.
• “bidset” object should be restored to “seatbid”.
• “bid.id” should be restored to “bid.impid”.
• “bid.campaignid” should be restored to “bid.cid”.
• “bid.creativeid” should be restored to “bid.crid”.

On the app and site category, I know there are other levels of category usage proposed for site and app, but it is sufficiently clear that an unqualified “cat” pertains to the scope of its object (e.g., site or app as opposed to page, etc.). I noticed that object IDs have all been changed to a similar unqualified style from the previous spec, which I do support (even though it’s backward incompatible).

On the gender values, the allowed values were also changed in an unnecessary way. Aside from “M” and “F”, the OpenRTB Mobile specification had “O” for “other” which is a useful classification. The 2.0 spec dropped it and added “U” for “unknown” which is redundant with respect to not passing the attribute.

On the ID in the bid object, in all other objects that have an “id” attribute, this ID pertains to the object itself. In this case, however, the ID is referring to the ID of a different object; an “imp” object. It would not only improve backward compatibility to restore it to “impid”, but it would be a lot less confusing.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=24

Original author: [email protected] (July 04, 2011 09:44:12)

Really great job done on the spec! It's looking really good, however I have a few comments.

There is no user matching process defined as proposed in issue #6.

The idea of a version attribute in Bid Request is great, however what is the formatting of it? Is 2.0, 2.0RC1, 2.0.0, 2.0.1, etc all valid and will only be matched as a string or do we have a more strict form? I'd suggest only numerical two parts format: Major.Minor as described in the beginning of the spec.

Device Object, make clear it is used for browsers in computers as well. Currently the text states "...to the mobile device including..."

Admeta is currently in the process of adding Text Ads capabilities to our RTB offering. We will submit a proposal for addition to a future spec when we are finished with it.

There is no notion of Loss Notification. A detailed notification of every lost bid is probably overkill, but notifications when for example a bidder's advertiser is rejected or not yet approved by the publisher would be really good and will benefit both bidder and exchange. We are in the process of adding such notifications and will submit our solution as a proposal when it is finished.

There is no bid currency handling as proposed in issue #7.

The inclusion of user data objects is really good. However the format of it is very verbose. The purpose for the bidder of such data is to be able to store cookie like data at the exchange, and will hence be sent every request and response, which leads to the fact that the user data is missing in Bid Response altogether.

We propose a more lightweight version of Custom User Data
"cud":
{
"string":"string",
...
}

for example:
"cud":
{
"age":"32",
"gender":"female"
}

Paragraph 4.3.1 has a Copy/Paste error from Bid Request

Paragraph 4.3.2 references a "seatbid" object, which is now renamed to bidset.

Patrik Oscarsson
Admeta

Original issue: http://code.google.com/p/openrtb/issues/detail?id=14

Original author: [email protected] (May 08, 2011 13:20:34)

What steps will reproduce the problem?

1. Clone code on Windows XP or Windows 7 (I've tested on both)
2. mvn package

What is the expected output? What do you see instead?

The error message is:

Test set: org.openrtb.common.json.AbstractJsonTranslatorTest

Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec <<< FAILURE!
verifyPrettyPrinter(org.openrtb.common.json.AbstractJsonTranslatorTest) Time elapsed: 0 sec <<< FAILURE!
org.junit.ComparisonFailure: pretty printer didn't return the expected results expected:<{[
"object" : {
"value" : "subtype-value"
},
"long" : 1234,
"string" : "parent-value"]
}> but was:<{[
"object" : {
"value" : "subtype-value"
},
"long" : 1234,
"string" : "parent-value"
]
}>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.openrtb.common.json.AbstractJsonTranslatorTest.verifyPrettyPrinter(AbstractJsonTranslatorTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

What version of the product are you using? On what operating system?
I have the tip (version 110) checked out on Windows XP and Windows 7

Please provide any additional information below.
The reason I think this is a Windows issue is that it works fine on my CentOS box (5.5). The other clue is that on my CentOS box the default encoding is UTF-8
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
...whereas on windows its Cp1252
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,i.e. build is platform dependent!

The offending code:
public void verifyPrettyPrinter() throws IOException {
test.usePrettyPrinter();
assertEquals("pretty printer didn't return the expected results", PRETTY_VALUE, test.toJSON(PARENT));

I've attached the logs

Original issue: http://code.google.com/p/openrtb/issues/detail?id=8

Original author: [email protected] (July 22, 2011 21:28:36)

There should not be a separate mechanism for retrieving VAST markup. The auction conversation between exchange and bidder should not vary by ad unit. I’m not sure if the intent is to call both the win notice and then the VAST URL or just the VAST URL, but either way the VAST URL should be eliminated and returned on the win notice URL; in the case of a VAST video, this is essentially the served ad markup. The seller and/or SSP are quite capable of detecting whether the response markup is XHTML or VAST XML and will be expecting to make that determination based on the fact that it allowed VAST video in the bid request.

To amplify the point, when serving the ad in the bid itself (Section 4.4.1), the spec allows the VAST XML to be returned in the “adm” parameter just like XHTML. The seller and/or SSP will have to make exactly the same determination in that case. There is no reason for the win notice URL to be any different.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=32

Original author: [email protected] (July 22, 2011 21:17:07)

The “site” and “app” objects have content category attributes. Except for their changed names (which I called out in a separate issue), this is consistent with the OpenRTB Mobile specification. In this spec, there are additional levels of content category arrays at the section, page, content, publisher, and producer levels; that's 6 levels of content categories. I have no objection to these additional levels, but are they really necessary? They seem like overkill and also pretty unrealistic in terms of actually getting them.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=26

Original author: [email protected] (May 17, 2011 10:34:00)

In the 1.9c draft spec there is the IP address attribute in the device object. But it is only specified as 15 chars long, which is fine for IPv4, but it should be extended to utilize IPv6 as well, which is 39 characters. Perhaps it make sense to have two different fields?

Patrik

Original issue: http://code.google.com/p/openrtb/issues/detail?id=9

Original author: [email protected] (June 30, 2011 23:16:41)

Hello,

I've posted openrtb 2.0RC1 in the downloads area. please download and give feedback by July 11th, 2011

http://code.google.com/p/openrtb/downloads/detail?name=Open&#37;20RTB&#37;202.0RC1.pdf&can=2&q=

Original issue: http://code.google.com/p/openrtb/issues/detail?id=13

Original author: [email protected] (July 22, 2011 21:15:44)

I don’t have a serious object to this, but how is the “privacypolicy” in “site” and “app” objects actionable? I would venture a guess that most sites have privacy policies of one kind or another and that they vary broadly. What will a bidder do with this boolean? If "not much", it should be removed.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=25

Original author: [email protected] (July 08, 2011 14:31:25)

Hi guys,

i'm referring to Open RTB 2.0RC1.pdf, from June 30, 2011, Pages 38+39 (5.1.4 Example 4 - Video)

imp->video->companionad is an array of banner objects, but it contains two hashes with the same index.

I think the "banner: " should be removed from the example.

Regards,

Torben Brodt

Original issue: http://code.google.com/p/openrtb/issues/detail?id=16

Original author: [email protected] (July 22, 2011 21:08:38)

In the OpenRTB Mobile specification, we followed an informal convention of prepending “b” or “w” to attribute names to indicate that they are block lists or white lists, respectively, (i.e., restrictions rather than just informative data). For the most part, those names are carried over into this spec. However, there are several new block or white list attributes in this spec and I recommend that they follow the same convention.

The ones that jump out at me are as follows with the proposed names in parentheses: banner.atype (wtype), banner.expandable (wexpandable or perhaps just wexpand), banner.format (wformat), video.format (wformat), video.playbackmethod (wplaybackmethod), and video.delivery (wdelivery).

Original issue: http://code.google.com/p/openrtb/issues/detail?id=22

Original author: [email protected] (February 08, 2012 15:44:42)

Background/Problem Description:

Certain browsers have 3rd party cookie support disabled by default. Namely Safari 5.1. This can cause major issues for DSPs and affects things such as frequency capping (as there is no way to fully single out the user). Typically, we have witnessed that for each auction request generated by these browsers that a brand new SSP userid is generated each time.

Proposed Solution:

Browser facing SSPs should be evaluating whether or not 3rd party cookies are enabled and should be passed this through on the auction request. There are many ways of determining whether 3rd party cookie support is supported - namely by watching for cookie persistence or by a two-pass redirect mechanism when no domain cookies are detected (on SSP ends).

Original issue: http://code.google.com/p/openrtb/issues/detail?id=42

Original author: [email protected] (July 22, 2011 21:58:34)

Attribute Name References: Need to do a full review of text descriptions especially where attribute names are referenced. Some of these refer to names that subsequently have been changed.

Object Descriptions Unclear: Some of the object description paragraphs are rather unclear. For example, it took me awhile to figure out if the video object was implying that “I want a video ad and these parameters describe what I want” versus “I am video content, these parameters describe me, and I want a video ad to be stitched into me”. The Data object is another example where a couple clarifying examples would help.

Segment Object Value Description: The description of segment.value should probably be clarified. While this is data that may have originated by a third party, it is still essentially data that the exchange is presenting to all bidders on a given auction. Therefore when the description talks about a negotiation, that would be between the third party and the exchange (i.e., and not any one bidder). The exchange must then make clear to the bidders what this data represents and how it will be represented. I suggest expressing the latter point as a “Best Practice” point similar to the first such point under Device object (i.e., that the exchange is highly encouraged to publish lists of device makes, models, etc., since there are currently no standardized reference lists).

Connection Type Description: The table description in section 6.11 was copied from 6.10, but never edited for the 6.11 table.

Bid Response Description: The first paragraph of 4.3.1 describing the bid response was copied from 3.3.1 the bid request, but never edited.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=37

Original author: [email protected] (October 24, 2011 10:36:01)

We believe that bidresponse.brespextensions should be defined as object and not as string, since this is data specified by exchange. Therefore both exchange and dsp should be able to interpret/process/use it. Same applies to bidresponse.bidset[x].bid.bidextensions.

bidresponse.customdata is ok as string, since this is used only by dsp and exchange will not process/intrpret/use this data in any way. If DSP sends data encoded as string, so can dsp also interpret this (his) string received back from adexchange.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=39

Original author: [email protected] (July 22, 2011 21:19:45)

In the OpenRTB Mobile specification, the site and app objects define 3 publisher attributes: “pid” (pub ID on the exchange), “pub” (pub name), and “pdomain” (the pub’s domain). This spec pushed these into a “publisher” object and since a “site” or “app” object has only one “publisher” object, this create an unnecessary point of backward incompatibility. Please restore these attributes as “pid”, “pub”, and “pdomain” to the “site” and “app” objects.

This leaves only the “cat” attribute in the “publisher” object, which means we should decide what to do about “cat” and drop “publisher”. My recommendation on “cat” is to drop it. I don’t really understand how an ad serve/bid decision would use this since the publisher is analogous to a parent company of sites; how are content categories about them meaningful to such a decision versus the site/app categories? If there is a meaningful way to use it, then my alternate recommendation is to rename it “pubcat” and move it to “site” and “app” with the other attributes.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=28

Original author: [email protected] (July 14, 2011 07:37:39)

What steps will reproduce the problem?
1.mvn install on the root folder shows up this warning.
2.
3.

What is the expected output? What do you see instead?
[INFO] Surefire report directory: C:\openrtb\common\target\surefire-reports

T E S T S

Running org.openrtb.common.json.AdvertiserBlocklistRequestTranslatorTest
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

What version of the product are you using? On what operating system?
Windows Vista

Please provide any additional information below.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=17

Original author: [email protected] (July 22, 2011 21:27:46)

The “geo” object should be removed and its attributes moved directly into the “device” and “user” objects. I know it may seem better organized this way, but it is just as easy to read and write these attributes to and from the “device” and “user” objects directly. Any perceived organizational improvement is hardly a reason to create an unnecessary point of backward incompatibility with the OpenRTB Mobile specification.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=31

Original author: [email protected] (February 15, 2011 21:34:30)

What steps will reproduce the problem?

1. Do something
2. See result
3. Still broken

What is the expected output? What do you see instead?

Please use labels and text to provide additional information.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=2

Original author: [email protected] (July 06, 2011 15:46:22)

The word "contains" should be removed in the following section of the Open RTB 2.0RC1.pdf document.

Before you get started

Not all objects are required, and each object may contain contains a number of optional parameters.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=15

Original author: [email protected] (July 22, 2011 21:27:01)

The FIPS 10-4 region codes were withdrawn by NIST as a FIPS (Federal Info Processing Standard) in September 2008. Thus the geo.regionfips104 attribute should be dropped. If it’s still in use by some exchanges, it should be sent within bidextensions. Also, what is the standard behind the geo.metro attribute? The sources “Metro Marketing Area” and “MetroCode” are referenced, but I couldn’t find official references to these. If these are vendor specific codes, I don’t think they should be explicitly called out in the standard. If that is the case, they too could be passed within “bidextensions”.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=30

Hello.

During run validator for audio type request, I faced above error and found that there is a bug on companion_type definition under audio.

	"audio": {
		"type": "object",
		"required": [ "mimes" ],
		"additionalProperties": false,

....
"companiontype": {
"type": "array",
"items": {
"$ref": "#definitions/vast_companion_type"
}
},
..,

As you see it , "/" is omitted between # & definitions.

Please put the "/" like below.

				"items": {
					"$ref": "#/definitions/vast_companion_type"
				}

I see the problem at openrtb-schema_bid-request_v2-4.json

Original author: [email protected] (February 06, 2012 21:36:37)

This is for RTB version 2 for public comment.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=41

Original author: [email protected] (July 22, 2011 21:10:36)

The “imp” object has been reorganized from the OpenRTB Mobile specification to require either a banner or a video object. There are a couple issues with this. First, the either-or notion requires that the ad request limits itself to one or the other a priori. We have some applications in the field that make ad requests that are happy to receive either a banner or a video and do not know until the ad is received. This would preclude that. The structure also adds the complexity of an additional object to the incredible majority of requests that are non-video and in the process takes us further away from backward compatibility. Here are the points I strongly urge to address this:

• Restore “w”, “h”, “pos”, “battr”, and “atype” back into the “imp” object and remove them from “banner” and “video”. Even for VAST companion banners, I believe these would all have the same values. If I’m wrong about that, then keep the ones that do vary in “banner” as well as “imp”.
• Copy the remaining attributes from “banner” up to the “imp” object except “id”, since that is only meaningful to VAST companion banners.
• The presence of a “video” object can be used to indicate that a video ad is allowed.
• Change “atype” back to “btype” (i.e., a block list rather than a white list as it is in the OpenRTB Mobile specification). If people also want the flexibility of a white list, then keep them both but rename the white list to be “wtype” to be consistent with the convention established in the OpenRTB Mobile specification.
• If only a video ad is welcome, then the “video” object would be included and “btype” would be used to block the banners.
• The “banner” object can still exist in the specification for reference by the “video” object. But since it would only be used as video companion ads, there may be the opportunity to further simplify it, but I’ll leave that to a VAST champion. It would probably make sense to rename it to “companion” at this point.
• The “h” and “w” attributes should be recommended rather than required as their descriptions indicate. While we tend to include it all the time, it is quite common in mobile to derive screen height and width from the UA and go with the largest MMA ad unit that will fit.

Summary note: This may feel less object-oriented from a spec perspective, but it makes requests for non-video ad units (i.e., the huge majority of global ad requests) simpler and more backward compatible with the existing OpenRTB Mobile specification.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=23