W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2001

[i41] Addressing within envelope or binding-specific?

From: Hugo Haas <hugo@w3.org>
Date: Thu, 26 Apr 2001 14:11:50 +0800
To: xml-dist-app@w3.org
Message-ID: <20010426141150.B11908@w3.org>
As per my action item, I am forwarding to xml-dist-app a discussion
about issue 41[1] which happened on the administrative mailing list.

  1. http://www.w3.org/2000/xp/Group/xmlp-issues#x41
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

attached mail follows:


At the face-to-face meeting last week, I agreed to take ownership of issue
No. 41. [1]  The issue references an e-mail from Vidur Apparao [2].

I am a little unsure of my specific responsibilities regarding ownership of
this issue, so I guess I'll start by just trying to sort out the concerns
and the terminology as I understand it, ending with a proposal to stimulate
discussion (or maybe just quickly resolve this.)

Background
==========

The pertinent excerpt from Vidur's note is:

>> R200
>>
>> "The XML Protocol must contain a convention for
>> representing calls and replies between RPC (Remote
>> Procedure Call) applications and services."
>>
>>   Section 7 [1] of the SOAP 1.1 spec addresses the
>>   issue of using SOAP for RPC. It provides a
>>   "uniform representation of remote procedure calls
>>   and responses".
>>
>> "The conventions must include the following:
>>
>> 1.Complete and unique identification, by means of
>> URI syntax, of the program, service or object and
>> procedure or method to be called."
>>
>> Section 7 states that the "URI of the target
>> object" is necessary to make an RPC calls and that
>> the "protocol binding [should] provide a mechanism
>> for carrying the URI". It further implies that the
>> method name should be a QName, and is modeled as
>> an element in the SOAP enveloper body.
>>
>> Issue RPC1: The target (program, service or
>> object) URI is pushed down to the protocol binding
>> and is not represented in the envelope instead.
>> While this does not conflict with the
>> requirements, I believe it's an important (and
>> possibly debatable) decision. This decision
>> precludes sending an RPC invocation through an
>> intermediary that uses different protocol bindings
>> for sending and receiving XP messages.
>>

Going back to the original SOAP specification [3]:

>> To make a method call, the following information
>> is needed:
>>
>> * The URI of the target object
>> * A method name
>> * An optional method signature
>> * The parameters to the method
>> * Optional header data
>>
>> SOAP relies on the protocol binding to provide a
>> mechanism for carrying the URI. For example, for
>> HTTP the request URI indicates the resource that
>> the invocation is being made against. Other than
>> it be a valid URI, SOAP places no restriction on
>> the form of an address (see [4] for more
>> information on URIs).

Analysis
========

My impression is that before we can resolve this issue, we must clarify the
relationship between the identification of the "target object", to use the
SOAP terminology, and the actual URI to which a message is sent.  I am not
sure that Vidur would agree, but my view is that the two are in general
different, though may in some circumstances be the same for convenience.

Why?  Let's assume that there is a service, we will call it an object for
now, which accepts purchase orders.  As a client application, I use some
URI to indicate the identity of the service (object) to which I am sending
my purchase order.  Let me further assume that, at a lower level, I have
routing software that is aware of two different transports available to the
same logical destination: one uses HTTP, and the other uses MQSeries.  So,
at a lower level, the routing software will decide to actually open and
HTTP connection (perhaps) to a URI which may or may not be the actual one I
used to identify the service resource.

A further consideration is the case in which several "hops" are needed over
a variety of transports to reach the actual provider of service.

So, in general, the address supplied by the sending application can be
independent of the transport-specific URI actually used for delivery.

Questions to be resolved
========================

So, I propose that there are at least two levels of URI address to which
Vidur's question can be applied:

1) The identity of the service itself
2) The one or more URI's used to physically deliver the message over each
"hop"

For each of these, we can consider what I think is Vidur's essential
question: should the URI be carried within the XML envelope, outside in a
manner determined by the binding, or perhaps both?

