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: Fri, 24 Jun 2005 08:15:52 -0500

Dave, 

I think you understand, but are falling to the wrong conclusion based on your desire to avoid suggesting a possible precident rather than the facts in this matter.

OMA did not redefine existing headers in non-standard ways.  Your address example below does not apply to the problem at hand, but if you believe it did, I can see why it would drive you to different conclusion.  OMA adopted X-mms headers as private extensions.  Extensions that are not understood are ignored by "pure" non-internet components.  I can drop a standard MMS message into MS outlook, or eudora, and it renders fine, even if some enhanced capabilities are not exposed.

The world of MMS and email are hybridizing.  There are, and will be more client and MTA's that live in both worlds, but are not formal gateways.  (informal in that they can forward, resend, or reply to one form with another form).  You clearly see MMS as an Island, I see them as adjacent bodies of water.

The goals as *I* see are the following:

	1) Map MMS message semantics to email semantics to the extent there is a mapping.  
		This allows MMS messages to be delivered to Internet endpoints with maximum fidelity.
	2) Tunnel information that can't be mapped in a way that it can be predictably reveresed 
		by a gateway when the message passes back into a separate MMS island.  We have lots of precedent
		for this, most of which is real but non-standard.  (X-MS-priority ect)
	3) Minimize confusion for hybrid clients that operate on both Internet and MMS headers by minimizing
		redundancy and avoiding silly states.  This goal is in tension with #1 above.

I understand the general danger and warning to avoid the three-gateway problem, where MMS may have the concept of ambient odor, and blatmail may have the concept of ambient odor, but there is no standard representation.  MMS-ambient-odor won't then map to blatmail room-smell.  We can't solve that general problem here, and I don't consider it a goal.

Greg V.

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: Friday, June 24, 2005 12:40 AM
To: [email-masked]
Subject: RE: [lemonade] Fwd: Appeal of decision to standardize "Mapping
Be tween the Multimedia Messaging Service (MMS) and Internet Mail"

Folks,

No doubt I'm misunderstanding something pretty basic.  Here's with I *think* is
going on:

>  OMA has defined RFC822 headers for use within the MMS domain.

"within the *MMS* domain" is the key point.

The Mapping document is a gateway specification between the MMS domain and the
Internet mail domain.

>OMA
>  designed MMS as an extenion of Internet email, and extended it in some
>  weird ways for tactical business reasons.

That's fine.  Folks can do anything they want... in *their* own domain.

That does not mean that we should make de jure standards of their decisions, in
our own domain, if the choices they made in their domain are not compatible with
our own.

Exactly as the document is titled, the job of a gateway is to *map* between
heterogeneous services.

If the MMS folks had decided to use exclamation marks to separate between the
global host reference and the local mailbox reference, would be adopt that?  No.
We would map it to the Internet mail conventions for addressing.

If the MMS folks had decided that all message data -- both control and content
-- was to be in Unicode, would we adopt that?  No.  We would map it to the
Internet mail conventions for data representation and encoding.

So it is difficult to understand why MMS-specific header conventions that are
not compatible with Internet mail conventions should not also get mapped to a
form that *is* compatible with Internet mail.

>  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.

In general, English and American are plug-compatible.  Just be careful how you
use the word stuffed, since the English will take offense, or say that something
should be tabled, since it means exactly opposite things.

In the early days of Internet products, some companies advertised that their
products were "based on" Internet standards.  Of course, that really meant that
their products were proprietary.  "In general" is dangerous language.

>  The protocols are sooo similar, that using the same user agent for mobile
>  internet email and MMS will be common.

That's great, but it is not a basis for letting the MMS folks impose change
fundamental Internet mail standards.

>  For these reasons, I preferred to keep X-MMS as defined by the OMA for MMS
>  messages gatewayed to the Internet.

Oh.  So this really is NOT trying to "map" MMS into Internet Mail?  It is trying
to *encapsulate* MMS in Internet mail, for use by a specialized community.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

_______________________________________________
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: Fri, 24 Jun 2005 19:34:16 +0100

On Fri Jun 24 14:15:52 2005, Vaudreuil, Greg M (Greg) wrote:
> The world of MMS and email are hybridizing.  There are, and will be 
> more client and MTA's that live in both worlds, but are not formal 
> gateways.

If, by "not formal gateways", I'm to assume that they do not, and 
will not, follow this specification, then why are we bothering to 
produce it, as a working group? Why not just sit back and let things 
happen? Why make a Proposed Standard, when an Informational at best 
would do?

