RE: [ietf-provreg] 3730 <poll> Text Change Proposal

["Michael Young" <myoung@ca.afilias.info>]

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?



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