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

The most obvious capability would be the ability to process a
particular XP module. Beyond that, it may be useful for there to be
dependencies/triggering between modules. For example, you may only
want to trigger a caching module if the intermediary can process the
encryption module as well.

I'm not saying that this should be defined in XP "core", but the
targeting mechanism should be extensible enough to accommodate them.

[I'll also try and come up with some better examples; it's late and I
have a lot of other things going on right now ;) ]



On Sat, Dec 09, 2000 at 10:35:54PM -0800, Satish Thatte wrote:
> 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)

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

Received on Sunday, 10 December 2000 02:19:33 UTC