[Top] [All Lists]

Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]

2009-03-01 18:46:45


[Local-part. Case sensitivity.  Globally opaque.  Where to interpret.]

I'm fixing the email-arch draft, according to the various notes that point out errors, confusion or poor wording. But I'm stymied by the several notes on the topic of local-part, some of which discussed language or issues that seem to differ from what is in email-arch.

Anyhow, here's what exists now:

RFC 5321

2.3.11. Mailbox and Address

...the local-part MUST be
   interpreted and assigned semantics only by the host specified in the
   domain part of the address.


2.4. General Syntax Principles and Transaction Model

   Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
   and extension name keywords) are not case sensitive, with the sole
   exception in this specification of a mailbox local-part
   The local-part of a mailbox MUST BE treated as case sensitive.
   Therefore, SMTP implementations MUST take care to preserve the case
   of mailbox local-parts.  In particular, for some hosts, the user
   "smith" is different from the user "Smith".  However, exploiting the
   case sensitivity of mailbox local-parts impedes interoperability and
   is discouraged.

RFC 5322

3.4.1. Addr-Spec Specification

   The local-part portion is a domain-dependent string.  In addresses,
   it is simply interpreted on the particular host as a name of a
   particular mailbox.


<t>The portion to the left of the at&nbhy;sign contains a
        string that is globally opaque and is called the
        &lt;local&nbhy;part&gt;. It is to be
        interpreted only by the entity specified by the address's
        domain name. Except as noted later in this section all
        other entities MUST treat the
        &lt;local&nbhy;part&gt; as an uninterpreted
        literal string and MUST preserve all of its original
        details. As such its public distribution is equivalent to
        sending a Web browser "cookie" that is only interpreted
        upon being returned to its creator.</t>

I think the current text in the draft accurately reflects the scope and formal semantics of local-part. The draft does not confront the apparent contradiction between "MUST BE treated as case sensitive" and "case sensitivity of mailbox local-parts impedes interoperability and is discouraged" in RFC 5321.

Since the latter is not explicitly normative, I thought it acceptable for email-arch to stick with the formal view.

If someone thinks email-arch should have different text on this topic, please suggest some.



  Dave Crocker
  Brandenburg InternetWorking

<Prev in Thread] Current Thread [Next in Thread>