Re: 3730 <poll> Text Change Proposal

Scott,

It looks good to me.

-- 

JG 

James F. Gould
VeriSign Naming and Directory Services
[email protected]

This message is intended for the use of the individual or entity to which it
is addressed, and may contain information that is privileged, confidential
and exempt from disclosure under applicable law. Any unauthorized use,
distribution, or disclosure is strictly prohibited. If you have received
this message in error, please notify sender immediately and destroy/delete
the original transmission


> From: "Hollenbeck, Scott" <[email protected]>
> Date: Mon, 29 Aug 2005 09:23:04 -0400
> To: Edward Lewis <[email protected]>
> Cc: <[email protected]>
> Subject: RE: [ietf-provreg] 3730 <poll> Text Change Proposal
> 
>> -----Original Message-----
>> From: Edward Lewis [mailto:[email protected]]
>> Sent: Friday, August 26, 2005 4:16 PM
>> To: Hollenbeck, Scott
>> Cc: [email protected]
>> Subject: Re: [ietf-provreg] 3730 <poll> Text Change Proposal
>> 
> 
> [snip]
> 
>> 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.)
> 
> OK, so how about this:
> 
> 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 SHOULD be created for passive clients affected by an
> action on an object.  Service messages MAY also be created for active
> clients that request an action on an object, though such messages MUST
> NOT replace the normal protocol response to the request.  For example,
> <transfer> actions SHOULD 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.
> 
> -Scott-
> 
>