Subject: [lemonade] GV review of draft-ietf-lemonade-mms-mapping-05.txt

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 3 Oct 2005 14:55:07 -0500

I have reviewed the recently posted -05 version of this document and have the following comments.  My comments from earlier reviews have been addressed.

Formatting issue:  The tables are given their own section, but because they are not true sections, it makes it hard to figure out which section to cite for these comments.  I will assume the tables do not begin a new section for the purposes of these comments.  The practice also makes the TOC overly complex.

Section 2.1.3.2

Future Delivery is a bit squishy, here and in section 2.1.3.3.  Because it may be possible to consider the gateway to be a submitting UA in the general model, the first-hop MTA after the gateway can be considered the submission server.  Whether this makes sense or not is besides the point.  I suggest the following text for handing an MMS with the X-Mms-delivery-time header:  "Future Delivery is a submission facility and does not provide for passing the delivery-time to the final system.  If the Gateway recieves a message with an X-Mms-delivery-time header, the gateway is responsible for ensuring that the message is held until the appointed time.  If the next-hop MTA supports the deliver-after SMTP extension, the gateway may map the X-MMs-Delivery-time header to the SMTP deliver-after parameter."  

There are a number of places in this section where there are requirements that are redundant with the base SMTP and MSG-FMT specifications.  I'd prefer to see language in the flavor of an implementors note with reference rather than  using the normative "MUST and SHOULD" conventions.  Examples are "The address(es) in the 'From:' header SHOULD be in the form of fully-qualified domains."  I'd prefer text here and elsewhere of the form "From: headers should be fully compliant to the requirements in [MSG-FMT]."

I don't recall that MMS permits sending of unencoded 8-bit characters in addresses. If it does, and that is the motivation for the discussion of 8-bit header encoding, then please note that explicitly.  Otherwise, the discussion of 8-bit text in addresses seems to cause confusion.

Address-hiding. This document makes the default action to unhide an address and forward the message.  It seems that as a matter of policy, one may chose to do the opposite, that is, to return a message to sender rather than disclose what was requested to remain hidden.  At a minimum, we need text here or in the security considerations section to make clear that there is a trade-off between maximum interoperability and the need to protect identity as supported by the address hiding header.

Section 2.1.3.3

Future Delivery: It may seem odd, but I can imagine the MMS gateway being used as a submission server for certian mobile clients.  In such a case, it makes perfect sense to accept a deliver-after SMTP parameter and map it onto an X-Mms-delivery-time if the next hop is an MMS relay.

Priority:  I don't recall the discussion on why we agreed to support both importance and X-priority.  Assuming we agreed to retain both, there needs to be text following the table defining what action to take where an X-priority and Importance header contradict.  I suggest "If the X-priority and X-importance value conflict, the value included in the importance header takes precidence"

Security Considerations

Again, we need some text discussing address hiding, a security consideration unique to the interaction between the two services.  Might also find similar with reverse-charging providing a revenue-leak.  Both of these unsupported features are unsupported in Internet mail precisely because they are hard to do securely across administrative domains.

References:

Two places discuss future delivery without making a helpful informative reference to the ID.  I'd suggest an additional reference.

Greg V.

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

---

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

Hi Greg,

Thanks for the review.

At 2:55 PM -0500 10/3/05, Greg M (Greg) Vaudreuil wrote:

>  I have reviewed the recently posted -05 version of this document 
> and have the following comments.  My comments from earlier reviews 
> have been addressed.

Please note that -05 was actually written a couple of week ago, and 
was posted to the list.  There was a problem with the formal I-D 
publication, which is why the notice was just sent now.  So, -05 is 
*not* the -06 that I am about to post.

