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

moving to a discussion list .....


............................................
David C. Fallside, IBM
Data Management Standards
Tel 530.477.7169 (TL 544.9665)
[email protected]

----- Forwarded by David Fallside/Santa Teresa/IBM on 03/18/2004 11:18 AM
-----
                                                                           
             Anish Karmarkar                                               
             <Anish.Karmarkar@                                             
             oracle.com>                                                To 
             Sent by:                  Noah Mendelsohn/Cambridge/IBM@Lotus 
             xmlp-comments-req                                          cc 
             [email protected]               Jean-Jacques Moreau                 
                                       <[email protected]>, 
                                       Dear XMLP Comments                  
             03/18/2004 11:07          <[email protected]>              
             AM                                                    Subject 
                                       Re: Issue 455 closed:               
                                       Representation header and SOAP      
                                       processing model                    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





[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 would imagine that a node that has knowledge of the downstream nodes
and their capabilities/roles would be an active intermediary and in that
case all bets are off. Comments?

> 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>
>
>
>
>