To:
Patrick <patrick@gandi.net>
cc:
ietf-provreg@cafax.se
From:
Eric Brunner <brunner@nic-naa.net>
Date:
Sat, 01 Sep 2001 12:29:55 -0400
In-Reply-To:
Your message of "Sat, 01 Sep 2001 17:28:21 +0200." <20010901172821.B31944@nohope.patoche.org>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: Message Pushing and TCP Transport
>> How many messages are waiting? > > The value of the count attribute. > Reading the draft : > - An OPTIONAL <msgQ> element containing a "count" attribute that > identifies the number of service messages queued for client > retrieval. So no messages are deleted from or added to the queue subsequent to the (atomic) set of events in which a value is written to msgQ->cnt, and the (atomic) set of events when, to use your original, the registrar "gets them[.] (immediately or later at its convenience)"? As a state machine recovery mechanism such locks are useful when transition takes place from the normal state management mechanism (push, usually), to the recovery-and-reset state management mechanism (poll, usually, ignoring the provreg epp/rrp sense of directionality). Is this what you think we have in the semantics of msgQ and its two associated types, the unsignedLong and dateTime? Just to be sure, and I'll make this my last question to you, how many messages are waiting? Eric