In general, the advantage of providing an address within the envelope seems
to be that the message becomes more self describing, that the information
is carried in the standard manner, and that in the case of No. 1 above the
representation is independent of binding and untouched through successive
hops.  The drawback of relying on information in the envelope, as we
discovered during the design of SOAP, is that there can be significant
processing overhead in cracking an XML envelope during message routing and
checking.  Furthermore, I am not sure whether anyone feels there are use
cases for the anonymous routing used for SOAP bodies, and potentially for
other headers.

Noah's proposals
================

Just to start the process of agreeing on a resolution, here is a strawman
(strawperson) proposal:

* For all applications of XMLP, not just RPC, a standard means will be
provided within the envelope to represent the identity of the intended
recipient of each header or the body (using SOAP terminology).  In other
words, this is a proposal pertaining to No. 1 above, calling for an
explicit Actor URI on each header.

* Bindings can, where appropriate, duplicate this information in a binding
specific manner outside the envelope, thus avoiding the need to repeatedly
parse the XML in situations where that is undesirable.

* The addresses discussed in No. 2 above are the private business of each
binding.  In general, the binding need not include such addresses within
the XML envelope, but as always, the binding has the option to create a
binding-specific header to carry information within the envelope is for
some reason the binding finds that the desirable.

For the record, I do not feel that including any of the addresses in the
envelope is necessary to correct operation of the system.  I am going along
with Vidur's recommendations because it seems like reasonably clean design,
and relatively harmless as long as bindings have free to do optimizations
as well.  Worry to take the other route, and like SOAP rely only on the
binding, I think that in multi-hop scenarios, each binding can pass the
destination address to the next.

Also, I personally am somewhat unsure as to why we want to preserve the
asymmetry in SOAP, in which headers destined to intermediaries carry
explicit addresses but headers (such as the body) intended for the last
stop do not.  For that reason, the above proposal treats all headers
symmetrically.

Finally, if this approach is adopted, it highlights the need to clarify our
notions of path and of multi-hop routing... since all headers become
symmetric, there is some question as to how we distinguish the endpoint
from intermediaries, if that even survives as a useful distinction.

In any case, it seems to me that we should adopt the same answer for RPC as
for other messages, especially other request response messages.

I hope this note is useful in starting the discussion.

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x41
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0193.html
[3] http://www.w3.org/TR/SOAP/#_Toc478383532


------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------




attached mail follows:



Noah, 

My phone died halfway through this discussion today, so I'm probably
missing something important.

> So, I propose that there are at least two levels of URI address to
> which Vidur's question can be applied:
> 
> 1) The identity of the service itself
> 2) The one or more URI's used to physically deliver the message over each
> "hop"
> 
[snip]
>
> * For all applications of XMLP, not just RPC, a standard means will be
> provided within the envelope to represent the identity of the
> intended recipient of each header or the body (using SOAP
> terminology).  In other words, this is a proposal pertaining to No.
> 1 above, calling for an explicit Actor URI on each header.

Does this mean that the service URI should be specified as the Body's
Actor? If so, am I correct in assuming that this will not be required
in all messages?



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

attached mail follows:


Mark Nottingham writes:

>> Does this mean that the service URI should be specified as 
>> the Body's Actor? If so, am I correct in assuming that 
>> this will not be required in all messages?

Well, I am still forming my opinions on this, but I tried to craft a 
proposal that would deal with the essence of Vidur's concerns.  A couple 
of factors went into this proposal:

1.  It is not apparent why the ultimate destination should
    be addressed using conventions different from 
    intermediaries.

2.  I detect a trend, which I agree with, that we will
    ultimately deal with message paths and routing
    (and probably therefore identifying the endpoint)
    as some kind of order or partial order on 
    the actors.

Anyway, the proposal is that every header be provided with an explicit 
actor, which for the sake of discussion would not be the empty string. 
Note also something that I had missed until Henrik pointed it out to me: 
in SOAP more than one header can have a null Actor, and BODY is just a 
convenient way for providing one.  Of course, we could change that. 
Anyway, the proposal is an explicit Actor for each header.

>> Does this mean that the service URI should be specified 
>> as the Body's Actor

