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

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 02 Dec 2021 10:52:54 +0000

Hi Dave/Ned,

Catching up with this thread:

On Tue, Nov 30, 2021, at 7:10 PM, Dave Crocker wrote:
> 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]
>> 
>>> On 11/24/2021 5:28 AM, Alexey Melnikov wrote:
>>>> 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.
>> 
>>> 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.
>> 
>> 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.
>
> 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. ...
>> 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.
>
> 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.

This is almost fine with me, except for one SHOULD. The "SHOULD be treated as equivalent" text is wrong (too weak), it has to be "MUST be treated as equivalent" as per the rest of this ticket. So with that in mind hopefully the last version:

 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 MUST be treated as 
 equivalent. A sending system SHOULD transmit the form that uses the 
 minimum quoting possible.

Best Regards,
Alexey

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Dec 2021 07:27:49 -0800

> This is almost fine with me, except for one SHOULD. The "SHOULD be treated as equivalent" text is wrong (too weak), it has to be "MUST be treated as equivalent" as per the rest of this ticket. So w…

ahh.  yes.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Thu, 02 Dec 2021 07:27:00 -0800 (PST)

Comments inline.

> > word, and since this isn't a person and it isn't a location, I'll

Agreed.

> > refer to singular case, when reasonable.

WFM.

> >> provide a standardized way to indicate such notwithstanding.

This was just an observation on my part: While I think the non-replyble
address issue is real, this is absolutely not the time or place to address it.

> > removed that potential distraction

Good.

> This is almost fine with me, except for one SHOULD. The "SHOULD be treated as
> equivalent" text is wrong (too weak), it has to be "MUST be treated as
> equivalent" as per the rest of this ticket. So with that in mind hopefully the
> last version:

Good point.

>  minimum quoting possible.

I like it.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Dec 2021 12:34:11 -0500

--On Thursday, December 2, 2021 10:52 +0000 Alexey Melnikov
<[email-masked]> wrote:

>>>> [email-masked] Organization: Brandenburg InternetWorking
>>>> To: [email-masked]
>...
 
> This is almost fine with me, except for one SHOULD. The
> "SHOULD be treated as equivalent" text is wrong (too weak), it
> has to be "MUST be treated as equivalent" as per the rest of
> this ticket. So with that in mind hopefully the last version:
> 
> 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 MUST be treated as 
>  equivalent. A sending system SHOULD transmit the form that
> uses the   minimum quoting possible.

I can live with this and have spliced it into -07.  That is
subject to further discussion, of course, but I hope to post -07
today or tomorrow and am unlikely to fuss with this further
before it goes up.    

However, I am (as individual, not as editor) a little queasy
about dropping the, admittedly awkward, "expects to receive
mail" terminology entirely.   The problem starts with <mailbox>
and <local-part>, pieces of RFC 821 syntax that were not
harmonized with the corresponding mail header syntax until at
least RFC 2821/5322 (and maybe later -- I vaguely remember some
additional tweaks in 5321/5322). It was clearly understood then,
and remains true today, that the name of the <mailbox> as
transmitted over the network was necessarily the same, or even
similar to, that actual name of the "mailbox" file (or
directory) in the relevant host.  Whether we preserve the
distinction I/we were trying to make in 5321 we may want to be a
bit more clear in the above that we are stalking about a piece
of syntax, the abstract address of the mailbox on, and facing,
the Internet, and not the name by which that object would be
recognized on the local system.  And, if the local system allows
getting mail to that object without going through SMTP, we
presumably don't care.  This is probably less of an issue now
than if was before we explicitly introduced Submission Servers,
but we should not discard the hint about a distinction without
giving it a few minutes of collective thought.

best,
  john