Re: Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt

> On 8/9/2021 8:29 AM, Ned Freed wrote:
> >> On Sun, Aug 08, 2021 at 07:02:02PM +0200, Alessandro Vesely wrote:
> >> Nobody puts unstructured phrases into "Delivered-To".  There are no
> >> display names in this context, because the payload is derived
> >> exclusively from an envelope address.  The "phrase" bits are redundant
> >> and incompatible with current practice.
> >
> > Unfortunately this is not the case. Here's one example, from last year:
> >
> >    Delivered-to: mailing list [email protected]

> ahh, thanks.  That's an example of what I thought I'd seen but couldn't
> find this morning.

> > In any case, the real question, I think, is not whether or not examples can be
> > found of incompatible use of this field - they can - but whether we want to
> > require implementation to support what is best a rare usage. Speaking for
> > myself, I think the answer should be "no".

> Different semantics, within the framework of the same, email-address
> syntax, seems a relatively minor point to me, and is arguably covered
> adequately by the generic prose already in the draft, about the nature
> of the string.

I'm talking about syntax. Not semantics. Requiring that implementations parse
what is effectively a new string format - AFAIK there is no  other place in any
of our specifications where

   FWS *phrase Mailbox *phrase

is used - may not be a significant burden to folks who spend a lot of time
dealing with email syntax, but to people who just want to hack something
together using some random email routine library, it's an issue. Having looked
at a lot of code written this way, the likely outcome is that they will call
something that's "close", which will probably handle  the case without the
phrases but will fail or produce bogus output when they are.

And as far as semantics are concerned, your syntax assumes that the 
the prefix and suffix parts are not, in fact, part of the mailbox. That
may or may not be correct.

> On the other hand, the difference between allowing arbitrary text
> (phrase) in the field's payload seems a big deal to me.  As noted, it
> messes with parsing, given the absence of the usual delimiters.

> Having the spec formally exclude an existing practice is obviously a big
> deal.

When formalizing things we often exclude rare practices that greatly
complicate things, especially when those practices are semantically
ambiguous.

				Ned