rainzq / openrtb Goto Github PK

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.

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.

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%20RTB%202.0RC1.pdf&c
an=2&q=

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.

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

[deleted issue]

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.

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.

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.

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.

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).

Currently we have different floor prices for different banner types as those 
defined in 6.2 Banner Ad Types.

As the floor price is at the impression level and there is no imp.banner.type, 
but there is a block types array. Would the best way to set different floor 
prices be to have 2 imp.

E.g. for HTML (we block 3)
imp[0].floor = 1.0
imp[0].banner.btype = [1, 4, 3]

E.g. for Rich Media (we block 2)
imp[1].floor = 2.0
imp[1].banner.btype = [1, 4, 2]

The issue currently is that we are debating the intent of the spec when it 
comes to the wording around the impression object 'action for a specific 
position'.

What we are trying to do is action a position but differ the floor price based 
on the attributes of banner, thus 2 actions for the same position.

Thanks

This is for RTB version 2 for public comment.

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

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

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.

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

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.

>> 3. Do you have plans to add user matching in the spec? If so, when 
>> could we expect to see a draft of it?
>>
>> 4. 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.

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

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.

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

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

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.

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.

We referred to the Wiki spec mentioned in the Carrier field and according to 
the wiki article "A mobile network code (MNC) is used in combination with a 
mobile country code (MCC) (also known as a "MCC / MNC tuple") to uniquely 
identify a mobile phone operator/carrier"

Now the RTB spec 2.1 only mentions the use of MNC which is clearly insufficient 
to determine the carrier.

So if you wish to determine the carrier using something other than the MCC, say 
country from the GEO, the fact that some countries have multiple MCCs with 
overlapping MNCs makes this impossible.

Example:

310 - 280 = ATT  
311 - 280 = Verizon

So if the publisher only sends the MNC (280) and country USA we cannot 
determine if the carrier is ATT or VERIZON.


Solution:
Pass the tuple MCC, MNC as the carrier code or join them as one string e.g. 
310280.

In addition it would be nice to derive an open standards list from this wiki 
article. It would make a great start.
Perhaps a nice web service for companies to fetch the latest revision.

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.

Background/Problem Description:

Proposed Solution:

Implementation Notes:

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”.

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.

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

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).

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

As the impression.banner has a btype which might allow the inclusion of 
multiple valid types in the response. The response object does not have a key 
for the banner type of the delivered ad.

Currently we have addressed this with an extension.

Background/Problem Description:

Proposed Solution:

Implementation Notes:

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

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.

Don't really know how to report this so i'm doing it here as well as by email...

I was going through the new OpenRTB 2.1 RC1 with PMP API an i found something 
that seems problematic.
On page 30, table 3.3.13 (PMP Object) one field is called "private". This won't 
be compatible with most object oriented development languages as "private" is 
often a reserved word. For instance, java doesn't accept this as an object 
attribute name.

Maybe should it be changed to "priv" or "isprivate".

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

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.

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.

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.

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

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).

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.

I downloaded to run a sample with ssp web in openrtb sources. I am trying to 
config but it is not working. Someone help me give some sample project to begin 
it or guide how to start web project with tomcat or jetty. 

p/s: This here is not clearly  . 
http://code.google.com/p/openrtb/wiki/SspGettingStarted

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.

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.

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.

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.