W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2003

Re: Summary: Encodings other than base64

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 2 Oct 2003 13:47:59 -0400
To: rsalz@datapower.com
Cc: Tony Graham <Tony.Graham@Sun.COM>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-ID: <OFE5895D3E.7D452E0F-ON85256DB3.0060F61C@lotus.com>

Rich Salz writes:

>> Can we design for many, but define only one now?

On the XMLP telcon yesterday a decision was made to adopt the Data Model 
formulation as the normative base for future work (original draft at 
[1]...stable WD editors copy text should show up within a week or so). 

I'd like to point out that it comes very close, I think, to doing exactly 
what Rich suggests (though I do recall that Rich expressed some 
reservations about the DM approach for other reasons.)  The dm:type 
accessor in the model clearly provides a hook for providing more 
generalized type information, but the current formulation is quite clear 
that for the moment, and perhaps forever, only base64 is subject to 
optimization.

Tony Graham writes:

>> - One might take the view that optimizing more than one type encourages 
one to send the actual type label as part of the model. [3]

I think the resolution to issue 431, as well as the DM formulation, make 
clear that this need not be a concern.    The key, I think, is 
distinguishing what is visible in the received Data Model or Infoset vs. 
what is visible at the binding level.  I think we've made a clear decision 
that the following is true:

* All information related to typing and optimization is visible only at 
the binding, and need not be surfaced at the receiving node (except 
insofar as the binding itself uses it to retrieve the optimized content.)

* At an intermediary, an inbound and outbound binding may conspire to 
provide efficient implementation in the case where a piece of the message, 
such as a header entry, are passed through unmodified.  Again, this is not 
visible directly at the Infoset or Soap Processing Model level:  it's 
something the bindings can do if they choose to. 

I believe that both of these rules generalize in the obvious way to the DM 
formulation and to the case where multiple data types are optimized. 

Noah

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2003Aug/0014.html

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Rich Salz <rsalz@datapower.com>
Sent by: xml-dist-app-request@w3.org
09/30/2003 09:23 PM

 
        To:     Tony Graham <Tony.Graham@Sun.COM>
        cc:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
        Subject:        Re: Summary: Encodings other than base64



> Arguments against encodings other than base64 are:

Greater requirements on all applications if interoperability is to be
maintained.  Can we design for many, but define only one now?
                 /r$

--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html
Received on Thursday, 2 October 2003 13:48:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT