Subject: [lemonade] Updated MMS-Mappings Draft

From: Randall Gellens <[email-masked]>
Date: Tue, 6 Sep 2005 15:54:38 -0700

I've prepared a revision of the MMS Mappings draft.  It should appear 
in the I-D directory soon, but in the meantime it is available at 
<http://people.qualcomm.com/randy/draft-ietf-lemonade-mms-mapping-05.txt>. 
Also, a diff from -04 is available at 
<http://people.qualcomm.com/randy/draft-ietf-lemonade-mms-mapping-05-diff.html>.

There is now an Appendix A that lists the changes from the previous version.

A few points to consider/discuss:

- The draft says that the return-path MUST be set to null for 
automatically-generated MMs.  I think this is the right way to go, 
given the risk of mail loops, but if you disagree, say so now.

- There is no longer any mention of sender address hiding except to 
say it isn't supported.  If you disagree, please speak up.

- The draft now says that FQDNs MUST be used in SMTP envelopes / 
Unqualified E.164 addresses MUST NOT be used.  This is very 
consistent with RFC 2821.

- The draft now says that FQDNs SHOULD be used in address headers / 
Unqualified E.164 addresses SHOULD NOT be used.  Do we want to make 
this MUST instead of SHOULD?

- The mapping between Disposition-Notification-To in Internet mail 
and X-MMS-Read-Reply in MMS should be carefully reviewed.

- The mapping between Message Disposition Notification reports in 
Internet mail and Read Reports in MMS should be carefully reviewed.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Don't accept your dog's admiration as conclusive evidence that you are
wonderful."                                              --Ann Landers

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Thu, 15 Sep 2005 14:57:00 -0700

