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


To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
cc: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: Rick H Wesson <wessorh@ar.com>
Date: Tue, 19 Jun 2001 08:06:23 -0700 (PDT)
In-Reply-To: <DF737E620579D411A8E400D0B77E671D0187805D@regdom-ex01.prod.netsol.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: Flushing the Message Queue


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/>
>


Home | Date list | Subject list