RE: Intermediaries and remote URI references (was: RE: [DR008] - pass ing arbitrary content)

<David>
The point I'm trying to make is that whether or not (as well as when) your
retrieve a reference is something that the XP protocol can't standardize on
as it is a function of the process/application that the XP protocol is
enabling. Therefore the rules on when the data should be retrieved **have**
to specified in the application and not in the XP protocol. Does this make
sense.
</David>

I completely agree.  Evidently, I misunderstood your intent in the phrase
"Any required fetching of data by intermediaries" to mean "required from the
viewpoint of the intermediary" rather than "required by the XP protocol".
There is no reason at the XP level to *require* either an intermediary or
the ultimate destination to do anything at all with a URI reference, even to
check it for resolvability, much less fetch any content.

Sorry about the confusion.

Satish

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Sunday, December 10, 2000 4:02 PM
To: Satish Thatte; xml-dist-app@w3.org
Subject: RE: Intermediaries and remote URI references (was: RE: [DR008]
- pass ing arbitrary content)


Satish

Some comments ...

<Satish>
It seems to me that the primary case when an intermediary would fetch remote
content referenced by a URI is where the URI reference occurs in a header
addressed to that intermediary.  In those cases it may be required to do so
and I don't see how or why it should be avoided.
</Satish>

This could well be true, but it really does depend on what the intermediary
is going to do with the reference. If you think about the architecture of
the solution that would be present at the intermediary, then you would
probably have:
1. Software which is designed to support the XP specification, let's call
this the XP handler.
2. Software which the XP handler interacts with to pass some data or other
information inside or referenced by the XP enevlope to the proccess that
needs to process it, let's call this the application.

Unless you know **exactly** what is required, you could get it wrong. For
example:
1. If the XP handler retrieves the reference, then this could actually be
wrong since, the application requires the most up-to-date version of the
data is retrieved and the application isn't going to process the data for a
day
2. The XP handler doesn't retrieve the reference, but actually the
application was expecting it as it was a legacy system that did not know how
to retrieve the data itself. So in this case the application fails.

The point I'm trying to make is that whether or not (as well as when) your
retrieve a reference is something that the XP protocol can't standardize on
as it is a function of the process/application that the XP protocol is
enabling. Therefore the rules on when the data should be retrieved **have**
to specified in the application and not in the XP protocol. Does this make
sense.

The second issue is that the sender of a message may not know the
intermediaries, a message would go through in order for it to be delivered.
In this case the sender will not know who to send the message to.

<Satish>

Also, on a related note, I hope the current requirements allow for the URIs
used to name intermediaries (actor URIs in SOAPspeak) to actually name
classes of intermediaries (caching server, notification broker, etc) rather
than always being required to name specific XP processors.  I haven't
followed the requirements discussions carefully so if this issue has already
been discussed and decided, I apologize for this "out of band" comment.

</Satish>

Now this is a good idea. Because you are identifying a role/actor that is
always carried out by the XP handler that is an intermediary, XP is in
control of the process and therefore the XP protocol can specify whether or
not a reference should be resolved/retrieved. What I can't so easily think
of is a use case where this would be necessary. No doubt someone can help.

Regards

David


<snip>
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Saturday, December 09, 2000 3:04 PM
To: Burdett, David; 'Paul Denning'; xml-dist-app@w3.org
Subject: Intermediaries and remote URI references (was: RE: [DR008] -
pass ing arbitrary content)


David,

Regarding your concerns

<David>

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

</David>

It seems to me that the primary case when an intermediary would fetch remote
content referenced by a URI is where the URI reference occurs in a header
addressed to that intermediary.  In those cases it may be required to do so
and I don't see how or why it should be avoided.

Also, on a related note, I hope the current requirements allow for the URIs
used to name intermediaries (actor URIs in SOAPspeak) to actually name
classes of intermediaries (caching server, notification broker, etc) rather
than always being required to name specific XP processors.  I haven't
followed the requirements discussions carefully so if this issue has already
been discussed and decided, I apologize for this "out of band" comment.

Satish 

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Friday, December 08, 2000 2:35 PM
To: 'Paul Denning'; xml-dist-app@w3.org
Subject: 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 Sunday, 10 December 2000 19:23:01 UTC