Re: Issue 455 closed: Representation header and SOAP processing model

+1

[email protected] wrote:

> First of all, I formally accept this resolution.  We can move ahead, thank 
> you. 
> 
> I should note that, on reflection, I think it would have made sense to say 
> that "if the processing node has knowledge of the role to which the header 
> is addressed, and if the node is aware that no other downstream node can 
> act in such a role, then the representation header need not be reinserted; 
>  in all other situations it MUST be reinserted."  This would avoid the 
> need to send a large representation past an intermediary which had good 
> reason to believe that it would be useless anyway.
> 
> I see no need to reopen the issue unless this observation gets widespread 
> support.  Thank you.
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> "Jean-Jacques Moreau" <[email protected]>
> Sent by: [email protected]
> 03/17/04 04:08 AM
> 
>  
>         To:     [email protected]
>         cc:     Dear XMLP Comments <[email protected]>
>         Subject:        Issue 455 closed: Representation header and SOAP processing model
> 
> 
> 
> Dear Noah,
> 
> You raised issue #455 about the interaction between the SOAP processing 
> model and the Representation Header.
> 
> At its recent f2f, the XMLP WG decided to close[1] this issue by 
> defining a new role (name to be decided), with the following 
> characteristics:
> 
> 1. The role will be used to target all Representation header blocks.
> 
> 2. The Representation header block MUST always be reinserted, even if 
> processed.
> 
> 3a. It's OK for multiple Representation header blocks in the same 
> message to have the same URI and role.
> 
> 3b. Such Representation header blocks would typically have different 
> metadata.
> 
> 4. Implementations MAY need to process Representation header blocks 
> BEFORE other header blocks that might dereference URIs.
> 
> Please let us know immediately if you do not agree with this resolution.
> 
> Regards,
> 
> Jean-Jacques.
> 
> [1] <http://www.w3.org/2004/03/02-xmlprotocol-irc.txt>
> 
> 
> 
>