If you mean they're not purpose built gateways, but they still do 
follow this specification, then what does it matter what the header 
field names are?

> 	1) Map MMS message semantics to email semantics to the extent 
> there is a mapping.  		This allows MMS messages to be delivered to 
> Internet endpoints with maximum fidelity.

Which is trivial.

> 	2) Tunnel information that can't be mapped in a way that it can be 
> predictably reveresed 		by a gateway when the message passes back 
> into a separate MMS island.

Indeed, and we have lots of precedent for this, such as the MIXER 
specification, which defined new headers for those semantics which 
previously didn't exist in the Internet domain.

The "predictably reversed" statement suggests that we should not use 
X-* headers in this instance, as the resultant reversal of the 
mapping would be less reliable.

The mere fact that it begins with "X-*" is, to me at least, a moot 
point. The effect of that, however, is that it becomes a less 
reliable method for gatewaying from the Internet to the MMS domain.

> 		redundancy and avoiding silly states.  This goal is in tension 

I fail to understand this.

Any UA, if it understands two messaging domains, must act as a formal 
gateway using whatever formal gateway specification exists, to 
transform messages between domains as required.

Any message store must be in one messaging domain only. Whichever it 
is in, if it is capable of receiving messages from multiple message 
domains, it must gateway according the relevant specification.

Is the purpose of this document to provide a standard for performing 
some interoperable action, or is it purely an informational document 
for explaining what these odd headers you might see are?

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 24 Jun 2005 12:25:35 -0700

At 7:34 PM +0100 6/24/05, Dave Cridland wrote:

>  Is the purpose of this document to provide a standard for 
> performing some interoperable action, or is it purely an 
> informational document for explaining what these odd headers you 
> might see are?

The purpose is to have an interoperable specification to map 
information elements between the MMS and Internet mail worlds to 
allow messages to be exchanged while retaining as much semantic 
content as possible.  The Abstract and Introduction and Scope 
sections should make this clear.  If you believe they fail to do so, 
please point out what is confusing, incorrect, or omitted.

The document already contains such mappings, and in all cases maps 
x-mms-* headers to equivalent Internet mail information elements: 
either header fields, SMTP envelope fields, or specifies that the 
functionality cannot be mapped, such as for reply charging.

The argument about x-mms- headers, as I understand it, has been over 
two specific x-mms- headers that -04 says SHOULD or MAY be retained. 
The proponents of that view have since acquiesced and agreed that 
they can be made the same as the others.

There was an additional argument over the mention of X-Priority, and 
it was agreed that any such mention should be moved to an 
informational appendix.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Vous etes ici

---

From: Dave Cridland <[email-masked]>
Date: Fri, 24 Jun 2005 22:24:27 +0100

On Fri Jun 24 20:25:35 2005, Randall Gellens wrote:
> content as possible.

Why do I bother asking rhetorical questions if people are going to 
answer them? ;-)

> The argument about x-mms- headers, as I understand it, has been 
> over two specific x-mms- headers that -04 says SHOULD or MAY be 
> retained.

That's not been the point of my argument, nor, as I understood it, 
Mark's.

It's the reverse that causes me concern - retaining X-* headers from 
an Internet message when transforming it into an MMS message.

I can see how easy it is to get confused over this, because the bulk 
of the proposed solutions for avoiding that transformation relate to 
the reverse - that is, in order to avoid the problems in the 
Internet->MMS end, the solutions are mainly centered around the 
MMS->Internet end.

But please don't confuse the two issues - you're more than welcome to 
put any X-* headers in your message (or indeed part) headers you 
like, and I'll defend your right to do so, however, semantic 
interpretation of those headers is something that should not be done 
if it can be avoided, and in this case I believe it can be avoided, 
and moreover it is simple to do so.

Moreover, there's the purist viewpoint that even mentioning them in a 
normative section of a standards-track document is a bad idea, but 
that alone wouldn't cause me to object so strongly to it - I like 
dogma, but I prefer pragma.

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 24 Jun 2005 15:10:06 -0700

At 10:24 PM +0100 6/24/05, Dave Cridland wrote:

>  It's the reverse that causes me concern - retaining X-* headers 
> from an Internet message when transforming it into an MMS message.

There's no mention anywhere in the document that I am aware of which 
mentions retaining x-headers when going from Internet mail to MMS. 
(There is mention of mapping X-Priority, which clearly says it is a 
non-standard header, but it was agreed that this should be moved to 
an informative appendix.)
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The challenge of computer science is: How NOT to make a mess of it.
                                               -Edsger W. Dijkstra

