Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review

Ray,

Thanks, we can take a look of the nits in AUTH48.

On the item of ignoring unsupported protocol options, I don’t believe that it is reasonable to return a success unless the server did exactly what the client requested.  The protocol is not defined to support a single client’s implementation, but to provide the required and optional features to satisfy the needs of multiple clients.  If a client wants to interface with all registries with the least number of permutations than it should not include the optional attributes.  Including another protocol item that defines the optional attributes that were ignored would require more work for the clients that care about those options.  If the servers should ignore unsupported options than the 2102 error code should not exist, but I believe its inclusion covers this specific case.  In summary, the 2102 error does not make policy but clearly provides a response to the client that their command could not be processed as requested.  Having the server pick and choose what it’s going to do with the command elements would cause more confusion and does not make for a clean interface.  


-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or Registry  Sensitive information intended solely for the recipient and, thus may not be  retransmitted, reproduced or disclosed without the prior written consent of  VeriSign Naming and Directory Services.  If you have received  this e-mail message in error, please notify the sender immediately by  telephone or reply e-mail and destroy the original message without making a  copy.  Thank you.

---

From: <Ray.Bellis@nominet.org.uk>
Date: Thu, 25 Mar 2010 00:58:35 -0400
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review

Having just discussed with Scott, I'd like to re-raise this point that I made 26th February: 
 
> Not being an EPP guru, what's the rationale for requiring a 2102 
> error if the server doesn't support <secDNS:update urgent="1"> or 
> <secDNS:maxSigLife> ? 
> 
> I would have thought that Postel's law should apply, otherwise a 
> registrar has to have advance knowledge of which registries support 
> those elements and which don't, and alter their submitted XML 
> accordingly.  I can't immediately see how any harm would come from 
> simply ignoring those elements. 

To my mind, requiring the 2102 error in effect makes policy - something we just said in the meeting that EPP specs should not do.  It _mandates_ a hard fail condition when those values are not supported, when it would be _perfectly_ reasonable for a registry to ignore the values, complete the operation anyway but also send back a <message/> element indicating that the requested policy value was ignored. 

Absent a "policy negotiation" feature in EPP, I still believe that hard failing these options also puts too high an implementation cost on the _client_ side of this specification.  If the server announces support for the secDNS 1.1 extension, the client shouldn't also need additional coding/templating to handle the four possible variants of whether the particular registry server it's talking to also supports "maxSigLife" and/or "urgent". 

Unfortunately I don't know how to address this without requiring a larger change than the AUTH48 window permits. 

There's also a couple of nits relating to <secDNS:update urgent="..."> which I think can be easily fixed in AUTH48. 

Firstly, §5.2.5 says "A server MUST return an EPP error result code of 2102 if the "urgent" attribute is specified and the server does not support it".  I believe this is incorrect - the "urgent" attribute is _always_ specified, since it has a default value (i.e. "false").  Notwithstanding my comments above about the suitability of the 2102 error in the first place, this sentence needs to be qualified as "specified with a 'true' value". 

Secondly (although it is permitted by XML Schema) the examples might look better if they read <... urgent="true"> rather than <... urgent="1">, since the draft and schema always use "false" rather than "0" to represent the opposite value. 

kind regards, 

Ray