updated tech spec

Coordinator
Jul 7, 2009 at 11:29 PM

I posted it in Issue Tracker area.  Take a look so we can discuss on tomorrow's call.

Thanks,

--Evan

Coordinator
Jul 8, 2009 at 7:53 PM

At some previous meeting, we discussed that we need to add HTTP parameter - sending trading partner GUID.

It's not in the current spec.

Arkadiy.

 

 

 

 

Coordinator
Jul 8, 2009 at 8:11 PM

I see that you posted a new version of spec  today. CodePlex did not send notification about this.

You added iab_callback_guid that really is a sending trading partner GUID. 

Am I correct?

Thanks,

Arkadiy.

 

 

Coordinator
Jul 9, 2009 at 7:34 PM

Yes, I believe that was the intent.

Jeremy Fain
Vice President of Industry Services
INTERACTIVE ADVERTISING BUREAU

116 East 27th Street, 7th Floor, New York, New York 10016
direct: 212 380 4724 / eFax: 212 214 0336 / cell: 646 456 4385


From: adikshte1 [mailto:notifications@codeplex.com]
Sent: Wednesday, July 08, 2009 4:11 PM
To: Jeremy Fain
Subject: Re: updated tech spec [iabebusiness:61787]

From: adikshte1

I see that you posted a new version of spec today. CodePlex did not send notification about this.

You added iab_callback_guid that really is a sending trading partner GUID.

Am I correct?

Thanks,

Arkadiy.

Read the full discussion online.

To add a post to this discussion, reply to this email (iabebusiness@discussions.codeplex.com)

To start a new discussion for this project, email iabebusiness@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Coordinator
Jul 15, 2009 at 1:09 PM

Is the final document for review and discussion posted? 

Coordinator
Jul 20, 2009 at 2:53 PM

REMINDER: Please review the posted tech spec for our meeting tomorrow.  We HAVE to get this finalized - the project needs to move forward and needs this document finalized to do that.

 

-Jeremy

 

Coordinator
Jul 20, 2009 at 5:38 PM

I reviewed the July 7th document and here are my comments -

 

  • There is a small typo in the description of the HTTP header parameters - there are three required fields not two.
  • My notes were that the goal of the three parameters was to allow most errors to be handled asynchronously.    Asynchronous errors allow all of the XML processing to be handled in the most flexible and scalable way.   The only errors that would be handled synchronously would be authentication errors, missing or malformed HTTP header parameters or system errors on the receiving side.   The first two types of errors would be considered fatal and message should not be resent until the issue has been resolved.   The third type, system errors on the receiving side, would be recoverable errors such as a database or queue mechanism is down etc and the message should be resent.   
  • All checks of the XML including well formed, schema validation, value checking, etc would be handled asynchronously.  If values in the XML did not match the values from the HTTP header the HTTP header values should be used to return the error and the XML values noted in the error message.  In other words the message would be sent to the endpoint associated with the HTTP header value iab_callback_guid and indicate the error is for message iab_message_id.  This does leave some gaps but will be consitient since there will be cases when then HTTP headers are readable but the XML is not.   
  • I had thought the response examples were going to be reworked into messaging examples vs stages of communication.   Roughly what I was expecting was a different liest for asynchronous vs synchronous responses/scenarios.  The synchronous might be something like:
  1. Communication error - This entry seemed ok to me - if for any reason communication is not successful the sender must have internal handling.  Likely this would include loggin the error, the enpoint, some message info and retrying later. 
  2. Authentication error - [403]Forbidden  returned with all additonal handling on the sender side.  Processing data from an message with failed authentication (including the required iab http headers) puts the recieving system at risk unnecessarily.
  3. Missing or Malformed required iab http headers - an appropriate http message response should be selected by the group for this condition. 
  4. System errors on the receiving side - Some variation of a [500] returned to the sender? 
  5. Message Recieved for Processing - [200] OK returned sender should expect an asynchronous iab_acknowlegement

 

