Re: renaming MTOM

Mark, others,

I think that Message Serialization Optimization Mechanism (MSOM) or
Message Packaging Optimization Mechanism (MPOM) is a good name for the
package that contains the abstract optimization feature and its concrete
implementation in SOAP HTTP binding. So if the other stuff that we're
potentially going to add will be added in different documents, the name
is OK.

If we want to add MIME typing and carrying web resource representations
sections into the document, I'd suggest a different name and I wouldn't
be afraid of using the name "attachment" either. I think "SOAP with
Attachments" is a good name, but alas, it's taken. 8-)

Let's see what PASWA does: 

     1. it supports the transmission of web resource representations in
        SOAP messages - this is one major thing people want to do
     2. it supports the encapsulation of binary data (with MIME content
        type) in XML - necessary for the first thing and also a major
        thing people want
     3. it optimizes the transfer of such XML envelopes - by itself not
        something people are crying for, but it is necessary for the
        previous thing

The first thing means attachments, the second thing means generic data,
so a synthesized name would be something like: "Binary data and
Attachments in SOAP".

Enjoy the discussions, I'm going on vacation now. 8-)

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/






On Thu, 2003-07-17 at 02:50, Mark Nottingham wrote:
> 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 11:42:51 UTC