- From: Satish Thatte <satisht@microsoft.com>
- Date: Sat, 9 Dec 2000 22:35:54 -0800
- To: "'Mark Nottingham'" <mnot@akamai.com>
- Cc: "'Burdett, David'" <david.burdett@commerceone.com>, "'Paul Denning'" <pauld@mitre.org>, xml-dist-app@w3.org
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