<!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:RelyOnVML /> <o:AllowPNG /> </o:OfficeDocumentSettings> </xml><![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:Compatibility> <w:BreakWrappedTables /> <w:SnapToGridInCell /> <w:WrapTextWithPunct /> <w:UseAsianBreakRules /> </w:Compatibility> </w:WordDocument> </xml><![endif]--><!--[if !supportAnnotations]--><!-- --> <script>// <![CDATA[ function msoCommentShow(anchor_id, com_id) { if(msoBrowserCheck()) { c = document.all(com_id); a = document.all(anchor_id); if (null != c && null == c.length && null != a && null == a.length) { var cw = c.offsetWidth; var ch = c.offsetHeight; var aw = a.offsetWidth; var ah = a.offsetHeight; var x = a.offsetLeft; var y = a.offsetTop; var el = a; while (el.tagName != "BODY") { el = el.offsetParent; x = x + el.offsetLeft; y = y + el.offsetTop; } var bw = document.body.clientWidth; var bh = document.body.clientHeight; var bsl = document.body.scrollLeft; var bst = document.body.scrollTop; if (x + cw + ah / 2 > bw + bsl && x + aw - ah / 2 - cw >= bsl ) { c.style.left = x + aw - ah / 2 - cw; } else { c.style.left = x + ah / 2; } if (y + ch + ah / 2 > bh + bst && y + ah / 2 - ch >= bst ) { c.style.top = y + ah / 2 - ch; } else { c.style.top = y + ah / 2; } c.style.visibility = "visible"; } } } function msoCommentHide(com_id) { if(msoBrowserCheck()) { c = document.all(com_id); if (null != c && null == c.length) { c.style.visibility = "hidden"; c.style.left = -1000; c.style.top = -1000; } } } function msoBrowserCheck() { ms = navigator.appVersion.indexOf("MSIE"); vers = navigator.appVersion.substring(ms + 5, ms + 6); ie4 = (ms > 0) && (parseInt(vers) >= 4); return ie4; } if (msoBrowserCheck()) { document.styleSheets.dynCom.addRule(".msocomanchor","background: infobackground"); document.styleSheets.dynCom.addRule(".msocomoff","display: none"); document.styleSheets.dynCom.addRule(".msocomtxt","visibility: hidden"); document.styleSheets.dynCom.addRule(".msocomtxt","position: absolute"); document.styleSheets.dynCom.addRule(".msocomtxt","top: -1000"); document.styleSheets.dynCom.addRule(".msocomtxt","left: -1000"); document.styleSheets.dynCom.addRule(".msocomtxt","width: 33%"); document.styleSheets.dynCom.addRule(".msocomtxt","background: infobackground"); document.styleSheets.dynCom.addRule(".msocomtxt","color: infotext"); document.styleSheets.dynCom.addRule(".msocomtxt","border-top: 1pt solid threedlightshadow"); document.styleSheets.dynCom.addRule(".msocomtxt","border-right: 2pt solid threedshadow"); document.styleSheets.dynCom.addRule(".msocomtxt","border-bottom: 2pt solid threedshadow"); document.styleSheets.dynCom.addRule(".msocomtxt","border-left: 1pt solid threedlightshadow"); document.styleSheets.dynCom.addRule(".msocomtxt","padding: 3pt 3pt 3pt 3pt"); document.styleSheets.dynCom.addRule(".msocomtxt","z-index: 100"); } // ]]></script> <!--[endif]--><!-- /* Font Definitions */ @font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1073741899 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:Cambria; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman"; mso-bidi-language:EN-US;} p.MsoCommentText, li.MsoCommentText, div.MsoCommentText {mso-style-noshow:yes; margin-top:0in; margin-right:0in; margin-bottom:10.0pt; margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:Cambria; mso-fareast-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman"; mso-bidi-language:EN-US;} span.MsoCommentReference {mso-style-noshow:yes; mso-ansi-font-size:8.0pt; mso-bidi-font-size:8.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --><!--[if gte mso 10]> <mce:style><! /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";} --> <!--[endif]-->iab_callback_guid<!--[if !supportAnnotations]-->[MSOffice1]<!--[endif]--> 
<!--[if !supportAnnotations]-->
<!--[endif]-->
<!--[if !supportAnnotations]-->
<!--[endif]--><!--[if !supportAnnotations]--><!--[endif]-->

 <!--[if !supportAnnotations]-->[MSOffice1]<!--[endif]-->My notes on this header are incomplete.  It seems that the point of this would be to send an asynch response even if the XML cannot be parsed, but that does not seem to be needed based on the table below; cases where XML can’t be parsed are just handled with HTTP response codes.  Which way should we go on this?

<!--[if !supportAnnotations]-->
<!--[endif]-->
Coordinator
Jul 27, 2009 at 11:11 PM

A new draft has been posted to the issue tracker.  Please send me feedback.  Thanks.

Coordinator
Jul 29, 2009 at 1:36 PM

Reviewed the new document  and it looks good - certainly worth presenting as-is to the group.    I think I can answer one of the queries in the document -

*Page 4 -  "single session"  - What I remember is that we wanted to ensure each transaction was "atomic".  In otherwords the implementation should not require a sequence of transacations to send a message.   There have been some implementations in other media modeled after users on a webpage that required authenticating, setting a cookie or getting a token, sending a message (or multiple) and then closing the session.   The description of the proposes REST message seems to make it clear that everything message send is a single stateless request so we can remove this point.

 

Thanks evan for the work

--John

Coordinator
Jul 29, 2009 at 3:23 PM

Comments to open issues in Technical Specifications:

1) For POST, an xml document is provided after an empty line in the message body.
    It'll be posted at the path provided directly after a word POST.
  
2) It makes sense to add an IABMessageHeader to IAB_Acknowledgement.xsd.
    This way we could provide useful info including UniqueMessageID of this message.

3) In cases when synchronous and asynchronous responses are necessary,
     I think we need use the following pattern:
            a) Synchronous response with status 202 (Accepted).
            b) Asynchronous response:
                     - server POST response (XML Acknowledgment document);
                     - client response to the POST is a 200 (OK).
   
Thanks,
Arkadiy.

Coordinator
Jul 29, 2009 at 3:40 PM
adikshte1 wrote:

3) In cases when synchronous and asynchronous responses are necessary,
     I think we need use the following pattern:
            a) Synchronous response with status 202 (Accepted).
            b) Asynchronous response:
                     - server POST response (XML Acknowledgment document);
                     - client response to the POST is a 200 (OK).

 

Arkadiy brings up a good point - we did not address the message workflow related to the asynchronous response messages.   I think the workflow should be generally the same as with documents except there should be no asynchronous responses (to avoid creating an endless loop).   If an asynchronous response message has a non-recoverable (ie cannot be retried as is) the system should log the problem and notify for manual handling.  

So for the response message workflow scenarios 1-4 would be valid as is.  5 would change to indicate manual handling for the XML problem, 6 would change to not have a response message and 7 would not be included.

The current workflow related to how both synchronous and asynchronous responses are handled for document messages seems right as is (using various response http codes).     

--John