To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>, Edward Lewis <Ed.Lewis@Neustar.biz>
CC:
<ietf-provreg@cafax.se>
From:
James Gould <jgould@verisign.com>
Date:
Mon, 29 Aug 2005 10:01:05 -0400
In-Reply-To:
<046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Microsoft-Entourage/11.1.0.040913
Subject:
Re: [ietf-provreg] 3730 <poll> Text Change Proposal
Scott, It looks good to me. -- JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com 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" <shollenbeck@verisign.com> > Date: Mon, 29 Aug 2005 09:23:04 -0400 > To: Edward Lewis <Ed.Lewis@Neustar.biz> > Cc: <ietf-provreg@cafax.se> > Subject: RE: [ietf-provreg] 3730 <poll> Text Change Proposal > >> -----Original Message----- >> From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >> Sent: Friday, August 26, 2005 4:16 PM >> To: Hollenbeck, Scott >> Cc: ietf-provreg@cafax.se >> 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- > >