---

From: Dave Cridland <[email-masked]>
Date: Sat, 25 Jun 2005 00:34:17 +0100

On Fri Jun 24 23:10:06 2005, Randall Gellens wrote:
> There's no mention anywhere in the document that I am aware of 
> which mentions retaining x-headers when going from Internet mail to 
> MMS.

I refer the honourable gentleman to the answer I gave some moments 
ago:

[...] currently, section 2.1.3.2 states that:

   An 'X-Mms-Message-Id:' header, if present, SHOULD be retained in
   order to facilitate the case where an MMS message traverses the
   Internet prior to returning to an MMS system.  Such systems should
   be aware that X-headers might be removed during transit through
   Internet MTAs.

Perhaps I'm being really very confused here, but doesn't that 
paragraph directly imply that those headers should be directly 
remapped - or retained if you will - when going from Internet mail to 
MMS? It's stated as the point of keeping them about at all, so 
perhaps I'm reading too much, but it certainly looks like a mention 
which mentions retaining those headers.

Moreover, if we're not going to apply MMS semantics to those headers, 
why are you so intent on keeping them?

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 24 Jun 2005 16:51:15 -0700

At 12:34 AM +0100 6/25/05, Dave Cridland wrote:

>> which mentions retaining x-headers when going from Internet mail 
>> to MMS.
>
>  I refer the honourable gentleman to the answer I gave some moments ago:
>
> remapped - or retained if you will - when going from Internet mail 
> to MMS? It's stated as the point of keeping them about at all, so 

Now that you point it out, I can see how that text could be 
interpreted as implying that such headers should be retained when 
going from Internet mail to MMS.  But, that text appears only in the 
section on going from MMS to Internet mail.  In the section on 
Internet mail to MMS there is no mention of retaining such headers.

However, we already agreed to delete the text you quote by agreeing 
that the x-mms-message-id header should no longer be treated 
specially, so I think it has become moot.

>
>  Moreover, if we're not going to apply MMS semantics to those 
> headers, why are you so intent on keeping them?

I'm "so intent on keeping them"?  I admit to having argued for 
keeping them, but quite some messages ago I agreed that we can delete 
them.

-------------- Randomly-selected tag: ---------------
To die for an idea is unquestionably noble. But how much nobler it
would be if men died for ideas that were true!
    --H.L. Mencken

---

From: Dave Cridland <[email-masked]>
Date: Sat, 25 Jun 2005 01:13:37 +0100

On Sat Jun 25 00:51:15 2005, Randall Gellens wrote:
> going from Internet mail to MMS.  But, that text appears only in 
> the section on going from MMS to Internet mail.  In the section on 
No, but there's no mention of not keeping them either.

> specially, so I think it has become moot.

Okay, so I'm to understand that gateways for Internet->MMS MUST drop 
all X-MMS-* headers? I think text to that effect should be in this 
document if that's the intent.

> keeping them, but quite some messages ago I agreed that we can 
> delete them.

Okay, so are we agreed that X-MMS-* headers MUST be dropped? Or are 
you saying that SHOULD be dropped, or MAY be dropped, or MAY be 
retained?

I don't see any argument left standing for keeping them at this 
point, but maybe I'm missing something.

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jun 2005 15:33:09 -0700

> point, but maybe I'm missing something.

I don't have any argument to make for keeping them either.  I think 
we should say "SHOULD be dropped".

-------------- Randomly-selected tag: ---------------
Politics offers yesterday's answers to today's problems.
                                     --Marshall McLuhan

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Jun 2005 18:30:55 -0700

At 3:33 PM -0700 6/27/05, Randall Gellens wrote:

>  I don't have any argument to make for keeping them either.

It may be worth having a brief informational mention of why it is not 
a goal of the document.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Lansing Residents Can Drop Off Trees
--Newspaper headline

---

From: Dave Cridland <[email-masked]>
Date: Tue, 28 Jun 2005 09:57:31 +0100

On Mon Jun 27 23:33:09 2005, Randall Gellens wrote:
>>  Okay, so are we agreed that X-MMS-* headers MUST be dropped? Or 
>> are you saying that SHOULD be dropped, or MAY be dropped, or MAY 
>> be retained?
>> 

I'm fine with a "SHOULD be dropped" for MMS->Internet, but I'd like a 
"MUST be dropped" for Internet->MMS.

Dave.