RE: renaming MTOM

The use cases that I had in mind were ones in which some property of
the body such as a signature over a checksum of the body needed to be
included, where the body was dynamically generated into the message.
There were other sorts of examples that we discussed when we wondered
whether to allow trailers in SOAP 1.2.  One school of thought was that
such things that had to be generated after the body could be put into
attachments.

Mark

	Subject: RE: renaming MTOM
	Date: Thu, 17 Jul 2003 12:24:03 -0700
	From: "Martin Gudgin" <mgudgin@microsoft.com>
	To: <jones@research.att.com>, <mark.nottingham@bea.com>, <xml-dist-app@w3.org>
	 

	> -----Original Message-----
	> From: xml-dist-app-request@w3.org 
	> [mailto:xml-dist-app-request@w3.org] On Behalf Of 
	> jones@research.att.com
	> Sent: 17 July 2003 11:23
	> To: mark.nottingham@bea.com; xml-dist-app@w3.org
	> Subject: Re: renaming MTOM
	> 
	> 
	> I think I would prefer a term that uses "serialization", 
	> which is really what we're defining.  The resulting 
	> MIME-multipart packaging need not represent any particular 
	> optimization at all.  The parts may even contain XML 
	> fragments which would be identical if they were coded 
	> "in-line" in the SOAP envelope. 

	Except that upon resulution of includes they would end up encoded as
	base64 chars at the infoset level. I don't believe that we have a
	use-case/requirement to allow the envelope to be broken up in such a
	way, do we?

	> [In some use cases, it is a 
	> convenience to build messages in this way if the headers 
	> express properties of a dynamically constructed body.]
	> 
	> "Serialization" doesn't quite capture the potential for lazy 
	> expansion of Include, but this is more of a run-time 
	> optimization than a wire-format transfer optimization.
	> 
	> Mark Jones
	> AT&T
	> 
	> 
	> 	From xml-dist-app-request@w3.org Wed Jul 16 20:51 EDT 2003
	> 	Delivered-To: jones@research.att.com
	> 	Resent-Date: Wed, 16 Jul 2003 20:51:17 -0400 (EDT)
	> 	Resent-Message-Id: <200307170051.h6H0pHsF010243@frink.w3.org>
	> 	Date: Wed, 16 Jul 2003 17:50:56 -0700
	> 	Mime-Version: 1.0 (Apple Message framework v552)
	> 	From: Mark Nottingham <mark.nottingham@bea.com>
	> 	To: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
	> 	Content-Transfer-Encoding: 7bit
	> 	Subject: renaming MTOM
	> 	X-Archived-At: 
	> http://www.w3.org/mid/B99F1B5E-B7F0-11D7-B152-00039396E15A@bea.com
	> 	Resent-From: xml-dist-app@w3.org
	> 	X-Mailing-List: <xml-dist-app@w3.org> archive/latest/7878
	> 	X-Loop: xml-dist-app@w3.org
	> 	Resent-Sender: xml-dist-app-request@w3.org
	> 	List-Id: <xml-dist-app.w3.org>
	> 	List-Help: <http://www.w3.org/Mail/>
	> 	List-Unsubscribe: 
	> <mailto:xml-dist-app-request@w3.org?subject=unsubscribe>
	> 	X-Spam-Status: No, hits=-2.6 required=4.0
	> 		
	> tests=BAYES_20,USER_AGENT_APPLEMAIL,X_LOOP,X_MAILING_LIST
	> 		version=2.55
	> 	X-Spam-Level: 
	> 	X-Spam-Checker-Version: SpamAssassin 2.55 
	> (1.174.2.19-2003-05-19-exp)
	> 
	> 
	> 	On today's concall, there was some concern expressed 
	> about the name 
	> 	chosen for our current work, especially regarding 
	> "Optimization." As a 
	> 	result, I took an AI to kick off discussion of other 
	> possible names, 
	> 	and their respective merits.
	> 
	> 	* Option 1: Message Transfer Optimization Mechanism (no change)
	> 	"Optimization" emphasizes the purpose for using the 
	> mechanism; i.e., 
	> 	we're doing this so that people can improve 
	> performance, efficiency or 
	> 	other characteristics of message transfer.
	> 
	> 	The objection to this name was that people may use the 
	> mechanism we 
	> 	describe without intending to optimize the message 
	> transfer (I'm not 
	> 	sure of the exact cases here; could someone who 
	> believes this expand 
	> 	upon this reasoning?).
	> 
	> 	* Option 2: Use "Encoding" (e.g., "Alternate XML Encoding")
	> 	I view the problems addressed by PASWA and MTOM as pure 
	> encoding 
	> 	problems, since their representations are isomorphic to 
	> vanilla XML 
	> 	1.0. In this manner, they are very similar to MIME 
	> 	(Content-Transfer-Encoding) and HTTP (Content-Encoding) 
	> mechanisms.
	> 
	> 	The problem here is that "Encoding" has other meanings 
	> for XML people 
	> 	(character encoding) and SOAP people (SOAP Section Five 
	> Encoding), and 
	> 	therefore may be confusing.
	> 
	> 	* Option 3: Use "Serialization" (e.g., "Alternate XML 
	> Serialization")
	> 	Another suggestion was to use "Serialization," because 
	> we're defining 
	> 	an alternate serialization of the message Infoset. This 
	> approach has 
	> 	many of the advantages of "Encoding"; it emphasizes the 
	> fact that it's 
	> 	just a different representation of the Infoset.
	> 
	> 	I'm not aware of any objections to the term 'Serialization."
	> 
	> 	* Option 4: Choose a completely unrelated name.
	> 	"SOAP" doesn't convey any information about what it is 
	> or attempts to 
	> 	do in its name (or, at least, it doesn't any more). We 
	> could take the 
	> 	same approach for this work.
	> 
	> 
	> 	In making this decision, we should probably keep the 
	> following in mind:
	> 
	> 	* We may be producing more than one specification, so 
	> the name doesn't 
	> 	need to address all of the functionality we're talking 
	> about (and we 
	> 	may need to wait until we determine what the 
	> deliverables will be; we 
	> 	have a slot scheduled for this during the F2F).
	> 
	> 	* The name chosen may also be affected by how our 
	> solution is layered 
	> 	into SOAP; e.g., if it's a content-coding in HTTP, 
	> "Encoding" makes 
	> 	more sense, whereas if it were a new format with a 
	> separate media type, 
	> 	"Serialization" might.
	> 
	> 	* We should also consider whether the mechanism we 
	> define might be 
	> 	reused by other XML applications; if it's likely, we 
	> may want to 
	> 	de-emphasize the messaging aspect.
	> 
	> 
	> 
	> 
	> 
	>

Received on Friday, 18 July 2003 09:01:31 UTC