RE: More Private Comments

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Daniel Manley [mailto:dmanley@tucows.com]
> Sent: Friday, December 21, 2001 10:12 AM
> To: Hollenbeck, Scott
> Cc: 'ietf-provreg@cafax.se'
> Subject: Re: More Private Comments
> 
> 
> 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.

Dan and I exchanged some private messages to make sure we're on the same
page, and after thinking about it a bit more I've come up with a way to
ensure that an optional "type" attribute is meaningful without having to
enumerate possible types: we just use existing EPP elements that clients
already understand.  Here's a sample to describe a transfer request:

<msgQ count="5" id="12345">
  <qDate>2000-06-08T22:00:00.0Z</qDate>
  <msg xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       type="<domain:transfer/>">Transfer requested.</msg>
</msgQ>

Note that the value of the "type" attribute is the command element that
caused the message in the first place, and that an "xmlns" attribute has to
be added to ensure that the parser can digest the "type" attribute.

My commentary and question: Given that all of this info is also found in the
<resData> element, I've suggested to Dan that the "type" attribute appears
redundant.  Dan's rationale for why it might be helpful is described above.
Does anyone object to adding an optional (it's not needed when there's no
<resData>) "type" attribute in this fashion?

-Scott-