The #1 point of the objection against the previous MMS mappings draft 
was that the working group (that's us) did not adequately review or 
discuss it.

I've submitted a revised version that addresses all the points raised 
in the appeal (and I believe deals with the underlying issues, not 
just the surface examples).  However, I have not seen any discussion 
of the revision.

The updated version and a nice color-coded diff are available via the 
links below.

Please take a few minutes to review.  If you're delighted with the 
changes, terrific -- a terse sentence to this effect will be much 
appreciated.  If you think I got something horribly, dangerously 
wrong, fine, speak up now.

(I just realized that the -05 draft still hasn't shown up in the i-d 
directory; I sent a note asking about it, but in the mean time it is 
available at the URL below.)

At 3:54 PM -0700 9/6/05, Randall Gellens wrote:

>  I've prepared a revision of the MMS Mappings draft.  It should 
> appear in the I-D directory soon, but in the meantime it is 
> available at 

-------------- Randomly-selected tag: ---------------
37% of Americans agree that while they would hate being British,
they wouldn't mind having a British accent.

---

From: Chris Newman <[email-masked]>
Date: Fri, 16 Sep 2005 20:01:37 -0700

I have a feeling that it will be very difficult to find reviewers familiar with 
both MMS and Internet mail which is why this document has had little review.  I 
have not read any of the MMS specifications so I'm not properly qualified to 
review this.  However, given the choice of no review or a reviewer who is only 
partially competent, I believe the latter is preferable so my review follows. 
Apologies for my ignorance of MMS.  I also apologize if any of these issues has 
been raised before and settled -- this is the first time I've examined this 
work and I did it cold without reading previous debate.

I've found two errors I consider show-stoppers:
 * Failure to discuss "By-type" for DELIVER BY mapping.
 * Conflation of Message-ID and ENVID.
and one issue which might be a show-stopper (depending on what MMS permits):
 * Handling of non-ASCII addresses

Detailed review follows:

Section 2.1.3.1:

>    Previously-sent- |N/A              |Resent-From:    |X-Mms-Previous
>    by               |                 |                |   ly-Sent-By:
>    _________________|_________________|________________|______________
>    Previously-sent- |N/A              |Resent-Date:    |X-Mms-
>    date and-time    |                 |                |   Previously-
>                     |                 |                |   Sent-Date:

On first glance I thought this was a direct mapping which would make no sense 
since the semantics don't match but in reading later text that was clarified. 
I suggest the left two columns of the table should look something like this:

            ...   From:        |X-Mms-Previously-Sent-By:
            ...   Resent-From: |From:
            ...   _____________|___________
            ...   Date:        |X-Mms-Previously-Sent-Date:
            ...   Resent-Date: |Date:

This makes it clear that MMS has different semantics for "From" and "Date" than 
Internet Email and that a cross-mapping is necessary when 
X-Mms-Previously-Sent-* headers are present.

Section 2.1.3.2:

>    The 'Message-Id:' header MUST be retained.  If not present it MUST
>    be created, with a unique value, per [Msg-Fmt].
>
>    The message ID SHOULD be transmitted in the [SMTP] envelope as the
>    ENVID parameter, as specified in [DSN-SMTP].

The message ID and envelope ID are different and I don't think it makes sense 
to copy from one to the other.  A message ID identifies the content of a 
message and can be reused when the message is resent.  An envelope ID 
identifies one transmission of a message and thus has a narrower scope.

Now if MMS conflates the two concepts (message content id vs. envelope id) in 
such a way that a proper delivery report can't be generated without conflating 
the two, then it might be justifiable on a lesser-of-evils basis to conflate 
the two as described.  However, you then need to describe some of the nasty 
situations that result, such as:

MMS -> Internet Mail -> MUA resend with same Message ID but different ENVID -> 
Internet Mail -> MMS -> bounce generated

The impact of conflating the two would need to be discussed in security 
considerations.

>    Current Internet message format requires that only 7-bit US-ASCII
>    characters be present in addresses.  Other characters (for example,
>    non-7-bit characters in a phrase part of an address header) MUST be
>    encoded according to [Hdr-Enc].

If MMS permits 8-bit anywhere in the address headers, then this is not 
complete. While non-ASCII characters in the phrase or a comment MUST be encoded 
with [Hdr-Enc], 8-bit characters in the domain must be encoded with IDN and if 
there are any 8-bit characters in the local part, the message must bounce since 
we haven't standardized what to do yet.

>    MUST NOT be sent to an Internet mail system with an E.164 numbers
>    instead of a fully-qualified domain name.

Grammar nit: Either drop "an" or change "numbers" to "number".

>    The remaining time until the message is considered expired SHOULD be
>    transmitted in the [SMTP] envelope by using the DELIVER-BY
>    extension, as specified in [Deliver-By].

You need to specify the "By-type" for this mapping.  Are the semantics to 
bounce if it expires or notify but deliver anyway if it expires?

>    When the NOTIFY extension is used, the unaltered recipient address
>    SHOULD be transmitted as the ORCPT value

This is good, but in the event the unaltered recipient address is not an RFC 
2821 address, then we need to register a new "MMS" address type with IANA for 
the ORCPT address type label.  See:
  <http://www.iana.org/assignments/mail-parameters>

>    Any 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date'
>    headers, if present, SHOULD be removed.  The information contained
>    in them SHOULD be translated into 'From:', 'Resent-To:',
>    'Resent-From:', and 'Resent-Date:' headers.  The original sender of
>    the message SHOULD appear in the 'From:' header; the original
>    recipient(s) SHOULD appear in the 'To:' header; the time and date
>    the message was originally sent SHOULD appear in the 'Date:' header.
>    The most recent sender SHOULD appear in the top-most 'Resent-From:'
>    header; the most recent recipient(s) SHOULD appear in the top-most
>    'Resent-To:' header; the time and date the message was most recently
>    sent SHOULD appear in the top-most 'Resent-Date:' header.

I find this text a bit vague and confusing.  An example is probably needed. 
I'm also not sure that "Resent-To:" should appear in the list but I can't be 
certain since I don't know the semantics of the MMS headers.

>    The message content appears in the message body.  Note that Internet
>    message format requires that line-endings be encoded as CR LF, thus

Change "as CR LF" to "as US-ASCII CR LF octets" to make it clear why this is a 
problem.

>    when they are suitable encoded or when binary transmission has been
                          ^
                          y

Section 2.1.3.3

>    An 'X-Mms-Expiry:' header SHOULD be created if the message contains
>    a relative time to expiration in the DELIVER-BY extension, as
>    specified in [Deliver-By].

You need to specify how to handle the different by-modes "R" and "N".

>   ... The
>    third subpart is of type message/rfc822 and includes the headers and
>    optionally the body of the referenced (original) message.

The third part is optional.  If it is headers-only, it has the 
text/RFC822-Headers content type.

>ID of message whose   |Message-Id: |'Original-Envelope-ID' field of
>delivery status is    |            |per-message fields (use value of
>being reported        |            |ENVID from SMTP envelope if avail-
>                      |            |able, 'Message-ID:' otherwise).
> ...
>ID of the original |Message-Id:       |'Original-Envelope-ID' field of
>message (object of |                  |per-message fields.  If not
>delivery report)   |                  |available, the 'Message-ID'
>                   |                  |header field of the message
>                   |                  |being reported, if included in
>                   |                  |the third part, may be
>                   |                  |substituted.

This advice could cause severe problems because Message-ID and Envelope-ID are 
quite different semantically.  In particular, it's very important that we don't 
willfully create a situation where two Internet Messages with different content 
have the same Message-ID.  So I see two ways to play this out:

1) The "Message-ID" header in an MMS message is context sensitive.  If the MMS 
message is an MMS delivery report, it _always_ maps to and from the envelope ID 
in SMTP.  In this case, the Message-ID header MUST be removed from the headers 
when generating the SMTP report.

2) The "Message-ID" header in an MMS message is not context sensitive.  It 
always maps _only_ to the RFC 2822 Message-ID and never maps to an envelope ID.

BTW, out of curiosity, what is the X-Mms-Transaction-Id?  Perhaps that maps 
cleanly to the SMTP envelope ID?

>Recipient address of  |From:       |'Final-Recipient' field of the
>the original message  |            |per-recipient section
>(object of delivery   |            |
>report)               |            |

This should be explained further.  I'm guessing that MMS overloads the "From:" 
header on a delivery report to contain the potentially-invalid recipient 
address that failed when delivery was attempted.  Presumably, this address 
might be an MMS address type rather than an rfc822 address type...

Also, for DSN mappings, if MMS defines any sort of computer readable diagnostic 
that it shoves in a header, then a new diagnostic type other than "smtp" should 
probably be registered and used in the DSN format.

It's not a show-stopper, but it would be very helpful to have some examples of 
the more complex mapping scenarios -- particularly those relating to multiple 
Resent-* headers and mappings of DSNs/MDNs.

                - Chris