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

[bernie@ietf.hoeneisen.ch]

Hi James,

On Sun, 21 Feb 2010, Gould, James wrote:

> The implementation note did not state anything about the contents of the 
> greeting of the server

That's what I said. Therefore the greeting might be different from login 
response (s. below in my original email).

> doing any kind of hiding of supported extensions. 

As I understand the hiding happens at login response (as it is defined now 
in draft-gould-rfc4310bis-05).

> The point of the note was to address how the server will handle clients 
> that support 1.0, 1.1, or both. 

I understand this, and it's good to have this section about transition 
considerations.

> It is assumed without having to restate it that the server MUST support 
> RFC 5730.

As I said, the proposal is compliant with RFC 5730, however it might 
cause pain to implementors.

cheers,
  Bernie

> 
> ----- 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.
> >
> >
> >
> 
> 
>