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

We're very close to agreeing on this I think.  I guess what I'd like to 
make clear is that someone can write a little spec for yet another role, 
as we have done for sticky.  For example, I should be able to document a 
role http://ibm.com/intermediaryMachineInNoahsOffice .  I would like the 
spec for that role to be able to say:  "if you send a Representation 
header to this role, you MUST NOT reinsert it."  In other words, SOAP 
delegates the reinsertion rules to the specification for the header.  I 
would like the spec for our Representation header to either explicitly or 
implicitly allow for further delegation either to the specification for 
some 2nd header that may coexist with the Rep. header in the message, or 
to the possible specifications for Roles such as the one above.  If we can 
do it for "sticky", it seems to me that someone should be able to do it 
for other roles as well.

Also:  I think the particular name "sticky" is a bit unfortunate.  Would 
"reinsertRepresentation" have a slightly less pejorative connotation? 
Thanks.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Jacek Kopecky <jacek.kopecky@systinet.com>
Sent by: xml-dist-app-request@w3.org
03/23/2004 10:52 AM

 
        To:     Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
        cc:     Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, XMLP Dist App 
<xml-dist-app@w3.org>
        Subject:        Re: Issue 455 closed: Representation    header  and     SOAP    processing 
model



Noah, 

I'm not saying that if Representation mandates some rules, it makes the
nodes that adhere to the rules active intermediaries. But if our rules
say the header may be reinserted but applications should not depend on
that (all in the absence of any more concrete information), I don't see
the point.

I would say: the Representation header specifies nothing about
reinsertion, defaulting to SOAP Processing Model's removal in the
absence of other information. One way of getting such info is from the
role, if the "sticky" role is used. Another is an additional module. Yet
another is the configuration of an active intermediary.

Basically, forwarding intermediaries get the "additional info" from the
incoming message, active intermediaries from their context, too. We
cannot force any open decision processes on forwarding intermediaries,
IMHO.

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/




On Tue, 2004-03-23 at 16:38, noah_mendelsohn@us.ibm.com wrote:
> "A SOAP header block is said to be reinserted if the
> processing of that header block determines that the
> header block is to be reinserted in the forwarded
> message.
> 
> This clearly says that the processing rules for a header block can 
> determine whether to reinsert, even in the case of a forwarding 
> intermediary (I think it's clearly implied that we're talking about 
> forwarding intermediaries here.)  We are writing the specification for 
the 
> processing of this header, so we have permission and indeed SHOULD in my 

> opinion indicate the rules for reinsertion as a result of such 
processing. 
>  My note was intended to offer two options for such a Representation 
> Header processing  specification.  I really don't think that suppying 
such 
> rules makes the node an active intermediary;  on the contrary, I think 
> we're doing what the SOAP Rec tells you to do when specifying the 
> processing of a header at a forwarding intermediary.  Make sense?

Received on Tuesday, 23 March 2004 11:09:10 UTC