Well, it needs to be on some header's Actor.  Again, remember that in SOAP 
more than one header can be destined for the endpoint, and contrary to 
appearances, <BODY> is not special except in the case of RPC.  (I 
personally think that aspect of the design needs cleaning up, but that is 
what we have today.)  In other respects, I think the answer is "yes", with 
the caveat that the phrase "the service URI" might or might not have the 
same connotation for everyone.  We still need to be careful regarding the 
degree to which we claim it identifies a specific endpoint in code vs. 
some more abstract notion of destination.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------



attached mail follows:


On Thu, Mar 15, 2001 at 05:23:09PM -0500, Noah_Mendelsohn@lotus.com wrote:
> 
> >> Does this mean that the service URI should be specified 
> >> as the Body's Actor
> 
> Well, it needs to be on some header's Actor.  Again, remember that in SOAP 
> more than one header can be destined for the endpoint, and contrary to 
> appearances, <BODY> is not special except in the case of RPC.  (I 
> personally think that aspect of the design needs cleaning up, but that is 
> what we have today.)  In other respects, I think the answer is "yes", with 
> the caveat that the phrase "the service URI" might or might not have the 
> same connotation for everyone.  We still need to be careful regarding the 
> degree to which we claim it identifies a specific endpoint in code vs. 
> some more abstract notion of destination.

I guess I'm trying to tease apart the relationship between node URIs,
endpoint URIs and service URIs, along with message exchange patterns
and correlation, and also I suppose these abstract destination URIs
that seem to be popping up.

