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

Re: i154: are roles invariant?

From: Yves Lafon <ylafon@w3.org>
Date: Thu, 29 Nov 2001 16:54:11 +0100 (MET)
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
cc: "xml-dist-app@w3.org" <xml-dist-app@w3.org>, Noah Mendelsohn <Noah_Mendelsohn@lotus.com>, Doug Davis <dug@us.ibm.com>, Marc Hadley <marc.hadley@sun.com>
Message-ID: <Pine.GSO.4.33.0111291642290.3323-100000@tarantula.inria.fr>
On Thu, 29 Nov 2001, Jean-Jacques Moreau wrote:

> This is a follow up of the discussion that just occurred at the
> f2f.
> Consider the message below. A simple inspection of the message is
> enough for a node to determine it should process blocks <X> and
> <PlayTheFollowingRole>, and only these two blocks. Processing
> then starts. However, during the evaluation of
> <PlayTheFollowingRole>, the node also discovers that it must play
> the role "meAsWell". If it assumes this new role, it breaks the
> invariant (on roles - i154); if it does not, it breaks the

My reading on the paragraph of the spec was more invariant wrt a specific
role, ie: you can't stop acting as a role, and not invariant as the set of
roles assumed by the processor prior processing the message.
The second part saying "an encoding role may be 'encode as identity' on
one message and 'encode as base64' for another message".
As the specs seems unclear, it should be more explicit (either way,
invariant for one role during processing, or for the set of roles).

> contract represented by <PlayTheFollowingRole>.
>   <envelope>
>     <header>
>       <X actor="next" mU="true">...</Y>
>       <PlayTheFollowingRole actor="next" mU="true">meAsWell</X>
>       <Y actor="meAsWell" mU="true">...</Z>
>     </header>
>   </envelope>
> Is it important for us to support such changing roles?

It can be important if the node starts to decipher a blob then find out
that it must act on it using a new role, this role being hidden for
security reason.

Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Thursday, 29 November 2001 10:54:47 UTC

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