Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping Be tween the Multimedia Messaging Service (MMS) and Internet Mail"

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 15 Jun 2005 17:48:57 -0500

I suspect there is some confusion here.

OMA has defined RFC822 headers for use within the MMS domain.  OMA designed MMS as an extenion of Internet email, and extended it in some weird ways for tactical business reasons.  (like wanting read receipts two years before the MDN work finished)  In general, MMS and Internet email are plug-compatible... as in, I can plug my PC in a socket in the UK or the US, and it pretty much works.  Not all features work, and it may not be safe in all circumstances.

The protocols are sooo similar, that using the same user agent for mobile internet email and MMS will be common.  (it is a detail that one message was retrieved via WAP/HTTP and the other via POP)  I will mix MMS messages and Internet messages in the same client-side inbox.  They are both RFC822 message, with MIME body structure.  It is very likely that MMS extenson header fields show up in the wild today, largely because you can resend an MMS message to an Internet submission server... and it just works.  

For these reasons, I preferred to keep X-MMS as defined by the OMA for MMS messages gatewayed to the Internet.  In that case, there are that many fewer headers I need to understand as a recipient UA.   I will have to parse the X-MMS version since I get them from the MMS message store, and I will likely get "escapee" MMS messages with X-MMs headers  from my Internet message store.  Adding a parser to also look for MMS- headers is not a big deal, it just seems unnecessary.  I am just trying to avoid the current situation where a client needs to look for X-priority, X-MS-priority, and Importance to maximize the odds that the recipients sees what the sender intended.

If protocol purity is the order of the day, then by all means, define MMS-headers to replace X-MMS-headers.  This can be enforced in the gateways.  It won't do too much for the other paths of leakage between the domains.  In the same appendix discussing X-priority, please mention that X-MMS headers can also be expected to show up in the wild, and if seen, they probably mean the same as MMS-headers.

Greg V.

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]]
Sent: Wednesday, June 15, 2005 4:56 PM
To: Ted Hardie
Cc: [email-masked]; Mark Crispin; Randall Gellens
Subject: Re: [lemonade] Fwd: Appeal of decision to standardize "Mapping
Between the Multimedia Messaging Service (MMS) and Internet Mail"

On Wed Jun 15 20:31:06 2005, Ted Hardie wrote:
> At 5:54 PM -0700 6/14/05, Mark Crispin wrote:
>> A null transformation of a datum by the gateway is permissible 
>> only when that datum is identical with identical semantics in 
>> both.  In Internet mail, X-* headers have the semantics of 
>> "user-defined field".  They therefore can not be used to represent 
>> MMS headers which have different sematics.
>> 
>> 
> But is this a null transformation?  The view of X- headers in the 
> two systems is
> such that I think it's reasonably to read it as a transformation 
> from
> "semantically valid" to "semantically null".  As long as the X-MMS 
> header
> is on the Internet side of the gateway, it is semantically null 
> because there
> is no user definition of the field.  True, it got made 
> "semantically null" by
> being copied verbatim into a system which treats strings starting 
> X- in a s
> pecial way, but it still got transformed as a result, didn't it?
> 
> 
You appear to be agreeing that the semantics were changed, which is, 
I think, Mark's point.

> I'm also somewhat confused about what you think "user defined" 
> implies
> in the current Internet case.  I see lots of X- headers that are 
> clearly
> parts of larger systems or are otherwise non-individual user defined
> headers (brightmail poetry, for example).  

None are defined by a standards-track IETF document, in as much as 
I'm aware.

I believe Mark was referring, by "user-defined field", to section 
4.7.5 of RFC822, which uses this term. (Admittedly, it's actually 
"user-defined-field[s]", but I'm willing to forgive Mark his missing 
hyphen.) I don't think he intended to suggest that all X-* headers 
were defined by individual users of network mail, even if that's the 
language used elswhere in that section, but merely that from a 
standards compliance perspective, they can be.

> Why are OMA-defined headers
> different here?

They're different because they don't exist. To the best of my very 
limited knowledge of the OMA, they have not defined any Internet 
message header fields at all.

Assuming you're referring to the X-MMS-* fields, however, those are 
different because they're not defined by the OMA, but by the IETF, 
and, in particular, this working group.

Dave.

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

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 16 Jun 2005 10:08:38 +0100

Thanks for the explanation.

On Wed Jun 15 23:48:57 2005, Vaudreuil, Greg M (Greg) wrote:
> If protocol purity is the order of the day, then by all means, 
> define MMS-headers to replace X-MMS-headers.  This can be enforced 
> in the gateways.  It won't do too much for the other paths of 
> leakage between the domains.  In the same appendix discussing 
> X-priority, please mention that X-MMS headers can also be expected 
> to show up in the wild, and if seen, they probably mean the same as 
> MMS-headers.

I think it's the "probably" that's raising objections.

This isn't a purity issue, at least not for me. This is a question of 
whether renaming the headers (or mapping them to different names, 
depending on your viewpoint) is better than not doing so.

Dave.