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

Mark,

I don't quite understand the capabilities and negation scenarios for
nominating intermediaries.  Could you give some examples?

Thanks,
Satish

-----Original Message-----
From: Mark Nottingham [mailto:mnot@akamai.com]
Sent: Saturday, December 09, 2000 5:58 PM
To: Satish Thatte
Cc: 'Burdett, David'; 'Paul Denning'; xml-dist-app@w3.org
Subject: Re: Intermediaries and remote URI references (was: RE: [DR008]
- pass ing arbitrary content)


On Sat, Dec 09, 2000 at 03:03:48PM -0800, Satish Thatte wrote:
> 
> 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.

While that hasn't been specifically required, it is definately within
the scope of the current targeting requirement, and I for one have
been thinking the same way; I'd like to see intermediary
targeting/nomination by:

- identity (URI/hostname/whatever)
- arbitary class (vendor/operator/nonce as group identifier)
- capabilities (modules present, etc)
- negation of above (process this module if it is *not* class Foo)



> 
> 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
> 
> 

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

Received on Sunday, 10 December 2000 01:36:41 UTC