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

[James Gould <jgould@verisign.com>]

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

Klaus,

I incorporated your feedback in 02 of the  draft at the URL below.  Please review for feedback.

http://www.ietf.org/id/draft-gould-rfc4310bis-02.txt

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.

---

From: Klaus Malorny <Klaus.Malorny@knipp.de>
Date: Wed, 23 Dec 2009 11:40:35 -0500
To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-01.txt Submitted for Review

On 21/12/09 19:13, James Gould wrote:
> Klaus,
>
> [...]

>>  While a standard should be concise, it should avoid implicit
> assumptions in my
>>  humble opinion. Maybe I am wrong, but I can't remember that RFC 5730
> or RFC
>>  3735
>>  say anything about the semantics of not including a certain extension.
> Also,
>>  giving the existence of an extension element any meaning limits the
> forward
>>  compatibility of the extension itself. For example, if someone thinks to
>>  extend
>>  RFC 3915 to report something in addition to the <rgp:rgpStatus>, then the
>>  semantics of the infData element would have to be changed regarding the
>>  existence.
>
> I’m really not sure if there is any defined extension points for an
> extension. I can add some global statement to the draft around the
> meaning of the inclusion or exclusion of the extension, where the
> remainder of the draft assumes that the extension is only included for
> commands or responses when there is data relevant to the extension to
> pass along with one or two examples. Does this meet your request?
>

Yes, this would be IMHO sufficient.

>>  I cannot agree. RFC 2119 says regarding "MUST":
>>
>>  1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
>>  definition is an absolute requirement of the specification.
>>
>>  Although I am not a native English speaker, this seems to be pretty
> clear to
>>  me
>>  that there may not exist any hidden assumptions. There is no
> comparative to
>>  "absolute". And it is no excuse for me that other EPP related RFCs do the
>>  same.
>>  Their wording has been the source for confusion more than once ;-)
>>
>
> I personally have not been confused, but does a global statement in the
> draft meet this request as well? I can’t change other RFC’s, so I will
> look to add some clarity in a global statement.

Yes, I think so.

>[...]
>
>
> JG

Regards,

Klaus