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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp