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

Re: draft-gellens-on-demand-03.txt



At 12:47 19/03/98 -0800, Randall Gellens wrote:
>At 3:33 PM +0000 3/19/98, Graham Klyne wrote:
>
>>I note that in normal use, SMTP may allow up to 5 days for relaying of a
>>message to be accomplished, with retries at appropriate intervals
>>throughout this period.
>
>There is nothing in the standards that I am aware of which mandates a
>five day period.
[...]

Indeed.  Hence "in normal use", to reflect the guidance of RFC1123 -- maybe
I should have said "in recommended use".  And my use (below) of "impose
[...] restriction" was ill-chosen.

>>Is it your intention to impose any similar restriction on how long a
>>message may be held for collection by the ATRN mechanism before it may be
>>assumed that that the message is undeliverable?
>
>I don't see that this needs to be specified in the standard.  I expect
>implementations will generally make this configurable, and sites will
>set it to meet their needs.  It's even less an issue for ODMR than SMTP
>in general, because typically there is a preexisting relationship
>between both sides in ODMR, while anyone can send an SMTP message to
>anyone (in general).

Again, agreed.  But in the same way that it's useful for RFC1123 to provide
guidance, would the fact that the relationship here (between relay and
next-hop) is different to common SMTP not suggest some alternate guidance
is appropriate?

>>Or is it your intention that delivery to an ATRN system will be regarded as
>>a completed delivery in the same way as delivery to a mailbox server?  In
>>which case, I think that some discussion on the appropriate (and
>>inappropriate) deployments for this scheme would be helpful.
>
>I think it is important that final delivery not occur when the message
>is received by the provider-side.  That's kind of the point; the
>message is still in-transit, and will be relayed using ODMR (and SMTP)
>to the client side, which then delivers it.

Good.

I am not trying to argue the technical content, just to clarify it.

GK.
---


------------
Graham Klyne