Unclear native ads specifications

[Crystark]

Hi,

In version 2.3 of OpenRTB you describe the Native object as a 5-property object, one being "request" and having the following description: Request payload complying with the Native Ad Specification.

Now i open the Native ad specification and there i see an other native object but with much more information in it.

So how should I interpret that: does that mean the "request" string needs to be a serialized version of the Native object described in the Native ad specification or is the Native ad specification's native object a replacement for the OpenRTB Native object ?

As a side note, i'd like to point out that native is a Java keyword so when one creates a java object based on this specification, he'll probably have to name it otherwise and add a specific mapping for this field. I think you had the same issue with the pmp.private field which has been renamed to pmp.private_auction when passing from v2.1-PMP to v2.2. May I suggest naming it nativead ?

Thanks

[giorgosera]

+1 I'd like a clarification about that too!

[drjbutler]

Good points. First the clarification. The OpenRTB v2.3 and Native 1.0 specifications are separate specifications. Although the Native Spec was born as an OpenRTB subcommittee, it could conceivably be used outside of RTB. Even within the context of RTB, there are times when the Native payload may be processed outside of the context of the RTB auction (e.g., on an in-app SDK). Thus we added the outer “native” object so that it could be easily inspected and determined to be a native payload outside the context of OpenRTB. When transported via OpenRTB, the OpenRTB container for it is the request attribute of the Native object, so they are related but separate.

Great catch on “native” as a Java keyword. I totally missed that I’m sorry to say. To avoid having Java developers have to write their own overrides in JSON parsersr (I don’t think we want to add this kind of friction over a name), we should change the name of the “Native” object in OpenRTB, the name of the “native” attribute in the “Imp” object that points to it, and the “Native” root elements in the request and response of the Native Spec. If others agree, here are my suggestions but I’m open to others:

Native 1.0 Spec:

§ Request root object: “nativeimp”

§ Response root object: “nativead”

OpenRTB v2.3 Spec:

§ Native object: “NativeSet”

§ Native attribute in “Imp” that points to that object: “nativeset”

I frankly am not a fan of my own suggestion on the OpenRTB names, but here’s my rationale. I don’t know any straight up synonym for “native” that would fly in this context; therefore a suffix. But this object is an impression type essentially and sits alongside its “banner” and “video” siblings. If we call it “nativeimp” or “nativead”, it would seem inconsistent; the others should then be “bannerimp/videoimp” or “bannerad/videoad”, but that would break backward compatibility so that’s out. So what makes native fundamentally different from a banner or a video? Banners and videos are somewhat analogous to primitives as ads go, whereas a native ad is actually a composite or set of primitives. Thus NativeSet.

I would love a better idea. Anyone?

:JB

