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

Noah, 

I wouldn't like the text to suggest that inventing roles for various
relaying semantics is necessarily a good practice because I have a
feeling these would mostly be one-off deployment-specific specs.

Also, if it's a header that uses the representation, we can assume that
that header is targeted at a specific role and it would only be natural
that the representation header would follow suit, and if any kind of
smart reinserting was necessary, well, that's what active intermediaries
are allowed to do. 

I don't think there is much space for interop problems here and specs
are meant to achieve interop, so I don't think there is much space for
specification here. Therefore, I'd just say that nodes receiving
Representation headers should consider whether or not to reinsert, and
that in some cases a special role may be useful.

Best regards,

                   Jacek Kopecky

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




On Fri, 2004-03-19 at 00:25, noah_mendelsohn@us.ibm.com wrote:
> 
> 
> 
> (moved to distApp for discussion)
> 
> Anish Karamarkar writes (on the XMLP Comments list):
> 
> > 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 was thinking about it a bit differently.  The rules for forwarding
> intermediaries say [1]:
> 
> "Forwarding SOAP intermediaries MUST also obey the specification for the
> SOAP forwarding features being used. The specification for each such a
> feature MUST describe the required semantics, including the rules
> describing how the forwarded message is constructed. Such rules MAY
> describe placement of inserted or reinserted SOAP header blocks. Inserted
> SOAP header blocks might be indistinguishable from one or more of the
> header blocks removed by the intermediary. Processing is defined here in
> terms of re-inserting header blocks (rather than leaving them in place) to
> emphasize the need to process them at each SOAP node along the SOAP message
> path."
> 
> So, the header (feature/module) specification must tell us whether a
> forwarding intermediary re-inserts a header that has been processed.  In
> this case, I am proposing that our particular specification for the
> representation header defer to specifications that may be written to
> describe particular roles.  So, for example, the SOAP Rec. itself specifies
> the special roles next, etc.
> 
> My proposal is that I should be able, for example, to say that the node:
> http://example.org/noahsMachine is in fact a role that is by definition to
> be assumed only by my machine.  Of course, SOAP processing software in
> general has no particular knowledge of this, but nothing prevents
> particular nodes from choosing to be aware of this rule.  I am suggesting
> that we allow for the >possibility< that such roles would be invented, and
> that their specifications would suggest that it would be unnecessary to
> relay the content further.  I think this is consistent with forwarding
> intermeds. as defined in SOAP.
> 
> There is one loophole with which one does have to be careful: there is no
> mustUnderstand for role names.  So, while I think the above is possible, it
> should only be attempted in situations in which the sender has high
> confidence that the targeted receiver will do the right thing, or that
> downstream nodes will be tolerant if it doesn't (e.g. dsigs won't break if
> the content is not removed.)
> 
> Which reminds me:  we should probably also say that all these rules for
> Representation are to be observed unless overridden by the specification
> for some other header that was understood and processed at the node.  This
> will allow us to later invent headers that change the rules for retaining
> representation (unlikely, but no reason not to leave the door open I
> think.)
> 
> Noah
> 
> [1] http://www.w3.org/TR/soap12-part1/#forwardinter
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
>

Received on Friday, 19 March 2004 10:33:18 UTC