RE: [DR008] - passing arbitrary content

Regarding this thread about binary data...  I think it is important to consider cases in which the client
may need to transmit binary data, but is not fitted with an http server or other means to respond to
separate (out of band) requests for that data from an XP service (via embedded uri's in the XP payload).
Furthermore, I don't like the inefficiency in the fallback of doing hex/base64 encoding in such cases.

There are likely other use cases, with slow transport (SMTP?) for example, where there is latency between
the request and response.  In such cases, the client may not have the resources to cache the data until the
server gets the XP request and issues the retrieval on the uri.  Another use case is where the clent is
generating the data stream in real time as a part of the request, but cannot cache it locally.  For example,
you might have a client that captures images or speech data and immediately wants to send it off to a
service, while doing no local caching of the info.

We should think hard about how to associate the binary data in the XP packaging and allow local uri
references to it from the XML content.

Mark A. Jones
AT&T Labs Research



  [DR008] - passing arbitrary content

>
> From: Henrik Frystyk Nielsen (frystyk@microsoft.com)
> Date: Wed, Dec 06 2000
>
> *Next message: Hall, Randy E: "Response to "On the use of HTTP as a Substrate for Other Protoco ls""
>
>    * Previous message: David E. Cleary: "RE: [DR008] - passing arbitrary content"
>    * Maybe in reply to: Kevin Mitchell: "[DR008] - passing arbitrary content"
>    * Next in thread: Noah_Mendelsohn@lotus.com: "RE: [DR008] - passing arbitrary content"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]
>
>   ------------------------------------------------------------------------
>
> Message-ID: <001d01c05faa$b878d6e0$308f3b9d@redmond.corp.microsoft.com>
> From: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
> To: <dick@8760.com>, "Andrew Layman" <andrewl@microsoft.com>, <xml-dist-app@w3.org>
> Date: Wed, 6 Dec 2000 09:33:56 -0800
> Subject: RE: [DR008] - passing arbitrary content
>
> > Thanks for clarifying the point regarding hex/base64, Base64
> > is certainly
> > more appropriate in this context.
>
> Yes, my mistake - it was a typo.
>
> > I want to explore one of your comments more thoroughly:
> > > Base64 is a supported type within XML Schemas.  The main point is
> > > that it is
> > > easily possible to carry small amounts of binary data inline in XML.
> >
> > Does this mean there is an "upper limit" for the amount of
> > binary data that
> > XP should be
> > expected to carry? For example, one of our clients, an
> > electric company,
> > regularly provides
> > a "profile" of its entire customer base, totaling 150 MB, to marketing
> > companies that are interested in this
> > information. Would you consider a 150 MB binary payload
> > beyond XP's intended
> > use?
>
> I don't think this is an XP question per se but an XML schema question.
> It is possible to compose a derived type with a maxLength (in octets)
> constraining facet but there does not seem to be a default maxLength.
>
> Btw, this is of course not the only way you can carry data in XP - you
> can refer to it using links, see for example [2].
>
> I think more this is a pragmatic question of how much data you want to
> carry this way as it has to be encoded. Using MIME multipart with 150M
> as one entity body is not really practical either as the recipient could
> have to read every single byte to find the delimiter as there is no
> mandatory content-length header field defined for MIME (and it doesn't
> work the same way as in HTTP), see [1]. Not to mention that it would
> exceed many mailbox sizes.
>
> Using HTTP without MIME multipart would seem to be a better way which
> could be indicated by having the link be a http: URI. That way, you can
> also take advantage of caches etc.
>
> > > Regarding referencing data using a URI, the URI does not
> > need to reference
> > > remote data.  It can reference another part within a
> > > multipart-MIME package.
> > > See
> > >
> >
> > I agree, this is the same technique used by ebXML. ebXML
> > manifest entries
> > "reference" local (in the same MIME package) MIME body parts via URI's
> > containing MIME Content-ID's. Perhaps it would be
> > worthwhile to define the requirements of local and remote
> > references so that
> > both are covered in XP's requirements doc.
>
> As the requirement is that they are URIs both cases are covered by
> default as URIs don't distinguish between "remote" or "local" - they are
> all just identifiers.
>
> Henrik
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
> [2]
> http://www.hpl.hp.com/personal/John_Barton/HTTP-A/SOAPAttachments16OCT00.htm
>
>   ------------------------------------------------------------------------
>
>    * Next message: Hall, Randy E: "Response to "On the use of HTTP as a Substrate for Other Protoco ls""
>    * Previous message: David E. Cleary: "RE: [DR008] - passing arbitrary content"
>    * Maybe in reply to: Kevin Mitchell: "[DR008] - passing arbitrary content"
>    * Next in thread: Noah_Mendelsohn@lotus.com: "RE: [DR008] - passing arbitrary content"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]

Received on Wednesday, 6 December 2000 14:51:32 UTC