Re: 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
[email protected]
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: <[email protected]>
Date: Thu, 25 Mar 2010 00:58:35 -0400
To: EPP Provreg <[email protected]>
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