For example, in a response message that's piggybacking on an HTTP
response, there aren't too many things that make sense as the Body's
actor (something that points at the final receiver) except "the
request's originator" in some form. Since we most likely don't know
it unless the request message tells us, this has to be an anonymous
construct like "http://.../client" (I personally don't like this
style of URI much, but that's for a different day). It also doesn't
seem to make sense to put in the service URI here at all (or maybe we
have different definitions of Service URI).

It seems like we'll need abstract URIs that cover this case and
others like it. Should they be defined by the binding specification,
or at a more global level?


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

attached mail follows:


Mark Nottingham wrote:

> [...] in a response message that's piggybacking on an HTTP
> response, there aren't too many things that make sense as the Body's
> actor (something that points at the final receiver) except "the
> request's originator" in some form. Since we most likely don't know
> it unless the request message tells us, this has to be an anonymous
> construct like "http://.../client"

You make me wonder whether we should not make Noah's proposal (i41) more
symmetric, ie not just allocate a service URI to the endpoint/receiver, but also
allocate one to the sender. This is probably necessary when using transports
that do not directly support request-response patterns, such as SMTP. Comments?

> (I personally don't like this style of URI much, but that's for a different
> day). [...]

I agree.

Jean-Jacques.


attached mail follows:


hmmm, I think this may be necessary.  Otherwise, the idendity of the
sender may be lost if processed by different intermediaries

marwan

Jean-Jacques Moreau wrote:
> 
> Mark Nottingham wrote:
> 
> > [...] in a response message that's piggybacking on an HTTP
> > response, there aren't too many things that make sense as the Body's
> > actor (something that points at the final receiver) except "the
> > request's originator" in some form. Since we most likely don't know
> > it unless the request message tells us, this has to be an anonymous
> > construct like "http://.../client"
> 
> You make me wonder whether we should not make Noah's proposal (i41) more
> symmetric, ie not just allocate a service URI to the endpoint/receiver, but also
> allocate one to the sender. This is probably necessary when using transports
> that do not directly support request-response patterns, such as SMTP. Comments?
> 
> > (I personally don't like this style of URI much, but that's for a different
> > day). [...]
> 
> I agree.
> 
> Jean-Jacques.

attached mail follows:


Jean-Jacque Moreau suggests:

>> not just allocate a service URI to the 
>> endpoint/receiver, but also allocate one 
>> to the sender

Maybe, but I think there may be situations in which a sender doesn't in 
any useful sense know its own name, but in which the binding knows the 
return path implicitly.  As we have seen on the web with NAT and other 
protocols, not all clients have useful IP addresses or DNS names, for 
example.  I think it should be possible to send an XMLP request/response 
from these.  Of course, you could fake out a return address, but the point 
is that in certain cases it really is the binding and underlying transport 
that do the correlation and routing.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------



attached mail follows:


Noah_Mendelsohn@lotus.com wrote:

> Jean-Jacque Moreau suggests:
>
> >> not just allocate a service URI to the
> >> endpoint/receiver, but also allocate one
> >> to the sender
>
> Maybe, but I think there may be situations in which a sender doesn't in
> any useful sense know its own name, but in which the binding knows the
> return path implicitly.  As we have seen on the web with NAT and other
> protocols, not all clients have useful IP addresses or DNS names, for
> example.  I think it should be possible to send an XMLP request/response
> from these.  Of course, you could fake out a return address, but the point
> is that in certain cases it really is the binding and underlying transport
> that do the correlation and routing.

Maybe implicitely behind my suggestion was the possibility that we might do
response dispatching (on the client), and not just request dispatching (on the
server), through processors/handlers. This would make the whole architecture
more symmetric.

Jean-Jacques.

attached mail follows:




>>> <Noah_Mendelsohn@lotus.com> 03/16/01 03:20PM >>>
>Jean-Jacque Moreau suggests:
>
>>> not just allocate a service URI to the 
>>> endpoint/receiver, but also allocate one 
>>> to the sender
>
>Maybe, but I think there may be situations in which a sender doesn't in 
>any useful sense know its own name, but in which the binding knows the 
>return path implicitly.  As we have seen on the web with NAT and other 
>protocols, not all clients have useful IP addresses or DNS names, for 
>example.  I think it should be possible to send an XMLP request/response 
>from these.  Of course, you could fake out a return address, but the point 
>is that in certain cases it really is the binding and underlying transport 
>that do the correlation and routing.

Agreed, as long as their is a common place where the sender name could go. 
It should be optional, but should be consistently there, and by "faked out" I
assume you mean some "null" or "empty" or "unknown" or "anonymous" type
special names that could be used in place of a real name.

Scott


> <snip/>


attached mail follows:


I am concerned that the address of the client be lost as a request
traverses multiple intermediaries that uses different protocol binding. 
That is why I advocate a mechanism to carry a client URI or address in a
request.  The client or an intermediary may fill this entry.

marwan

Scott Isaacson wrote:
> 
> >>> <Noah_Mendelsohn@lotus.com> 03/16/01 03:20PM >>>
> >Jean-Jacque Moreau suggests:
> >
> >>> not just allocate a service URI to the
> >>> endpoint/receiver, but also allocate one
> >>> to the sender
> >
> >Maybe, but I think there may be situations in which a sender doesn't in
> >any useful sense know its own name, but in which the binding knows the
> >return path implicitly.  As we have seen on the web with NAT and other
> >protocols, not all clients have useful IP addresses or DNS names, for
> >example.  I think it should be possible to send an XMLP request/response
> >from these.  Of course, you could fake out a return address, but the point
> >is that in certain cases it really is the binding and underlying transport
> >that do the correlation and routing.
> 
> Agreed, as long as their is a common place where the sender name could go.
> It should be optional, but should be consistently there, and by "faked out" I
> assume you mean some "null" or "empty" or "unknown" or "anonymous" type
> special names that could be used in place of a real name.
> 
> Scott
> 
> > <snip/>

attached mail follows:



Is enabling intermediaries which do this one of the things we want to
do 'out-of-the-box', or just allow?



On Mon, Mar 19, 2001 at 07:19:39AM -0500, marwan sabbouh wrote:
> I am concerned that the address of the client be lost as a request
> traverses multiple intermediaries that uses different protocol
> binding.  That is why I advocate a mechanism to carry a client URI
> or address in a request.  The client or an intermediary may fill
> this entry.
> 
> marwan
> 
> Scott Isaacson wrote:
> > 
> > >>> <Noah_Mendelsohn@lotus.com> 03/16/01 03:20PM >>>
> > >Jean-Jacque Moreau suggests:
> > >
> > >>> not just allocate a service URI to the
> > >>> endpoint/receiver, but also allocate one
> > >>> to the sender
> > >
> > >Maybe, but I think there may be situations in which a sender
> > >doesn't in any useful sense know its own name, but in which the
> > >binding knows the return path implicitly.  As we have seen on
> > >the web with NAT and other protocols, not all clients have
> > >useful IP addresses or DNS names, for example.  I think it
> > >should be possible to send an XMLP request/response from these. 
> > >Of course, you could fake out a return address, but the point is
> > >that in certain cases it really is the binding and underlying
> > >transport that do the correlation and routing.
> > 
> > Agreed, as long as their is a common place where the sender name
> > could go. It should be optional, but should be consistently
> > there, and by "faked out" I assume you mean some "null" or
> > "empty" or "unknown" or "anonymous" type special names that could
> > be used in place of a real name.
> > 
> > Scott
> > 
> > > <snip/>

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

attached mail follows:


That is what we have to agree on.  I am not sure what the answer is.What
are the trade-offs between the two options?What are the trade-offs
between the two options?  I am tempted to say that we just  allow that.
This way, the specification can be written in a modular way.  On the on
the other hand, this may result in different vendors implementing the
same functionality in many different ways, unless some working group
address these issues.   .

Mark Nottingham wrote:
> 
> Is enabling intermediaries which do this one of the things we want to
> do 'out-of-the-box', or just allow?
> 
> On Mon, Mar 19, 2001 at 07:19:39AM -0500, marwan sabbouh wrote:
> > I am concerned that the address of the client be lost as a request
> > traverses multiple intermediaries that uses different protocol
> > binding.  That is why I advocate a mechanism to carry a client URI
> > or address in a request.  The client or an intermediary may fill
> > this entry.
> >
> > marwan
> >
> > Scott Isaacson wrote:
> > >
> > > >>> <Noah_Mendelsohn@lotus.com> 03/16/01 03:20PM >>>
> > > >Jean-Jacque Moreau suggests:
> > > >
> > > >>> not just allocate a service URI to the
> > > >>> endpoint/receiver, but also allocate one
> > > >>> to the sender
> > > >
> > > >Maybe, but I think there may be situations in which a sender
> > > >doesn't in any useful sense know its own name, but in which the
> > > >binding knows the return path implicitly.  As we have seen on
> > > >the web with NAT and other protocols, not all clients have
> > > >useful IP addresses or DNS names, for example.  I think it
> > > >should be possible to send an XMLP request/response from these.
> > > >Of course, you could fake out a return address, but the point is
> > > >that in certain cases it really is the binding and underlying
> > > >transport that do the correlation and routing.
> > >
> > > Agreed, as long as their is a common place where the sender name
> > > could go. It should be optional, but should be consistently
> > > there, and by "faked out" I assume you mean some "null" or
> > > "empty" or "unknown" or "anonymous" type special names that could
> > > be used in place of a real name.
> > >
> > > Scott
> > >
> > > > <snip/>
> 
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)

