To:
janusz <janusz@ca.afilias.info>
Cc:
Edward Lewis <Ed.Lewis@Neustar.biz>, ietf-provreg@cafax.se
From:
Edward Lewis <Ed.Lewis@Neustar.biz>
Date:
Tue, 16 Aug 2005 19:04:28 -0400
In-Reply-To:
<430261E7.1090400@ca.afilias.info>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] 3730 <poll> Text Change Proposal
Let me give it a rest in my mind and think it over. Like my previous message - it's just a quibble about words. And sometimes it just takes a bit to settle in. At 18:00 -0400 8/16/05, janusz wrote: >Edward, >even if we have "SHOULD...that did not directly" and "MAY" sending >transfer and pending action <poll> notifications will be still >mandatory. The behaviour of those classes of <poll> messages is >determined not just by the text we are contemplating to change but >also by the text of 2.9.3.4 in 3730 and texts of 3.2.6 in 3731, 3732 >and 3733. Mandatory nature of transfer and pending action <poll> >notifications is acceptable because for both classes of messages the >protocol defines a way of passing object specific information so >interoperable implementations are feasible. For other more generic >classes of <poll> messages like auto-renewal, deletion, ... >meaningfull interoperable implementations are not feasible. >Therefore it is reasonable to use a weeker word than MUST in the >text of 2.9.2.3 in 3730. > >Cheers, > >Janusz Sienkiewicz > > >Edward Lewis wrote: > >> Yeah - my "objection" is purely in the sense that "can" is not >>covered by RFC 2119. I agree that the MUST causes heartburn, so I >>am fine with moving off that. And Janusz is right that we aren't >>talking "MUST NOT", so I am fine with that. >> >> But perhaps there is something I need to hammer out. In my text >>proposal, I have "MUST...that did not directly" and "MAY". I did >>this to make sure we still cover other "elements" that need to know >>of an action. I used MAY for all, as this means "its permitted, >>but not necessary." I.e., the initiator and responder ought to >>tolerate being told of a transfer request, but the other party must >>be told. >> >> Is that what we are going towards? >> >> At 16:42 -0400 8/16/05, Michael Young wrote: >> >>> Hi Edward >>> >>> "Service messages can be created for all clients affected by an action" >>> >>> Likewise I don't understand why this change would invalidate any existing >>> implementations, which is why Scott proposed it this way. MUST replaced >>> with SHOULD or "can" does not cause an issue with existing code. Retaining >>> "MUST" however puts us back to square one in resolving the raised >>>issue - so >>> I don't see leaving it unmodified as a viable option. >>> >>> I am perfectly happy to settle for softening it to a SHOULD versus "can" if >>> you find that language confusing. >>> >>> >>> Michael Young >>> -----Original Message----- >>> From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On >>> Behalf Of janusz >>> Sent: Tuesday, August 16, 2005 4:32 PM >>> To: Edward Lewis >>> Cc: ietf-provreg@cafax.se >>> Subject: Re: [ietf-provreg] 3730 <poll> Text Change Proposal >>> >>> Edward, >>> if your code conforms to the OLD text then it should conform to the NEW >>> version. Nobody is proposing replacing MUST with MUST NOT. >>> >>> The NEW text looks reasonable to me. It keeps existing EPP >>>deployments still >>> within protocol compliance. >>> >>> Cheers, >>> >>> Janusz Sienkiewicz >>> >>> >>> Edward Lewis wrote: >>> >>>> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >>>> >>>>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>>>> >>>>>> NEW: >>>>>> Service messages can be created for all clients affected by an >>>>>> action on an object that did not directly execute the action. For >>>>>> example, <transfer> actions can be reported to the client that has >>>>>> the authority to approve or reject a transfer request. Other >>>>>> methods of server-client action notification, such as offline >>>>>> reporting, are also possible and are beyond the scope of this >>>>>> specification. >>>>> >>>>> >>>>> >>>>> I like this, myself. Do we want to make the "can"s in there SHOULDs >>>>> instead? (I don't, really, but this is a pretty dramatic weakening >>>>> from the MUST we had before. Looking at the archives, there seem to >>>>> have been some people arguing for a much more important poll queue.) >>>> >>>> >>>> >>>> The change confuses me. Instead of relaxing from MUST to SHOULD, the >>>> change eliminates any "standards" words. >>>> >>>> The code base we have currently conforms to the "OLD" spec. We don't >>>> have a problem with it, hence we are reluctant to want to see the spec >>>> changed (in a way that is "not backwards compatible"). Not so much >>>> because we are against change but because we'd like to avoid having to >>>> redistribute software (or require new software be written by clients >>>> that contact us). >>>> >>>> It might be that the service message requirement as in "OLD" is >>>> suboptimal because it requires a service message go back to the >>>> initiator. But we'd rather keep this practice and just recognize (and >>>> then drop) the unnecessary message than have to replace software. >>>> Keeping in mind that the current way of passing messages is only >>>> sub-optimal, not unworkable. >>>> >>>> Perhaps there's a misunderstanding on my part of what problem the >>>> extraneous message causes. >>>> >>>> Still, I would have thought the new text would have been: >>>> >>>> Service messages MUST be created for all clients affected by an action >>>> on an object that did not directly execute the action, and MAY be >>>> created for others affected (including the initiator). For example, >>>> ... >>>> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.