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

["Gould, James" <JGould@verisign.com>]

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

Bernie,

The implementation note did not state anything about the contents of the greeting of the server doing any kind of hiding of supported extensions.  The point of the note was to address how the server will handle clients that support 1.0, 1.1, or both.  It is assumed without having to restate it that the server MUST support RFC 5730.

----- Original Message -----
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
To: Gould, James
Cc: EPP Provreg <ietf-provreg@cafax.se>
Sent: Sun Feb 21 12:14:38 2010
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-05.txt Submitted for Review

Hi James

Thanks for the update!

Concerning the transition considerations:

    3.  The version of <secDNS:infData> to return for a domain info
        command SHOULD be defined by the secDNS extURI's included in the
        EPP login services using the following mapping:
    [...]

- This does not specify the behavior of Hello & Greeting (RFC 5730,
2.3/2.4), where extensions are queried too. This might lead to
inconsistencies in the extension announcements of an EPP server.

- Furthermore I consider it a bad idea, if EPP servers hide extensions
from EPP clients. While such behavior is not prohibited by RFC 5730, it
potentially introduces inconsistencies in the feature negotiation process.

- The text (as it is) leads to confusion among implementors.

For these reasons, I suggest to replace the 3rd bullet point by a
recommendation, that the EPP client SHOULD always use 1.1, if mutually
supported by EPP server and client (or sth similar).
(The EPP server should always be honest about his supported extensions.)

cheers,
  Bernie


On Wed, 17 Feb 2010, James Gould wrote:

> All,
>
> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-05.txt which includes the feedback that I received so far.  I included an open
> question on the inclusion of the ttl element to the AD for guidance.  Please let me know if you have any feedback to the latest draft.
>
> Thanks,  
>
> --
>
>
> 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.
>
>
>