RE: [DR008] - passing arbitrary content

A number of thoughts came to mind reading Oisin's message and others in 
this thread.

At 02:58 PM 2000-12-06, Oisin Hurley wrote:
> >   [DR6xx] Arbitrary content (to include binary data) outside the
> >   XP message shall be accommodated by the protocol binding or in
> >   a manner completely independent of that XP message.
>
>Um, I'm still trying to make out why 'Arbitrary content' is different
>from 'application specific content' - they are both arbitrary and
>scope free to my mind. If you agree, then then let me remind you
>of the text of R700a:


I agree that "application specific content" and "arbitrary content" are the 
same, and we should pick one term and use it consistently in the 
requirement document.


>"The XP specification must define a mechanism or mechanisms that
>allow applications to submit application-specific content or information
>  for delivery by XP.

Does "for delivery by XP" imply part of the XP envelope?  Or by the same 
transport to which XP is bound?
I agree that the solution to the requirement may be to use a URI within the 
XP envelope to refer to data that is either local (i.e., same transport 
binding, for example, using cid: or mid:), or remote (using a different 
protocol binding, or the same protocol but a different session, for 
example, http://<some-other-host>).  But these are solutions, not requirements.


>In forming the standard for the mechanisms, the XP
>  specification may consider support for:


The word "may" is weak language.  The desire by some for a Normative 
approach to this "content" is why I suggested a new DR.  The XP 
specification "must" support referring to application specific payloads 
outside the XP envelope.  I suggested DR6xx because the of the language in 
the SOAP with Attachments proposal [1], which clearly places this in the 
transport binding.  If we're not going to make MIME the XP envelope, then 
allocating the details to the protocol binding (IMHO) makes sense.

I don't understand Henry's comment concerning http as the only normative 
binding.  This proposed requirement would apply to other bindings.  If 
someone defines an SMTP binding, then "Arbitrary content (to include binary 
data) outside the XP message shall be accommodated by the protocol binding" 
still applies.  The binding used for the XP message (e.g., HTTP) may be the 
only binding available to the client.  Although "URI" covers both local and 
remote cases, I'm saying that any binding needs to define the local 
case.  This implies that such a limited client would not be able to support 
XP-based applications that depend on "Arbitrary content (to include binary 
data) outside the XP message, which is completely independent of that XP 
message".

Is it not redundant to say "outside the XP message" and "completely 
independent of that XP message"?

My original wording (without the phrase "or in a manner completely 
independent of that XP message.") was not intended to preclude normative 
definition of Arbitrary content (to include binary data) "inside" the XP 
message.  This requirement would not be in the "protocol binding" section 
of the requirement document, since it would be inside the XP message.

An XP module "may" refer to arbitrary content independent of the protocol 
binding (or instance thereof) used to carry the XP envelope.  That is, 
minimal compliance to XP would require arbitrary content outside the XP 
message but inside the instance of the protocol binding used to carry the 
XP message.  If initially the XP spec only defines an HTTP binding, then it 
would define how this is done in an interoperable way.  Any updates to the 
XP spec or separate protocol binding specs should comply with the XP 
requirement document's section on protocol bindings.

>  - carrying application specific payloads inside the XP envelope,
>  - referring to application specific  payloads outside the XP envelope,
>  - carrying nested XP envelopes as application specific data within the
>    XP envelope,
>  - referring to XP envelopes as application specific data outside the XP
>    envelope"
>
>especially I'd like to draw your attention to bullet point number two.
>
>Also, I'm not sure I agree with tying the extension mechanism to the
>protocol,
>that doesn't feel right at all. Maybe you mean that there should be a way
>to map the extension mechanism to different wire representations, depending
>on the transport protocol - that I could go for. Example, an XP message
>might travel via HTTP and include an ftp hyperlink to the extension data
>(this is a valid use case).
>If this XP message then goes through an
>intermediary
>that decides to change the protocol to SMTP, then the extension data could
>be fetched and mapped to a MIME attachment.

Or the intermediary could simply pass the reference along rather than fetch 
it.  How should XP specify whether the intermediary should fetch the data 
or pass the reference?  It may be that the Ultimate XP receiver would 
prefer that the intermediary fetch the data, and the original XP sender may 
not really care.  How does the XP receiver tell XP senders whether or not 
to fetch out-of-band data and put it in-band (or take in-band data, cache 
it, and pass a reference to the cached data)?


>I'm saying the extension
>mechanism
>that we standardize is the same in both cases, just the mapping to the
>transport protocols is different. The intermediary will have to understand
>that
>it must get the extension data to pass it on, but because it implicitly
>supports
>the HTTP mapping then it should know how to do so.
>
>In summary, I think that the solution to this requirement requires more
>thought
>rather than the requirement itself.
>
>  cheers
>    --oh
>
>--
>ohurley at iona dot com
>+353 1 637 2639


[1] http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0062.html
[2] http://www.ietf.org/internet-drafts/draft-vaudreuil-esmtp-binary2-03.txt
[3] http://www.w3.org/2000/xp/Group/xp-reqs-03#N3010

Paul

Received on Friday, 8 December 2000 15:44:16 UTC