Re: [Asrg] Re: draft-hall-inline-dsn-01

["Eric A. Hall" <ehall at ehsco.com>]

On 1/26/2007 11:22 PM, Claus Assmann wrote:
> [[Is this the appropriate list to discuss this topic?]]

I would imagine that ietf-smtp at imc.org is the right place to talk about
the protocol, particularly if its going to be advocated for standards
track, but I'll deal with questions where I find them

> 1. the name is confusing and the new name isn't very helpful either.
> Let's call it something like "Delayed-RCPT-Status" (DRS) or
> "RCPT-Status-After-Dot" (RSAD).

deferred-rcpt-responses would be most descriptive but that's a bit greedy
given that command-line space is fixed. I don't really care what people
call it. Robots will be the 99.9999% use case and they won't care either.
Probably some kind of acronym like DRR or whatever would be most efficient
as far as that goes.

Best outcome I can see here is for a plurality of implementors to request
a specific name. Otherwise we are all going to be wanting our pet name so
any name is as bad as any other.

> 2.  This is another confusing part:
> 
>      6.   The End-of-Data Response Codes
>        6.1.  The 352 Response Code
>        6.2.  The 353 Response Code
>        6.3.  The Per-Recipient Response Codes
>        6.4.  The Final Response Code
> 
> My understanding is:
> 352 is used for RCPT:
>   6.1.    The 352 Response Code
> 
>      The 352 response code is used by a server to indicate that the
>      mailbox address specified in the associated RCPT TO command
>                                                  ^^^^
> 
> 353 is used for end of data.
> 
> So it should be:
> 
>      6.   Additional RCPT Response Code
>        6.1.  The 352 Response Code
>      7.   The End-of-Data Response Codes
>        7.1.  The 353 Response Code
>        7.2.  The Per-Recipient Response Codes
>        7.3.  The Final Response Code
> 
> 
> BTW: it probably should be
>      7.   The End of Mail Data Response Codes
> to match RFC 2821.

I changed the section 6 heading in the current draft. The additional
breakdown looks reasonable and appropriate so I'll do that in the next
edition if there's any real interest in pursuing this further.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg