Subject: [Emailcore] Ticket #21: G.9. Revisiting Quoted Strings

From: Alexey Melnikov <[email-masked]>
Date: Wed, 24 Nov 2021 13:28:02 +0000

Hi all,

Based on IETF 112 discussion I suggest the following changes to address 
this ticket:

In Section "4.1.2. Command Argument Syntax", the 1st paragraph after the 
ABNF syntax reads:

    While the above definition for Local-part is relatively permissive,
    for maximum interoperability, a host that expects to receive mail
    SHOULD avoid defining mailboxes where the Local-part requires (or
    uses) the Quoted-string form or where the Local-part is case-
    sensitive. For any purposes that require generating or comparing
    Local-parts (e.g., to specific mailbox names), all quoted forms MUST
    be treated as equivalent, and the sending system SHOULD transmit the
    form that uses the minimum quoting possible.

Suggestion to add to the end of the above paragraph:

    For example, the following 3 Local-parts are semantically equivalent
    and must compare equal: "ab cd ef", "ab\ cd ef" and "ab\ \cd ef".
    Similarly, "fred" and fred must compare equal. White space reduction
    MUST NOT be applied to Local-part by intermediate systems.

(John, I think your were not quite happy with "semantically equivalent", 
but "syntactically equivalent" is not right here, as all these forms and 
not syntactically the same. I am happy for you to come up with better 
wording.)

In Section "4.1.2. Command Argument Syntax", the 3rd paragraph after the 
ABNF:

    Note that the backslash, "\", is a quote character, which is used to
    indicate that the next character is to be used literally (instead of
    its normal interpretation). For example, "Joe\,Smith" indicates a
    single nine-character user name string with the comma being the
    fourth character of that string.

Suggestion to move it before the 1st paragraph after the ABNF (so that 
it introduces \ escape character).

Best Regards,

Alexey

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Nov 2021 06:29:08 -0800 (PST)

>     MUST NOT be applied to Local-part by intermediate systems.

OK... So what, exactly, is white space reduction?  AFAICT the term doesn't
appear elsewhere in the document. Clearly it's a bad thing because systems MUST
NOT do it, so I think we need to be really clear as to what it is. 

If it refers to compressing whitespace out of local parts, then yes, I can
agree that intermediate systems should not be doing that.. But if
canonicalization from "fred" to fred is included, then (a) You need a different
term, and (b) I'm not sure prohibiting submission servers - which are
intermediate sytems - is necessarily a good idea.

> not syntactically the same. I am happy for you to come up with better

I think  "semantically equivalent" is about as good as it gets.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Nov 2021 06:53:50 -0800

>     form that uses the minimum quoting possible.

1. The concept of 'expects to receive mail' seems a bit odd.  It implies 
that we support the circulation of email addresses that don't work. If 
there is a benefit in having an Internet standard for email that defines 
an email address that isn't valid, what is it?  Otherwise, I suggest 
dropping this qualifier.

2. The 'SHOULD' language could be simpler and more direct.

So, perhaps:

      For maximum interoperability, a Local-part SHOULD NOT be defined
      using the Quoted-string form and SHOULD NOT have a Local-part that
      is case-dependent.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Nov 2021 20:43:12 -0500

--On Wednesday, November 24, 2021 13:28 +0000 Alexey Melnikov
<[email-masked]> wrote:

> Hi all,
> 
> Based on IETF 112 discussion I suggest the following changes
> to address this ticket:
> 
> In Section "4.1.2. Command Argument Syntax", the 1st paragraph
> after the ABNF syntax reads:
> 

> (John, I think your were not quite happy with "semantically
> equivalent", but "syntactically equivalent" is not right here,
> as all these forms and not syntactically the same. I am happy
> for you to come up with better wording.)

Above added as written except, for consistency, I believe the
first "must" should be a "MUST" and have tentatively made that
change.  My only suggestion for better wording is to not qualify
"equivalent" at all, e.g., to just say "local-parts are
equivalent and..."  or even "local-parts are equivalent under
the quoting rules and..."  

> In Section "4.1.2. Command Argument Syntax", the 3rd paragraph
> after the ABNF:
> 
> Suggestion to move it before the 1st paragraph after the ABNF
> (so that it introduces \ escape character).

Done.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Nov 2021 07:48:43 -0800

Haven't seen a response to this...

-------- Forwarded Message --------
Subject: Re: [Emailcore] Ticket #21: G.9. Revisiting Quoted Strings
Date: Wed, 24 Nov 2021 06:53:50 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]

So, perhaps:

d/

-- 
Emailcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emailcore

---

From: Ned Freed <[email-masked]>
Date: Tue, 30 Nov 2021 07:59:01 -0800 (PST)

>        using the Quoted-string form and SHOULD NOT have a Local-part that

While I agree that the "expects to receive mail" phrase is odd and could stand
to be replaced, this isn't the right text because it elides over the issue of
quote equivalency. The original text appears to have been constructed with this in
mind. My suggestion would be a smaller change along the lines of:

      While the above definition for Local-part is relatively permissive,
      for maximum interoperability, a mailbox SHOULD NOT be defined whose
      Local-part requires (or uses) the Quoted-string form or where the
      Local-part is case-sensitive. For any purposes that require generating
      or comparing Local-parts (e.g., to specific mailbox names), all quoted
        be treated as equivalent, and the sending system SHOULD transmit the
        form that uses the minimum quoting possible.

And FWIW, we absolutely do support the circulation of addresses that
intentionally do not work. It's not like we have a choice: Non-replyable
messages are quite common; the fact that we don't provide a standardized
way to indicate such notwithstanding.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Nov 2021 11:10:43 -0800

On 11/30/2021 7:59 AM, Ned Freed wrote:

>> -0800 From: Dave Crocker <[email-masked]> Reply-To:
>> [email-masked] Organization: Brandenburg InternetWorking To:
>> [email-masked]
> 
>>> While the above definition for Local-part is relatively
>>> permissive, for maximum interoperability, a host that expects to
>>> receive mail SHOULD avoid defining mailboxes where the Local-part
>>> requires (or uses) the Quoted-string form or where the Local-part
>>> is case- sensitive. For any purposes that require generating or
>>> comparing Local-parts (e.g., to specific mailbox names), all
>>> quoted forms
>> MUST
>>> be treated as equivalent, and the sending system SHOULD transmit
>>> 
>> the
>> 1. The concept of 'expects to receive mail' seems a bit odd.  It
>> implies that we support the circulation of email addresses that
>> don't work. If there is a benefit in having an Internet standard
>> for email that defines an email address that isn't valid, what is
>> it?  Otherwise, I suggest dropping this qualifier.
> 
> While I agree that the "expects to receive mail" phrase is odd and
> could stand to be replaced, this isn't the right text because it
> elides over the issue of quote equivalency. The original text appears
> to have been constructed with this in mind. My suggestion would be a
> smaller change along the lines of:
> 
> Local-part is case-sensitive. For any purposes that require 
> generating or comparing Local-parts (e.g., to specific mailbox
> names), all quoted be treated as equivalent, and the sending system
> SHOULD transmit the form that uses the minimum quoting possible.

Almost wfm.  A few editorial changes suggested...

1. The 'whose' and 'where' probably should be changed to use the same 
word, and since this isn't a person and it isn't a location, I'll 
suggest 'with'.

2. singular vs. plural -- I've come to believe that specification 
language tends to be simpler and clearer when sentences are made to 
refer to singular case, when reasonable.

3. The 'For any purpose" sentence reads at least awkwardly.  In 
addition, I am not sure it means to tread quoting as equivalent when 
/generating/ a Local-part.

3. small typos fixed

4. ...
> intentionally do not work. It's not like we have a choice:
> Non-replyable messages are quite common; the fact that we don't
> provide a standardized way to indicate such notwithstanding.

My concern is with the idea that syntactic differences might provide a 
signal about utility of the email address. The issue, then, is with the 
focus of the language.

Embedding the operational concept of intentionally not-working, into 
this sort of deep, definition specification, is the problem.  It isn't 
needed and I think it is ill-advised.  Hence I'm glad that your version 
removed that potential distraction

So...

While the above definition for Local-part is relatively permissive,
for maximum interoperability, a mailbox SHOULD NOT be defined with
Local-part requiring (or using) the Quoted-string form or with the
Local-part being case-sensitive. Further, when comparing a Local-part 
(e.g., to a specific mailbox name), all quoting SHOULD be treated as 
equivalent. A sending system SHOULD transmit the form that uses the 
minimum quoting possible.

d/