XMLP LC Issue 394 Resolution


You have raised an issue about unprocessed header blocks not 
being relayed in certain circumstances.

The XMLP WG recognises this is an important issue. It has decided 
to introduce a new "relay" attribute. This attribute lets nodes 
explitely specify which header block should be forwarded. More 
precisely, it indicates which unprocessed header blocks, 
targetted at a node assumed by an intermediary, must be forwarded.

In your email, you outlined a similar solution 
("relayIfNotProcessed"), although you recommended adopting a 
simpler proposal ("relay" role) at this late stage of the 
recommandation process.

After carefull consideration and intense discussion, the WG 
decided to go for the more elaborate solution, for the following 

1) The concepts of targetting and forwarding are separate and 
should remain so.

2) With your proposed solution, it would be impossible to target 
a header block at a user-defined role. A relayable block would 
have to always be targetted at the "relay" role, which defeats 
the whole purpose of the "role" attribute.

3) Both solutions would result in about the same amount of 
changes to the spec anyway.

Since your initial email, you have indicated during at least two 
different teleconferences that you would indeed prefer the more 
general solution; we thus trust that you will agree with the WG's 
resolution. Please let us know asap if you think otherwise.

The WG has also taken this opportunity to introduce a new table 
which clarifies and summarizes when and how nodes are allowed to 
forward messages.


Received on Wednesday, 30 October 2002 08:57:34 UTC