Banner and Video Objects

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 reported on code.google.com by jim.butler%nexage.com@gtempaccount.com on 22 Jul 2011 at 9:10
rainzq / openrtb

Banner and Video Objects #23
