Re: 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