RE: Proposal for new last call issue: Some unprocessed headers should stay

Gudge, Henrik, Noah, others,

it all boils down to the relative weights of supporting the following
scenarios of targeting (other scenarios are IMHO not affected):

1) targeting the first node playing a given custom role
2) targeting the first understanding node playing a given custom role
3) targeting the first understanding node
4) targeting all the nodes playing a given custom role
5) targeting all the understanding nodes playing a given custom role
6) targeting all the understanding nodes

A) With the status quo, 1 is OK, 2 and 3 are impossible, 4 is doable
only with mU="true" and relaying specified in the module, 5 and 6 are
impossible.

B) With the flipped default (relaying unprocessed headers), 1 is doable
only with mU="true", 2 and 3 are OK, 4 to 6 are all doable with relaying
specified in the module.

C) With the current default and the new role, 1 is OK, 2 is impossible,
3 is doable if the first understanding node plays the new role, 4 is
doable only with mU="true" and relaying specified in the module, 5 is
impossible, 6 is doable with relaying specified in the module and if all
the understanding nodes play the new role.

D) With a new attribute able to change the default locally for a header,
1 to 3 are OK, 4 to 6 are doable with relaying specified in the module.

In a table:
                      |  1  |  2  |  3  |  4  |  5  |  6  |
----------------------|-----|-----|-----|-----|-----|-----|
status quo            |  Y  |  N  |  N  | m,r |  N  |  N  |
flipped default       |  m  |  Y  |  Y  |  r  |  r  |  r  |
new role 'relay'      |  Y  |  N  |  *  |  N  |  N  | r,* |
new attribute 'relay' |  Y  |  Y  |  Y  |  r  |  r  |  r  |

m - mustUnderstand must be true -> limited support
r - relaying must be specified in the module
* - all the affected nodes must play the role
    we would probably end up with virtually all nodes playing the new role

So, clearly the new attribute is the best case. 

As for Henrik's corner cases (see [1]): it is true that this new
attribute would make no sense with mustUnderstand="true" or role="none"
on the same header, but then mU="true" doesn't make any sense on
role="none" header either so that can be considered a normal interaction
between the values. The corner case role="ultimate receiver" with the
new attribute present is also very weak in the light of other headers
already possible that are not targeted at the ultimate receiver - they
also get relayed to nowhere.

If we don't want the new attribute, the flipped default case is IMHO the
second best because it matches better what I perceive as the intended
semantics of roles: "A role name specifies who gets to see a header I
want processed." I think that the additional constraint of "the first
node playing the given role" is artificial and unnecessary. If I wanted
a given node to do something for me, I'd make it play a unique role and
I'd target the header at that role.

The proposed new role would have to be common to all headers that want
the relaying semantics and all the interested nodes would have to play
that role (i.e. all the nodes would play that role) and one could not
say "I only want relayed signature headers, not relayed caching
headers."

Hope I've demonstrated sufficiently that the new role is a suboptimal
solution to the problem.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0055.html

Received on Wednesday, 16 October 2002 16:55:41 UTC