To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc:
<ietf-provreg@cafax.se>
From:
Edward Lewis <Ed.Lewis@Neustar.biz>
Date:
Fri, 26 Aug 2005 16:15:32 -0400
In-Reply-To:
<046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] 3730 <poll> Text Change Proposal
Revisiting this... At 13:27 -0400 8/15/05, Hollenbeck, Scott wrote: >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! 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.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.