>
>  Formatting issue:  The tables are given their own section, but 
> because they are not true sections, it makes it hard to figure out 
> which section to cite for these comments.  I will assume the tables 
> do not begin a new section for the purposes of these comments.  The 
> practice also makes the TOC overly complex.
>
>  Section 2.1.3.2
>
>  Future Delivery is a bit squishy, here and in section 2.1.3.3. 
> Because it may be possible to consider the gateway to be a 
> submitting UA in the general model, the first-hop MTA after the 
> gateway can be considered the submission server.  Whether this 
> makes sense or not is besides the point.  I suggest the following 
> text for handing an MMS with the X-Mms-delivery-time header: 
> "Future Delivery is a submission facility and does not provide for 
> passing the delivery-time to the final system.  If the Gateway 
> recieves a message with an X-Mms-delivery-time header, the gateway 
> is responsible for ensuring that the message is held until the 
> appointed time.  If the next-hop MTA supports the deliver-after 
> SMTP extension, the gateway may map the X-MMs-Delivery-time header 
> to the SMTP deliver-after parameter."

I don't want to reference future-delivery since that will delay 
publication, and we already have 3GPP2 documents waiting on this 
document.

>
>
>  There are a number of places in this section where there are 
> requirements that are redundant with the base SMTP and MSG-FMT 
> specifications.  I'd prefer to see language in the flavor of an 
> implementors note with reference rather than  using the normative 
> "MUST and SHOULD" conventions.  Examples are "The address(es) in 
> the 'From:' header SHOULD be in the form of fully-qualified 
> domains."  I'd prefer text here and elsewhere of the form "From: 
> headers should be fully compliant to the requirements in [MSG-FMT]."

If you want to send me the examples from -06 where these should be 
changed, I can reword them to something like "per [reference], blah 
blah blah MUST be done", or maybe "blah MUST be fully compliant to 
[reference], including blah blah blah".  Just saying "fully 
compliant" doesn't really help, I think.

>
>  I don't recall that MMS permits sending of unencoded 8-bit 
> characters in addresses. If it does, and that is the motivation for 
> the discussion of 8-bit header encoding, then please note that 
> explicitly.  Otherwise, the discussion of 8-bit text in addresses 
> seems to cause confusion.

This text has been reworded in -06, please review that.

>
>  Address-hiding. This document makes the default action to unhide an 
> address and forward the message.  It seems that as a matter of 
> policy, one may chose to do the opposite, that is, to return a 
> message to sender rather than disclose what was requested to remain 
> hidden.  At a minimum, we need text here or in the security 
> considerations section to make clear that there is a trade-off 
> between maximum interoperability and the need to protect identity 
> as supported by the address hiding header.

I added text that "A message that contains an 
'X-Mms-Sender-Visibility:' header with a value of 'Hide' SHOULD be 
rejected."

>
>  Section 2.1.3.3
>
>  Future Delivery: It may seem odd, but I can imagine the MMS gateway 
> being used as a submission server for certian mobile clients.  In 
> such a case, it makes perfect sense to accept a deliver-after SMTP 
> parameter and map it onto an X-Mms-delivery-time if the next hop is 
> an MMS relay.

This can be added to a revision of the document after future delivery 
is standardized.

>
>  Priority:  I don't recall the discussion on why we agreed to 
> support both importance and X-priority.  Assuming we agreed to 
> retain both, there needs to be text following the table defining 
> what action to take where an X-priority and Importance header 
> contradict.  I suggest "If the X-priority and X-importance value 
> conflict, the value included in the importance header takes 
> precidence"

This text was added to -06 in the Internet Mail to MMS case.  All 
mention of X-Priority was deleted from -06 in the MMS to Internet 
mail direction.

>
>  Security Considerations
>
>  Again, we need some text discussing address hiding, a security 
> consideration unique to the interaction between the two services. 
> Might also find similar with reverse-charging providing a 
> revenue-leak.  Both of these unsupported features are unsupported 
> in Internet mail precisely because they are hard to do securely 
> across administrative domains.

The document says:
	Some MMS features contain inherently more risk than others,
     including reply charging and sender address hiding.  Support for
     these mechanisms are not included in this document.

Is there other text you'd like to see?

>
>  References:
>
>  Two places discuss future delivery without making a helpful 
> informative reference to the ID.  I'd suggest an additional 
> reference.

-06 only has one occurrence of the word "future", and I don't think 
it needs a reference.  Please have a look at -06 and see if you still 
feel the need for a reference.  Note that any reference would need to 
be informative and vague to avoid delaying publication.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
People demand freedom of speech to make up for the freedom of thought
which they avoid.                                       --Kierkegaard