RE: More Private Comments

["Gould, James" <JGould@verisign.com>]

Scott,

I have no problem with items 1 and 2, but item 3 "no "content length: "
header in TCP transport.", I have a different proposal.  If there is a
desire to use a packet header, as an implementer I would find it more
efficient and simpler to use a network header that only includes the length
of the packet as a network byte order, four byte, unsigned integer.  By
using the network header, the packets will be framed and the framing can be
done without having to do string comparisons.  

Jim



> ----------
> From: 	Hollenbeck, Scott
> Sent: 	Monday, December 17, 2001 7:47 AM
> To: 	'ietf-provreg@cafax.se'
> Subject: 	More Private Comments
> 
> Last week I received a few private comments that will result in changes to
> the EPP documents.  Here's a quick summary:
> 
> Eric Brunner-Williams provided some suggested changes to the data
> collection
> policy elements.  Nothing radical, so I intend to make the changes he
> requested.
> 
> Dan Manley also sent me some private comments touching on 4 things:
> 
> 1)  auth info not required for transfer query command
> 
> This was discussed on the list a little while ago.  I intend to change
> things such that auth info is required to complete a transfer query.
> 
> 2)  inconsistent poll response format
> 
> This comment described an issue with the way <poll> messages are returned.
> In the current documents, the response <msg> element is overloaded to
> return
> the message.  Dan suggested a change the to the 1301 response code so that
> it has a consistent meaning, and putting the message within the <resData>
> element.  I disagreed with putting the message with <resData> because
> <resData> is currently used only for _object specific_ response data, and
> I
> suggested a compromise of putting the message within the <msgQ> element,
> like this:
> 
>   S:  <response>
>   S:    <result code="1301">
>   S:      <msg>Message dequeued.</msg>
>   S:    </result>
>   S:    <msgQ count="5">
>   S:      <qDate>2000-06-08T22:00:00.0Z</qDate>
>   S:      <polledMsg id="12345">Transfer requested.</polledMsg>
>   S:    </msgQ>
>   S:    <resData>
>   S:      <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj"
>   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
>   S:        <obj:name>example</obj:name>
>   S:        <obj:trStatus>pending</obj:trStatus>
>   S:        <obj:reID>ClientX</obj:reID>
>   S:        <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
>   S:        <obj:acID>ClientY</obj:acID>
>   S:        <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
>   S:        <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
>   S:      </obj:trnData>
>   S:    </resData>
>   S:    <trID>
>   S:      <clTRID>ABC-12345</clTRID>
>   S:      <svTRID>54321-XYZ</svTRID>
>   S:    </trID>
>   S:  </response>
>   S:</epp>
> 
> This puts all of the <poll>-specific data in the <msgQ> element, keeps
> <resData> object-specific, and makes the response code structure
> consistent.
> At the end of our last private exchange Dan said he still wasn't
> comfortable
> with this suggested modification, so we may have more to talk about.
> 
> 3)  no "content length: " header in TCP transport.
> 
> Dan's comment is that it would be helpful for buffering purposes for the
> application reading from a socket to know the size of an incoming PDU.  he
> and I talked about it a bit, and came with a suggested change to the TCP
> mapping to define a short header of the form "type:length:value", where:
> 
> Type = "application/epp+xml"
> 
> Length: length of the value in octets, represented in hex.
> 
> Value: The <epp>...</epp> stuff.  So a TCP datagram containing an XML
> instance of length 128 decimal (80 hex) would look like this:
> 
> application/epp+xml:80:<epp>...</epp>
> 
> 4) Domain and Contact transfers in EPP
> 
> Dan and I talked a bit more about the comments he made during the SLC
> provreg session, but no specific changes were agreed to.
> 
> Eric and Dan, please feel free to expand on anything you think needs more
> explaining or if you disagree with my summations.
> 
> -Scott- 
> 
>