attached mail follows:


I think this is an example of a choice that we will face repeatedly in a 
variety of areas: which things to encoding the envelope in a fixed manner, 
and which to propagate hop to hop.  I think either is capable, in 
principle, of routing a return message through multiple transports, but 
the trade-offs are different.

If the return address is to be encoded in a fixed manner in the envelope, 
then we need to deal with the case were the original sender does not in 
any useful sense know its identity (per my original note), or the related 
case in which the sender has some notion of its identity, but not in a 
form that would actually be useful for routing a return message.  Consider 
message that first went through the public network, and then through some 
company's private message queuing system (MQSeries, etc.)   Yes, in 
certain cases the originator could put a URI into the envelope to identify 
itself.  Whether that URI would in fact be the most useful routing cookie 
to send the response back through MQSeries would depend a lot on how the 
application and the environment were built behind the firewall. 
Furthermore, we know that parsing and perhaps updating the XML envelope 
tends to have performance implications, and is to be avoided in situations 
where low overhead is desired.

The trade-offs are different, I think, for hop by hop propagation of 
return addresses.  Let's assume that the message originates through HTTP, 
and the ultimate response is to be generated quickly enough to send over 
the HTTP response Channel.  The originator puts no indication in the 
envelope, but sends the outbound message and the connection remains open. 
The message arrives at what I think we are calling the transport 
intermediary, for requeuing perhaps over MQSeries.  The software 
responsible for the requeuing would have to send through MQSeries, either 
in the SOAP envelope or in some binding-specific manner (compare to 
SOAPAction) an indication that an open HTTP connection is waiting for the 
response, and some cookie usable to find that connection when the response 
returns.  Presumably the work would be done, a response generated back 
through MQSeries carrying the cookie, and the correct connection would be 
identified for responding through HTTP.

