[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Andrew Sullivan" <andrew@ca.afilias.info>, <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Tue, 30 Aug 2005 07:09:50 -0400
Content-class: urn:content-classes:message
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcWs0O5PUdVSeb+tR8umC+9wLgaUswAga2Ew
Thread-Topic: [ietf-provreg] 3730 <poll> Text Change Proposal
Subject: RE: [ietf-provreg] 3730 <poll> Text Change Proposal

> -----Original Message-----
> From: owner-ietf-provreg@cafax.se 
> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan
> Sent: Monday, August 29, 2005 3:22 PM
> To: ietf-provreg@cafax.se
> Subject: Re: [ietf-provreg] 3730 <poll> Text Change Proposal
> 
> On Mon, Aug 29, 2005 at 09:23:04AM -0400, Hollenbeck, Scott wrote:
> > 
> > NEW:
> > Service messages SHOULD be created for passive clients 
> affected by an
> > action on an object.  Service messages MAY also be created 
> for active
> 
> The SHOULD here makes me slightly nervous, but I don't have any
> principled objection.  I still think the mechanism is pretty
> inflexible, but this SHOULD gives me enough room, I think, to move if
> I have to.

Didn't you yourself suggest a SHOULD?:

http://www.cafax.se/ietf-provreg/maillist/2005-08/msg00053.html

> The third paragraph of the existing 2.9.2.3 also has this:
> 
> ---cut here---
> Servers MAY implement other mechanisms to dequeue and deliver
> messages if queue maintenance needs exceed server resource
> consumption limits.
> ---cut here---
> 
> We could take the conditional clause away, to yield, "Servers
> MAY implement other mechanisms to dequeue and deliver messages."
> That would again be consistent with the old language, and coupled
> with the changes Scott has suggested, would lead to a looser
> understanding of what the poll mechanism requires.

...but we already have suggest new text to make it clear that
alternatives are possible:

"Other methods of server-client action notification, such as offline
reporting, are also
possible and are beyond the scope of this specification."

The text in 2.9.2.3 exists to let people know that they can deal with
clients that don't retrieve queued messages however they wish.
Something to make that clear really should remain in the document.

-Scott-


Home | Date list | Subject list