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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 15 Aug 2005 13:27:56 -0400

OK, we've been talking about the text in 3730 that describes the <poll>
command for a few days.  Let me throw out a straw man text change that
builds on the one first proposed by Jim Gould.

OLD (section 2.9.2.3):
Service messages MUST be created for all clients affected by an action
on an object.  For example, <transfer> actions MUST be reported to both
the client that requests an object transfer and the client that has the
authority to approve or reject the transfer request.

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.

Fire away!

-Scott-

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Aug 2005 14:04:03 -0400

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

A
-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Aug 2005 16:02:07 -0400

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

---

From: janusz <[email-masked]>
Date: Tue, 16 Aug 2005 16:32:03 -0400

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:

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

---

From: "Michael Young" <[email-masked]>
Date: Tue, 16 Aug 2005 16:42:53 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of janusz
Sent: Tuesday, August 16, 2005 4:32 PM
To: Edward Lewis
Cc: [email-masked]
Subject: Re: [ietf-provreg] 3730 <poll> Text Change Proposal

Edward,

The NEW text looks reasonable to me. It keeps existing EPP deployments still
within protocol compliance.

Cheers,

Janusz Sienkiewicz

Edward Lewis wrote:

>>>  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.
>>
>>
> on an object that did not directly execute the action, and MAY be 
> created for others affected (including the initiator).  For  example, 
> ...
>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Aug 2005 17:25:22 -0400

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?

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Aug 2005 17:22:02 -0400

> change eliminates any "standards" words.

I think others have pointed out that any relaxing from MUST will not
make existing code incompatible with the resulting document.  

I don't want to attribute anything to Scott (since I have no
knowledge in this matter -- or in any other, some would argue!), but
I have a suspicion that the use of "can" instead of any of the magic
standards words is a feature, not a bug.  I think it's a good idea,
because it neatly sidesteps the problems we've identified in the use
of the poll queue, and doesn't potentially embroil us in other
standards issues.

> spec changed (in a way that is "not backwards compatible").  Not so 

I can understand a desire to avoid changes that cause
incompatibilities (even if this isn't such a case).  But I think this
is a weak plank on which to build an argument that the protocol needs
to remain unchanged.  The whole point of PROPOSED STANDARD after all
is that we're not completely committed to that design, precisely
because we're aware that we might not have had all the operational
experience necessary to get things quite right when folks were first
designing the protocol.  That isn't to say I think we should embrace
change for its own sake; I prefer to leave the protocol alone, to the
extent possible, and use extensions where we can, even if the result
is not the most elegant approach when considered in isolation.  I'm
just made awful nervous by a suggestion that we shouldn't fix things
we find need fixing (if we do -- and I recognise the jury is still
out) because we have some installed base.  It'll be much harder to
fix things later, with a bigger installed base.

A

---

From: "Michael Young" <[email-masked]>
Date: Tue, 16 Aug 2005 17:49:58 -0400

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:[email-masked]] 
Sent: Tuesday, August 16, 2005 5:25 PM
To: Michael Young
Cc: 'janusz'; 'Edward Lewis'; [email-masked]
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.

At 16:42 -0400 8/16/05, Michael Young wrote:
>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
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of janusz
>>>  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 
>> (and  then drop) the unnecessary message than have to replace software.
>>  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,  ...
>>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Aug 2005 17:53:56 -0400

> Is that what we are going towards?

I hope not, because I'm trying to make the whole thing optional (if
we don't take the other approach I suggested).  My experience of
clients' actual use of the message queue is that many of them simply
don't.  I want to make it more useful for them, in the hope that
they'll use it and spare me creating more needless reports.

A

---

From: janusz <[email-masked]>
Date: Tue, 16 Aug 2005 18:00:07 -0400

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Aug 2005 19:04:28 -0400

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Aug 2005 19:03:00 -0400

>"others" - could this be, for example as remote as an entity outside the

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.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 26 Aug 2005 16:15:32 -0400

Revisiting this...

>are beyond the scope of this specification.

Where I am getting confused is that "Service messages" is used twice 
in the document and not explicitly defined.  Not that the lack of a 
definition is a problem I want to see solved, but looking at the 
above text out of context threw me for a loop.

What I think we want is to document that servers don't have to create 
"special" responses to return to the sender of a requested action. 
What I hope that we mean to say is that servers ought to let other 
clients know of actions "happening behind their back" where the 
target of the action is of some interest to the other clients.

My goal is also to warn the implementers of client software that 
there may be "special" responses coming to them that are superfluous. 
I.e., the servers that conform to the OLD text won't bring down a 
client conforming to the NEW text.

That's why I suggest a "SHOULD/MUST" send to others involved, "MAY" 
to the requestor.  (And that clients MUST be able to deal with the 
message appropriately.)