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

Sure - This makes sense. I'm still thinking of functionalities that
we should support, not necessarily about the implementation.


On Sun, Dec 10, 2000 at 04:27:50PM -0800, Satish Thatte wrote:
> <Mark>
> 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.
> </Mark>
> 
> Why can't these cases be covered by the "named class of intermediaries"
> notion?  Seems to me that this resembles the "named type vs structural type"
> contrast.  Named types are usually good enough and often carry semantics
> beyond the structure.  Structural types only make sense where name agreement
> is hard to come by and structure carries sufficient information about
> intent.  In this case, I am having trouble seeing the value of structural
> typing.
> 
> Satish
> 
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@akamai.com]
> Sent: Saturday, December 09, 2000 11:20 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)
> 
> 
> 
> 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)

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

Received on Sunday, 10 December 2000 19:44:42 UTC