RE: [DR008] - passing arbitrary content

A few detailed comments and suggestion for a DR008.

1. Re making the definition of arbitrary content part of the transport
protocol binding.
I have one concern over this, in that you might find that the same message
needs to transported over multiple different transport protocols in order to
get from its starting point to its final destination. If the message is also
digitally signed so as to bind the "arbitrary content" to the XP headers,
then moving from one transport protocol to another might result in the
signature being broken unless the two protocol bindings, that have been
independently written, are consistent. Now you might be able to get around
this if you say that only XML Signature can be used, but I think it would be
safer, and easier, if the method of including arbitrary content was
transport protocol indpendent and defined in only one place. There is then
the question of whether this should be in the base XP spec on in some
supplementary spec.

2. Re fetching out-of-band data that is externally referenced.
Paul said ... "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."

Any required fetching of data by intermediaries, is potentially
problematical since:
a) there is no way of knowing how large the data is
b) it would require the intermediary to know if fetching out-of-band data
was required for a particular message instance and this might vary from
instance to instance,
c) the sender of the message may not know the capabilities of the
intermediaries a message will pass through and therefore will not be able to
tell an intermediary whether to resolve the reference

So I think the better approach is for intermediaries to simply pass
references and not resolve them. When the message reaches its final
destination, then the XP processor at that end might retrieve it, but again
it really depends on the message instance, and could vary from message to
message. Anyway resolving of reference by the destination XP processor is
really an implementation decision and therefore should not be in the spec
anyway.

So my suggestion for a requirement for DR008 would be along the lines of ...

>>>"Support the passing of any data that can be represented in electronic
form either "by value" i.e. within the XP enevelope, "by local reference",
i.e. to data transported at the same time and in the same message as the XP
envelope, or "by external reference" to data held on the web or
elsewhere.<<<

If we did this then section 4.1 should perhaps be renamed "Handling of Any
Data".

Thoughts?

David
-----Original Message-----
From: Paul Denning [mailto:pauld@mitre.org]
Sent: Friday, December 08, 2000 12:39 PM
To: xml-dist-app@w3.org
Subject: 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 17:44:15 UTC