Re: Flushing the Message Queue

[Daniel Manley <dmanley@tucows.com>]

But I think that the protocol should at least state that there is an 
OPTIONAL registry-specified timeout on poll nofications and that the 
out-of-band communication method, if there is one, is also 
registry-specific.

hmm... what about poll messages that have time-sensitive data (i.e. 
transfer notifications).  Should they be plucked from the message queue 
when the message is no longer applicable?  I'm hoping the answer is no - 
just cuz it sounds like a lot of work for the registrar to do.  Besides 
if the registrar didn't pick up the transfer notification in time, then 
they're clearly not polling enough.

Dan

Rick H Wesson wrote:

>Scott,
>
>Sounds like registry policy to me, the protocol does not need to specify
>how long they can be kept in queue. It should be up to the registry on how
>to handle it.
>
>-rick
>
>On Tue, 19 Jun 2001, Hollenbeck, Scott wrote:
>
>>While we're talking about messages exchanged between client and server, I
>>might as well bring this up: there's currently nothing in the protocol draft
>>that says anything about how a server should deal with messages that remain
>>queued for "a long time" due to a client either not retrieving their
>>messages or not acknowledging them.  I can't imagine a registry wanting to
>>keep messages enqueued for an indefinite amount of time, but I doubt that
>>it's a good idea to dequeue and throw messages away, either.
>>
>>One possibility could be that messages must be retained for some server- or
>>protocol-defined amount of time, and if not dequeued by the client before
>>the end of the retention period perhaps the server can dequeue them and send
>>them to the client via an out-of-band method like email, or make them
>>available via ftp, or who knows what else.
>>
>>Does anyone have any thoughts on the topic?
>>
>><Scott/>
>>
>