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

On 8/12/2021 11:36 AM, Ned Freed wrote:
>> On 8/9/2021 8:29 AM, Ned Freed wrote:
>>> 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.


I would very much prefer the syntax to just be Mailbox. But what with 
the excited concern for covering established practice, this alternative 
syntax seemed necessary.

However, given your enthusiastic prompting -- which I will take as 
support -- I'll revert the syntax, but add some text noting the issue.

Anyone objecting strongly is encouraged to comment with explanations for 
why just having the field contain a string in the form of an email 
address is not sufficient.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net