I am not trying to make a quick decision as to which are these 
architectures is better, merely pointing out that both are possible and 
that there are trade-offs.  I think we will face analogous decisions for 
much of the information that relates to routing and message patterns over 
multiple transports.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







marwan sabbouh <ms@mitre.org>
03/19/01 07:19 AM

 
        To:     Scott Isaacson <SISAACSON@novell.com>
        cc:     moreau@crf.canon.fr, Noah_Mendelsohn@lotus.com, 
w3c-xml-protocol-wg@w3.org, xml-dist-app@w3.org
        Subject:        Re: Addressing within envelope or binding-specific?

I am concerned that the address of the client be lost as a request
traverses multiple intermediaries that uses different protocol binding. 
That is why I advocate a mechanism to carry a client URI or address in a
request.  The client or an intermediary may fill this entry.

marwan

Scott Isaacson wrote:
> 
> >>> <Noah_Mendelsohn@lotus.com> 03/16/01 03:20PM >>>
> >Jean-Jacque Moreau suggests:
> >
> >>> not just allocate a service URI to the
> >>> endpoint/receiver, but also allocate one
> >>> to the sender
> >
> >Maybe, but I think there may be situations in which a sender doesn't in
> >any useful sense know its own name, but in which the binding knows the
> >return path implicitly.  As we have seen on the web with NAT and other
> >protocols, not all clients have useful IP addresses or DNS names, for
> >example.  I think it should be possible to send an XMLP 
request/response
> >from these.  Of course, you could fake out a return address, but the 
point
> >is that in certain cases it really is the binding and underlying 
transport
> >that do the correlation and routing.
> 
> Agreed, as long as their is a common place where the sender name could 
go.
> It should be optional, but should be consistently there, and by "faked 
out" I
> assume you mean some "null" or "empty" or "unknown" or "anonymous" type
> special names that could be used in place of a real name.
> 
> Scott
> 
> > <snip/>




attached mail follows:


This seems like a question between network routing and document 
routing.  In either case it calls for  a path to the initial XMLP sender 
with identification of the sender through a URI, as the transport layer 
information (i.e., sender) is not necessarily available to the XMLP 
layers.  I have a couple of quick questions on how this relates to the 
requirements:

    * R302 says "without prior agreement"
      
          * Does this require the XMLP layer to preserve the URI of the  
            initial XMLP sender? 
          * Does this also require preservation of the entire sequence 
            of intermediary URIs in the document? 
          * Do these URIs have to resolve to the same physical resources 
            on the reply path or subsequent returns?  The introduction 
            to section 4.4 ("intermediaries cannot be implicitly 
            defined") may be logical (units that are in some sense 
            equivalent) rather than physical (identical and state cannot 
            in any case be ensured)
          * May the return path resolve intermediaries through a URI 
            reference instead of carrying a self contained URI list of 
            intermediaries?
            
    * R304 says "many transport or application protocol bindings ... 
      without information loss".
      
          * Does this reinforces the document centric approach rather 
            than an intermediary centric one?
          * Does it allow the mutable documents can either be self 
            contained or URI-reference based?  
            
    * R608  requires the possibility of bindings to SSL channels. 
      
          * Does this suggest a document based approach allowing for the 
            secure flow of information? 
          * Where would a document embedded context be defined?  At the 
            XMLP or at the "application" layer?  Is this a candidate for 
            a suggested standard module?
          * Is it permissible that an initial path setup construct a 
            path of "lilly pads" for stepwise processing, and that 
            subsequent phases reuse this path?
            
Michah Lerner
michah@att.com
Received on Thursday, 26 April 2001 02:12:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:00 GMT