- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Thu, 15 Mar 2001 17:44:34 +0100
- To: "Mark A. Jones" <jones@research.att.com>
- CC: Henrik Frystyk Nielsen <frystyk@microsoft.com>, Stuart Williams <skw@hplb.hpl.hp.com>, John Ibbotson <john_ibbotson@uk.ibm.com>, Krishna Sankar <ksankar@cisco.com>, Lynne Thompson <Lynne.Thompson@unisys.com>, Marc Hadley <marc.hadley@uk.sun.com>, Martin Gudgin <marting@develop.com>, Nick Smilonich <nick.smilonich@unisys.com>, Oisin Hurley <ohurley@iona.com>, Scott Isaacson <SISAACSON@novell.com>, Yves Lafon <ylafon@w3.org>, xml-dist-app@w3.org
Mark, Thanks for the rewriting and the hard work, although I must admit I preferred the original version. :( "Mark A. Jones" wrote: > 1. An XML Protocol Message consists of zero or more header blocks > and one body block. [...] > There has been some discussion in the past as to whether we should keep the (somewhat artificial) distinction between headers and body. Are you suggesting that we should keep both, instead of just having blocks? Also, how would I be able to send two RPCs to an XMLP Receiver via a single XMLP Message if a Message can only carry one body block? > 1. Each header has an optional associated id (identifier), an > optional actor and an optional mustUnderstand flag. The body > has an optional associated id (identifier) and an optional > actor. The body must be understood. The id is an ID that > identifies the block for the purposes of reference by other > blocks. The actor is a URI used by the XML Protocol Processor > for determining which module to apply to the block. [...] > Noah has suggested (cf issue 41) that we use two different URIs, one for physically identifying the host, one for the identifying the service. Wouldn't this have an impact on the actor attribute? > 1. There are reserved actor URI's with special significance: > http://.../none // matches no module (i.e., an > untargeted header) > http://.../next // matches a default module at the next > processor > http://.../final // matches a default module at the > final processor > http://.../body // matches the module selected at the > final processor (can be used as a target for headers) > [...] > Don't we need some lower level of granularity in these URIs, so we can address, for example, a particular handler? Also, shouldn't the URIs be HTTP agnostic, if we claim we are transport independent? > 1. When a header is selected for processing by a module at an > intermediary, the header is removed from the envelope. [...] > I am concerned by us automatically removing blocks as soon as they are consummed. I think there are cases where you do want to keep consummed blocks from one intermediary to the next, and I would be reluctant to us having to use the push(pop()) kludge, instead of solving the issue properly. If we really want this functionality, shouldn't we at least make it optional? > The processing of a header may result in a fault or a > successful evaluation. A fault terminates processing and > causes a return message containing the fault to be generated if > a return path is available. [...] > Does a fault terminate all processing, including forwarding to the next hop; or does it only terminate processing at the current node, with forwarding still happening? The text probably requires some amount of clarification. I hope this helps, Jean-Jacques.
Received on Thursday, 15 March 2001 11:45:46 UTC