From: Laurent [mailto:notifications@github.com] Sent: Thursday, December 11, 2014 4:19 AM To: openrtb/OpenRTB Subject: [OpenRTB] Unclear native ads specifications (#11)

Hi,

In version 2.3 of OpenRTB you describe the Native object as a 5-property object, one being "request" and having the following description: Request payload complying with the Native Ad Specification.

Now i open the Native ad specificationhttps://github.com/openrtb/OpenRTB/blob/master/OpenRTB-Native-Ads-Specification-Final-Draft-v1.pdf and there i see an other native object but with much more information in it.

So how should I interpret that: does that mean the "request" string needs to be a serialized version of the Native object described in the Native ad specification or is the Native ad specification's native object a replacement for the OpenRTB Native object ?

As a side note, i'd like to point out that native is a Java keyword so when one creates a java object based on this specification, he'll probably have to name it otherwise and add a specific mapping for this field. I think you had the same issue with the pmp.private field which has been renamed to pmp.private_auction when passing from v2.1-PMP to v2.2. May I suggest naming it native_ad ?

Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/openrtb/OpenRTB/issues/11.

[Crystark]

Hi,

So if I understand this well, the request attribute of the OpenRTB Native object should contain the Native object of the Native specs as a Json encoded string ? That means one needs to deserialize the json to an OpenRTB Object and then deserialize the native.request to the appropriate native object ?

It's a shame one will need to doubly decode some parts of the payload but I understand that having two separate specs forces you to do this. But why not make each OpenRTB specs versions directly linked to one and only one of the native specs version ? It limits the evolution of the native specs inside the OpenRTB specs but you usually only change things when you change of OpenRTB version or else you use the OpenRTB ext field to add some features. That's just an idea though.

Thanks

[drjbutler]

You’ve got it exactly. The reason we decoupled the specs is also as you cite. OpenRTB is mature going on 4 years. Native is very new albeit it hugely popular and is also by its nature more complex than the most other ad units. It will almost certainly be called upon to evolve quickly for some time as it stabilizes and rightly so. Tying it tightly to the OpenRTB spec would either slow down the evolution of Native or just as bad drag OpenRTB through many more versions than it would otherwise need. I could certainly envision a point down the road when Native stabilizes enough to merge it into OpenRTB directly.

:JB

From: Laurent [mailto:notifications@github.com] Sent: Saturday, December 13, 2014 8:01 AM To: openrtb/OpenRTB Cc: Jim Butler Subject: Re: [OpenRTB] Unclear native ads specifications (#11)

Hi,

So if I understand this well, the request attribute of the OpenRTB Native object should contain the Native object of the Native specs as a Json encoded string ? That means one needs to deserialize the json to an OpenRTB Object and then deserialize the native.request to the appropriate native object ?

It's a shame one will need to doubly decode some parts of the payload but I understand that having two separate specs forces you to do this. But why not make each OpenRTB specs versions directly linked to one and only one of the native specs version ? It limits the evolution of the native specs inside the OpenRTB specs but you usually only change things when you change of OpenRTB version or else you use the OpenRTB ext field to add some features. That's just an idea though.

Thanks

— Reply to this email directly or view it on GitHubhttps://github.com/openrtb/OpenRTB/issues/11#issuecomment-66875621.

[drjbutler]

Frankly, as a Java developer the "native" name doesn't trouble me. It creates no problems for any message/class/interface names which are all capitalized (Native), or to methods which always need get/set prefixes (getNative() / setNative()). Fields will always be private and they can have mangled names. Specifically in my implementation I use protobuf, where the field name "native" is allowed, and the generated Java code uses a private field native_ so it compiles correctly. For local variables which type is a Native object, I have adopted "nativ" :)

On Fri, Dec 12, 2014 at 6:12 PM, Jim Butler jim.butler@nexage.com wrote:

Good points. First the clarification. The OpenRTB v2.3 and Native 1.0 specifications are separate specifications. Although the Native Spec was born as an OpenRTB subcommittee, it could conceivably be used outside of RTB. Even within the context of RTB, there are times when the Native payload may be processed outside of the context of the RTB auction (e.g., on an in-app SDK). Thus we added the outer “native” object so that it could be easily inspected and determined to be a native payload outside the context of OpenRTB. When transported via OpenRTB, the OpenRTB container for it is the request attribute of the Native object, so they are related but separate.

Great catch on “native” as a Java keyword. I totally missed that I’m sorry to say. To avoid having Java developers have to write their own overrides in JSON parsersr (I don’t think we want to add this kind of friction over a name), we should change the name of the “Native” object in OpenRTB, the name of the “native” attribute in the “Imp” object that points to it, and the “Native” root elements in the request and response of the Native Spec. If others agree, here are my suggestions but I’m open to others:

Native 1.0 Spec:

§ Request root object: “nativeimp”

§ Response root object: “nativead”

OpenRTB v2.3 Spec:

§ Native object: “NativeSet”

§ Native attribute in “Imp” that points to that object: “nativeset”

I frankly am not a fan of my own suggestion on the OpenRTB names, but here’s my rationale. I don’t know any straight up synonym for “native” that would fly in this context; therefore a suffix. But this object is an impression type essentially and sits alongside its “banner” and “video” siblings. If we call it “nativeimp” or “nativead”, it would seem inconsistent; the others should then be “bannerimp/videoimp” or “bannerad/videoad”, but that would break backward compatibility so that’s out. So what makes native fundamentally different from a banner or a video? Banners and videos are somewhat analogous to primitives as ads go, whereas a native ad is actually a composite or set of primitives. Thus NativeSet.

I would love a better idea. Anyone?

:JB

From: Laurent [mailto:notifications@github.com] Sent: Thursday, December 11, 2014 4:19 AM To: openrtb/OpenRTB Subject: [OpenRTB] Unclear native ads specifications (#11)

Hi,

In version 2.3 of OpenRTB you describe the Native object as a 5-property object, one being "request" and having the following description: Request payload complying with the Native Ad Specification.

Now i open the Native ad specification https://github.com/openrtb/OpenRTB/blob/master/OpenRTB-Native-Ads-Specification-Final-Draft-v1.pdf and there i see an other native object but with much more information in it.

So how should I interpret that: does that mean the "request" string needs to be a serialized version of the Native object described in the Native ad specification or is the Native ad specification's native object a replacement for the OpenRTB Native object ?

As a side note, i'd like to point out that native is a Java keyword so when one creates a java object based on this specification, he'll probably have to name it otherwise and add a specific mapping for this field. I think you had the same issue with the pmp.private field which has been renamed to pmp.private_auction when passing from v2.1-PMP to v2.2. May I suggest naming it native_ad ?

Thanks

— Reply to this email directly or view it on GitHub https://github.com/openrtb/OpenRTB/issues/11.

You received this message because you are subscribed to the Google Groups "openrtb-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

Osvaldo Doederlein | Software Engineer, Doubleclick Ad Exchange | opinali@google.com

[drjbutler]

Others ok with this?

:JB

From: openrtb-dev@googlegroups.com [mailto:openrtb-dev@googlegroups.com] Sent: Monday, December 15, 2014 10:59 AM To: openrtb-dev@googlegroups.com Cc: openrtb/OpenRTB; openrtb-native@googlegroups.com Subject: Re: [openrtb-dev] RE: [OpenRTB] Unclear native ads specifications (#11)

Frankly, as a Java developer the "native" name doesn't trouble me. It creates no problems for any message/class/interface names which are all capitalized (Native), or to methods which always need get/set prefixes (getNative() / setNative()). Fields will always be private and they can have mangled names. Specifically in my implementation I use protobuf, where the field name "native" is allowed, and the generated Java code uses a private field native_ so it compiles correctly. For local variables which type is a Native object, I have adopted "nativ" :)

On Fri, Dec 12, 2014 at 6:12 PM, Jim Butler jim.butler@nexage.com<mailto:jim.butler@nexage.com> wrote: Good points. First the clarification. The OpenRTB v2.3 and Native 1.0 specifications are separate specifications. Although the Native Spec was born as an OpenRTB subcommittee, it could conceivably be used outside of RTB. Even within the context of RTB, there are times when the Native payload may be processed outside of the context of the RTB auction (e.g., on an in-app SDK). Thus we added the outer “native” object so that it could be easily inspected and determined to be a native payload outside the context of OpenRTB. When transported via OpenRTB, the OpenRTB container for it is the request attribute of the Native object, so they are related but separate.

Great catch on “native” as a Java keyword. I totally missed that I’m sorry to say. To avoid having Java developers have to write their own overrides in JSON parsersr (I don’t think we want to add this kind of friction over a name), we should change the name of the “Native” object in OpenRTB, the name of the “native” attribute in the “Imp” object that points to it, and the “Native” root elements in the request and response of the Native Spec. If others agree, here are my suggestions but I’m open to others:

Native 1.0 Spec:

• Request root object: “nativeimp”

• Response root object: “nativead”

OpenRTB v2.3 Spec:

• Native object: “NativeSet”

• Native attribute in “Imp” that points to that object: “nativeset”

I frankly am not a fan of my own suggestion on the OpenRTB names, but here’s my rationale. I don’t know any straight up synonym for “native” that would fly in this context; therefore a suffix. But this object is an impression type essentially and sits alongside its “banner” and “video” siblings. If we call it “nativeimp” or “nativead”, it would seem inconsistent; the others should then be “bannerimp/videoimp” or “bannerad/videoad”, but that would break backward compatibility so that’s out. So what makes native fundamentally different from a banner or a video? Banners and videos are somewhat analogous to primitives as ads go, whereas a native ad is actually a composite or set of primitives. Thus NativeSet.

I would love a better idea. Anyone?

:JB

From: Laurent [mailto:notifications@github.commailto:notifications@github.com] Sent: Thursday, December 11, 2014 4:19 AM To: openrtb/OpenRTB Subject: [OpenRTB] Unclear native ads specifications (#11)

Hi,

In version 2.3 of OpenRTB you describe the Native object as a 5-property object, one being "request" and having the following description: Request payload complying with the Native Ad Specification.

Now i open the Native ad specificationhttps://github.com/openrtb/OpenRTB/blob/master/OpenRTB-Native-Ads-Specification-Final-Draft-v1.pdf and there i see an other native object but with much more information in it.

So how should I interpret that: does that mean the "request" string needs to be a serialized version of the Native object described in the Native ad specification or is the Native ad specification's native object a replacement for the OpenRTB Native object ?

As a side note, i'd like to point out that native is a Java keyword so when one creates a java object based on this specification, he'll probably have to name it otherwise and add a specific mapping for this field. I think you had the same issue with the pmp.private field which has been renamed to pmp.private_auction when passing from v2.1-PMP to v2.2. May I suggest naming it native_ad ?

Thanks

—

Reply to this email directly or view it on GitHubhttps://github.com/openrtb/OpenRTB/issues/11.

You received this message because you are subscribed to the Google Groups "openrtb-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.commailto:openrtb-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

Osvaldo Doederlein |

Software Engineer, Doubleclick Ad Exchange |

opinali@google.commailto:opinali@google.com

You received this message because you are subscribed to the Google Groups "openrtb-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.commailto:openrtb-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[drjbutler]

+1

On Mon, Dec 15, 2014 at 7:58 PM, Jim Butler jim.butler@nexage.com wrote:

Others ok with this?

:JB

From: openrtb-dev@googlegroups.com [mailto:openrtb-dev@googlegroups.com]

Sent: Monday, December 15, 2014 10:59 AM To: openrtb-dev@googlegroups.com Cc: openrtb/OpenRTB; openrtb-native@googlegroups.com Subject: Re: [openrtb-dev] RE: [OpenRTB] Unclear native ads specifications (#11)

Frankly, as a Java developer the "native" name doesn't trouble me. It creates no problems for any message/class/interface names which are all capitalized (Native), or to methods which always need get/set prefixes (getNative() / setNative()). Fields will always be private and they can have mangled names. Specifically in my implementation I use protobuf, where the field name "native" is allowed, and the generated Java code uses a private field native_ so it compiles correctly. For local variables which type is a Native object, I have adopted "nativ" :)

On Fri, Dec 12, 2014 at 6:12 PM, Jim Butler jim.butler@nexage.com wrote:

Good points. First the clarification. The OpenRTB v2.3 and Native 1.0 specifications are separate specifications. Although the Native Spec was born as an OpenRTB subcommittee, it could conceivably be used outside of RTB. Even within the context of RTB, there are times when the Native payload may be processed outside of the context of the RTB auction (e.g., on an in-app SDK). Thus we added the outer “native” object so that it could be easily inspected and determined to be a native payload outside the context of OpenRTB. When transported via OpenRTB, the OpenRTB container for it is the request attribute of the Native object, so they are related but separate.

Great catch on “native” as a Java keyword. I totally missed that I’m sorry to say. To avoid having Java developers have to write their own overrides in JSON parsersr (I don’t think we want to add this kind of friction over a name), we should change the name of the “Native” object in OpenRTB, the name of the “native” attribute in the “Imp” object that points to it, and the “Native” root elements in the request and response of the Native Spec. If others agree, here are my suggestions but I’m open to others:

Native 1.0 Spec:

§ Request root object: “nativeimp”

§ Response root object: “nativead”

OpenRTB v2.3 Spec:

§ Native object: “NativeSet”

§ Native attribute in “Imp” that points to that object: “nativeset”

I frankly am not a fan of my own suggestion on the OpenRTB names, but here’s my rationale. I don’t know any straight up synonym for “native” that would fly in this context; therefore a suffix. But this object is an impression type essentially and sits alongside its “banner” and “video” siblings. If we call it “nativeimp” or “nativead”, it would seem inconsistent; the others should then be “bannerimp/videoimp” or “bannerad/videoad”, but that would break backward compatibility so that’s out. So what makes native fundamentally different from a banner or a video? Banners and videos are somewhat analogous to primitives as ads go, whereas a native ad is actually a composite or set of primitives. Thus NativeSet.

I would love a better idea. Anyone?

:JB

From: Laurent [mailto:notifications@github.com] Sent: Thursday, December 11, 2014 4:19 AM To: openrtb/OpenRTB Subject: [OpenRTB] Unclear native ads specifications (#11)

Hi,

In version 2.3 of OpenRTB you describe the Native object as a 5-property object, one being "request" and having the following description: Request payload complying with the Native Ad Specification.

Now i open the Native ad specification https://github.com/openrtb/OpenRTB/blob/master/OpenRTB-Native-Ads-Specification-Final-Draft-v1.pdf and there i see an other native object but with much more information in it.

So how should I interpret that: does that mean the "request" string needs to be a serialized version of the Native object described in the Native ad specification or is the Native ad specification's native object a replacement for the OpenRTB Native object ?

As a side note, i'd like to point out that native is a Java keyword so when one creates a java object based on this specification, he'll probably have to name it otherwise and add a specific mapping for this field. I think you had the same issue with the pmp.private field which has been renamed to pmp.private_auction when passing from v2.1-PMP to v2.2. May I suggest naming it native_ad ?

Thanks

— Reply to this email directly or view it on GitHub https://github.com/openrtb/OpenRTB/issues/11.

You received this message because you are subscribed to the Google Groups "openrtb-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

Osvaldo Doederlein |

Software Engineer, Doubleclick Ad Exchange |

opinali@google.com

You received this message because you are subscribed to the Google Groups "openrtb-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups "openrtb-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[drjbutler]

"I would love a better idea. Anyone?"

NginAd is PHP so we don't care about Java keywords. Though it's hard to believe that every Java developer would feel obligated to name all their class members exactly the same as the parameters. I am glad that the Native 1.0 is being distanced from the OpenRTB 2.3 spec, so thumbs up for that.

• Chris

On Friday, December 12, 2014 3:12:27 PM UTC-8, Jim wrote:

Good points. First the clarification. The OpenRTB v2.3 and Native 1.0 specifications are separate specifications. Although the Native Spec was born as an OpenRTB subcommittee, it could conceivably be used outside of RTB. Even within the context of RTB, there are times when the Native payload may be processed outside of the context of the RTB auction (e.g., on an in-app SDK). Thus we added the outer “native” object so that it could be easily inspected and determined to be a native payload outside the context of OpenRTB. When transported via OpenRTB, the OpenRTB container for it is the request attribute of the Native object, so they are related but separate.

Great catch on “native” as a Java keyword. I totally missed that I’m sorry to say. To avoid having Java developers have to write their own overrides in JSON parsersr (I don’t think we want to add this kind of friction over a name), we should change the name of the “Native” object in OpenRTB, the name of the “native” attribute in the “Imp” object that points to it, and the “Native” root elements in the request and response of the Native Spec. If others agree, here are my suggestions but I’m open to others:

Native 1.0 Spec:

§ Request root object: “nativeimp”

§ Response root object: “nativead”

OpenRTB v2.3 Spec:

§ Native object: “NativeSet”

§ Native attribute in “Imp” that points to that object: “nativeset”

I frankly am not a fan of my own suggestion on the OpenRTB names, but here’s my rationale. I don’t know any straight up synonym for “native” that would fly in this context; therefore a suffix. But this object is an impression type essentially and sits alongside its “banner” and “video” siblings. If we call it “nativeimp” or “nativead”, it would seem inconsistent; the others should then be “bannerimp/videoimp” or “bannerad/videoad”, but that would break backward compatibility so that’s out. So what makes native fundamentally different from a banner or a video? Banners and videos are somewhat analogous to primitives as ads go, whereas a native ad is actually a composite or set of primitives. Thus NativeSet.

I would love a better idea. Anyone?

:JB

From: Laurent [mailto:notifi...@github.com ] Sent: Thursday, December 11, 2014 4:19 AM To: openrtb/OpenRTB Subject: [OpenRTB] Unclear native ads specifications (#11)

Hi,

In version 2.3 of OpenRTB you describe the Native object as a 5-property object, one being "request" and having the following description: Request payload complying with the Native Ad Specification.

Now i open the Native ad specification https://github.com/openrtb/OpenRTB/blob/master/OpenRTB-Native-Ads-Specification-Final-Draft-v1.pdf and there i see an other native object but with much more information in it.

So how should I interpret that: does that mean the "request" string needs to be a serialized version of the Native object described in the Native ad specification or is the Native ad specification's native object a replacement for the OpenRTB Native object ?

As a side note, i'd like to point out that native is a Java keyword so when one creates a java object based on this specification, he'll probably have to name it otherwise and add a specific mapping for this field. I think you had the same issue with the pmp.private field which has been renamed to pmp.private_auction when passing from v2.1-PMP to v2.2. May I suggest naming it native_ad ?

Thanks

— Reply to this email directly or view it on GitHub https://github.com/openrtb/OpenRTB/issues/11.

[Crystark]

On my end it's a simple question of using an annotation so that the field is serialized/deserialized to the correct "native" field. But I won't talk for every Java developer and I guess that depending on one's code it can be more or less tedious.

I think that for the good of all it's better to avoid any language keyword: you never know what people may be facing. I feel like calling the field "nativ" is a good idea: it's simple. It's even shorter than 'native' which reduces used bandwidth for those not using protobuf or the like of it ;)

[drjbutler]

+1

---

The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.

[jlcheng]

-1 on renaming the "native" field to "nativ". The label "nativ" looks like a typo and to intentionally misspell it because of Java is a bad idea.

Popular Java libraries like GSON and Jackson allow Java developers to easily customize property names using annotations. If this field needs to be renamed, fine. But it should not based on fear that the name "native" will cause problems with Java developers.

[manigandham]

Have to agree with @jlcheng

It's a mistake to change the name because of a single programming language when it can be easily handled by annotations. In 2015, this shouldn't even be an issue for any modern language.

Make the spec stand clear and concise on it's own, the implementation (using whatever language) should not be confused with the structure of the spec itself.

[lpgauth]

Specs really shouldn't be influenced by implementation details like this... The fact that this discussion is happening is a bit alarming.

[k-bx]

Hi!

I am working on a Haskell lib for OpenRTB and I should add my 2 cents that in haskell, words data and type are also keywords (used to create new types and type-synonyms respectively), so it does complicate life a bit, since you can't auto-generate accessors for those fields, so if you'll consider renaming some fields, please also think on those.

But what I wanted mostly to say is that renaming fields in next version of a protocol is a huge pain for backwards-compatibility and I'd suggest just skipping it, what's done is done, and causing backwards-compatibility-pain is much worse than one-time pain for developing shared OpenRTB library.

[manigandham]

Was there a conclusion on this?

I'm surprised why this second part is still a debate, the spec should stand alone and have clear naming that makes sense for its context. Protected keywords in languages have nothing to do with the spec and should be dealt with separately.

[drjbutler]

This was discussed, the consensus was that we should not worry about language reserved words, and so the spec stands as published.

:JB

---

James M. Butler, Ph.D. SVP of Technology Millennial Media, Inc.

On Apr 16, 2015, at 8:58 AM, Mani Gandham notifications@github.com wrote:

Was there a conclusion on this?

I'm surprised why this second part is still a debate, the spec should stand alone and have clear naming that makes sense for its context. Protected keywords in languages have nothing to do with the spec and should be dealt with separately.

— Reply to this email directly or view it on GitHub https://github.com/openrtb/OpenRTB/issues/11#issuecomment-93727676.

[NathanChristie]

Had I seen this issue, I may not have created this posting on the Google Groups openrtb-user forum. I'm linking it here in case one is brought here via an external link and searching for authoritative information: https://groups.google.com/forum/#!topic/openrtb-user/sbpf6OfzilY