Re: More Private Comments

[Daniel Manley <dmanley@tucows.com>]

Hollenbeck, Scott wrote:

>
>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.
>
thanks for posting this Scott.  The only other suggestion we have would 
be to include a "type" attributes to the <polledMsg> tag.  I'm not sure 
if EPP could define a set of types since EPP only defines that transfers 
must generate messages.  So possibly a pattern like <polledMsg 
type="transfer:domain" id="123">Transfer requested</polledMsg>.  This 
would allow parsing clients to know how to parse the XML in <resData> 
without having to pre-parse it beforehand.

Also, I was wondering if poll in the EPP documents (this would also 
apply to futur push implementations, if any) should be further defined 
like this:

"An EPP server MUST generate queued messages or notifications to the 
registrar if an object owned by the registrar is affected or changed 
without the registrar's invovlement."  (or something of the sorts)

As a registrar I would want to be notified anytime an object of mine is 
modified or affected by the actions of either other registrars (like 
transfer requests) or by the registry itself (via policy mechanisms like 
auto-renew or changes made by registry support staff).  That way, 
registrars can be sure that their databases have better chances of not 
being out of sync with the registry.

Dan