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

RE: Clarification sought on DS805 and DS807

From: Glen Daniels <gdaniels@allaire.com>
Date: Tue, 6 Feb 2001 10:14:08 -0500
Message-ID: <C3843BD1B83DD2119D79000092A7BAD405D9B9A6@platinum.allaire.com>
To: "'David Fallside'" <fallside@us.ibm.com>
Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>


Comments / clarifications below.

> Glen, during last week's XP WG telcon, we started to discuss DS805 and
> DS807. Unfortunately we did not make a lot of progress on these DS's
> because the WG wanted some clarification which you were not 
> available to
> provide. I took the to-do from that meeting to ask you for 
> clarification.
> In particular:
> re. DS805
> -- "certain intermediaries": does this mean a message passes through
> several intermediaries, and/or a message may pass through 
> different types
> of intermediaries?

This scenario was focused on processing intermediaries, not transport
intermediaries, and that should be made more clear in the text.  The intent
was that the entire scenario be in the XP layer.  Potentially, several
intermediaries may be involved, although each of the examples assumes only

> -- "track the identity/IP of the caller": does the caller 
> mean the entity
> that first generated the message, or the last entity to have 
> passed along a
> message (such as an intermediary)?

The former.  The intent would be something like the following:

A privacy advocate wants to utilize a service which requires authentication
of some sort to access some data; let's say news stories.  Our hero doesn't
want the service provider to be able to easily track his authentication
information and associate it with a profile of stories read, so he contracts
with an anonymizing intermediary service.  The XP stack on the client
formats the request just as if it were going to the service itself, but adds
a block addressed to the intermediary which tells it the actual service
address.  The intermediary will then forward the request (sans the routing
block, and plus its own authentication information) to the news service.
The service therefore only knows about the intermediary's identity, not the

> -- "Another example", the WG was concerned that the last sentence was
> describing a rather different scenario, perhaps another scenario that
> merits its own DS?

The signature verification itself may well merit an additional DS (as might
the "anonymization" service above), but the key feature to focus on here is
that the end-user is sending a message to an intermediary who does NOT know
who the next hop will be through any sort of static configuration.  The
"routing" information telling it who to send the message to next is
contained completely within the XP message.  Do people think this makes

If other folks have any other scenarios which reflect this sort of explicit
routing (especially with multiple hops), please send them along as well.
> re. DS807
> -- general comment that the "supplimentary text" is indeed too
> implementation specific for a DS


> -- the nature of the tracking needs further clarification. 
> For example, is
> the trace available for inspection en-route, is it available 
> at the final
> destination, is there an intent to provide a mechanism to 
> send the trace
> from the final destination to the originating sender?

Any/all of the above.  The intent of the scenario was that the originating
sender would receive the list, but the specific mechanism for this (as part
of the response, as a separate notification message, etc) was not specified.

How about the following rewording:

A developer wishes to track her message to see exactly which processing
intermediaries have touched it by the time it arrives at its destination.
Processing intermediaries along the way, as well as the final destination,
must support a known tracking extension so that she is guaranteed a valid
response containing an ordered list of intermediary identifiers (URIs)
describing the message path.

Received on Tuesday, 6 February 2001 10:14:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:11 UTC