To:
"Michael Young" <myoung@ca.afilias.info>
Cc:
"'Edward Lewis'" <Ed.Lewis@Neustar.biz>, "'janusz'" <janusz@ca.afilias.info>, <ietf-provreg@cafax.se>
From:
Edward Lewis <Ed.Lewis@Neustar.biz>
Date:
Tue, 16 Aug 2005 19:03:00 -0400
In-Reply-To:
<E1E59Jq-0005BD-G6@mail.libertyrms.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: [ietf-provreg] 3730 <poll> Text Change Proposal
At 17:49 -0400 8/16/05, Michael Young wrote: >Ed I don't see a problem with the "MAY" portion but how do you define >"others" - could this be, for example as remote as an entity outside the >system? Others (admittedly a poor use of the term) = those who in the old spec are told that don't need to be told. For example, the initiator. I don't mean to expand who can/ought to be told. Just using the MAY to cover the now MUST actions that we no longer want to require yet don't want to outlaw. Rest assured, this is all a quibble about the terms. I think we agree what we want. > > > >>> MAY be created for others affected (including the initiator).. > > > > > > >Michael Young >-----Original Message----- >From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >Sent: Tuesday, August 16, 2005 5:25 PM >To: Michael Young >Cc: 'janusz'; 'Edward Lewis'; ietf-provreg@cafax.se >Subject: RE: [ietf-provreg] 3730 <poll> Text Change Proposal > >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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.