To:
"Michael Young" <myoung@ca.afilias.info>
Cc:
"'janusz'" <janusz@ca.afilias.info>, "'Edward Lewis'" <Ed.Lewis@Neustar.biz>, <ietf-provreg@cafax.se>
From:
Edward Lewis <Ed.Lewis@Neustar.biz>
Date:
Tue, 16 Aug 2005 17:25:22 -0400
In-Reply-To:
<E1E58Gv-0002nW-Rr@mail.libertyrms.com>
Sender:
owner-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.