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

+1 to both.

[email protected] wrote:
> 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 <[email protected]>
> Sent by: [email protected]
> 03/23/2004 10:52 AM
> 
>  
>         To:     Noah Mendelsohn <[email protected]>
>         cc:     Jean-Jacques Moreau <[email protected]>, XMLP Dist App 
> <[email protected]>
>         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, [email protected] 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?
> 
> 
> 
> 
> 
> 
>