Subject: [EAI] draft-ietf-eai-popimap-downgrade-03.txt

From: [email-masked]
Date: Tue, 15 Nov 2011 11:11:59 +0900 (JST)

Hi, all,

I updated draft-ietf-eai-popimap-downgrade to -03.

This is changes from -02 and what I want to decide for future updates.
same as  http://www.ietf.org/proceedings/82/slides/eai-1.pdf

Please check the draft and diffs at:
       http://tools.ietf.org/html/draft-ietf-eai-popimap-downgrade-03

Changes from -02 to -03 are:
  1. Added "Updates: 5322 (if approved)" in header
     "Section 3.  Updating RFC 5322" already appeared in -02
  2. Added Message-ID downgrading
  3. Treated Unknown Header Fields as unstructured
  4. Updated and fixed IANA considerations
  5. Added one sentence to Security Considerations
  6. Updated TYPED address downgrading
  7. Updated the example
  8. Some changes

2. Message-Id Downgrading
  RFC 5322 Section 3.6 describes that Min number of Message-Id, In-Reply-To,
   References, Resent-Message-Id fields is zero
  These header fields may be removed (with encapsulation)
  Defined new Downgraded header fields
     Downgraded-Message-Id, Downgraded-Resent-Message-Id
     Downgraded-In-Reply-To, Downgraded-References
  Defined Message-Id header downgrading as ENCAPSULATION Downgrading

3. Treated Unknown Header Fields as unstructured
  Previously, Unknown Header Fields was Encapsulated to new header field
   which field name is the concatenation of "Downgraded-" and the original name
   Downgraded-X-Unknown:
  RFC 5322 Section 3.6.8 "Optional Fields" says
   Field unspecified in this document is optional-field 
   optional-field  =   field-name ":" unstructured CRLF
  Unknown Header Field Downgrading was changed as UNSTRUCTURED Downgrading
  Is this change OK ?

4. IANA considerations
  RFC 5504 defined many Downgraded header fields
    All of them are unused by recent standard track documents
  Update them to replace "experimental" with "obsoleted" and
    to reference this document (Or framework document ?)
  RFC 5504 requested refusing any "Downgraded-" registrations 
    It may be useless, and new updating text required
  Added new 6 Downgraded- header fields
    Message-ID related and missed TYPED address headers
  Need more fixes

5. Secutiry Considerations
  Added one sentence
    Existing clients do not know new From: and Sender: header fields syntax
    updated by Section 3 and may get wrong when they confront<group> syntax
    in From: and Sender: fields.

6. Updated TYPED address downgrading
  Added missing header fields definition
    Downgraded-Original-Recipient:
    Downgraded-Final-Recipient:

TODO
  Commented by Chairs, but no time to update to -03
    Updating header fields definition and IANA Considerations

  Compatible to RFC 5504
    Compatible with IANA Registry:
      http://www.iana.org/assignments/message-headers/perm-headers.html
  New IANA request format

I have new proposal
  <addr-spec> is downgraded as "Internationalized Address" ENCODED-WORD "Removed:;"
  May I change it as ENCODED-WORD ":;" ?

  Reason
    It's easy and simple to implement
    People who need internationalization cannot understand
      "Internationalized Address removed".
    With/Without ""Internationalized Address removed",
    it is a group syntax and the receiver cannot reply.

I want to make questions for WG members,
  1. Is it OK that treating Unknown Header Fields as unstructured ?
  2. Who obsoletes header fields defined by RFC 5504 ?
      (framework ? This document ?)
  3. Is removing "Internationalized Address removed" OK ?

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

> From: [email-masked]
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF.
> 
> 	Title           : Post-delivery Message Downgrading for Internationalized Email Messages
> 	Author(s)       : Kazunori Fujiwara
> 	Filename        : draft-ietf-eai-popimap-downgrade-03.txt
> 	Pages           : 19
> 	Date            : 2011-10-31
> 
>    The Email Address Internationalization (UTF8SMTP) extension allows
>    UTF-8 characters in mail header fields.  POP and IMAP servers support
>    internationalized email messages.  If a POP/IMAP client does not
>    support Email Address Internationalization, POP/IMAP servers cannot
>    send Internationalized Email Headers to the client and cannot remove
>    the message.  To avoid the situation, this document describes a
>    conversion mechanism for internationalized Email messages to be
>    traditional message format.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-eai-popimap-downgrade-03.txt
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Nov 2011 05:29:24 +0100

>       http://tools.ietf.org/html/draft-ietf-eai-popimap-downgrade-03

Hi, I don't get the idea of mail "from" a group.  You can only send
mail "to" a group, including Reply-To:.  It is just a funny tag for
zero or more recipients.  And the cases "zero" or "more than one" are
not what you want for a Sender: or Resent-Sender:.

Using <address> for *Sender: instead of <address-list> for *From:
does not help with the "zero" or "more than one" cases, because
address = mailbox / group

You specify downgrade algorithms for MAILBOX and GROUP, and that's
enough for the new "groupified" *From: and Sender:.  But IMO you'd
get a similar effect if you add an algorithm for MAILBOXLIST, and
keep the syntax of *From: and *Sender: as it is in RFC 5322.

Presumably this is an old IETF 81 discussion, and I just missed why
the "groupification" hack is better than my frontal KISS approach.

-Frank (will post again if I see another nit)

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Nov 2011 05:50:35 +0100

>  2. Added Message-ID downgrading

I wonder why.  The WG insisted on "same syntax as for mailbox".
Therefore I'd expect "same downgrade algorithm as for mailbox".

Let them eat their dog-food right now, move all header fields
in section 5.2.4 to section 5.2.1.  Sadly there are still two
other cases for 5.1.9 ENCAPSULATION, "Original-Recipient" and
"Final-Recipient".

-Frank