RE: treatment of ns prefixes by intermediaries

Matt Long asks:

> Is the issue in relaying a header 'as is,' i.e., when a
> header is processed by an intermediary then forwarded
> without modification.  However, if a header were
> processed, then modified and forwarded, it would seem
> intuitive (to me) that preservation of the prefixes
> would not apply.
> 
> Is that a fair assessment?

Close, but I don't think you're slicing it quite the way the specification 
does.  What it says, as I understand it, is that there are two cases:

1) The node did not process the header.  This can be because it was not 
targeted to the node, or because mustUnderstand was false and the node 
chose not to process.  In this case, the infoset must be preserved, modulo 
the 20 or so exceptions listed, and the prefix must be preserved.

2) The header was processed.  Now remember, the SOAP spec defines 
processing as "do what the spec for the header block itself says".  It 
then says, if processed, you must remove, but may if the feature calls for 
it reinsert.  So, in this case, I think the header that's reinserted is 
completely under the control of the specification for that header.  Its 
rules may be as simple as "if you're not a caching node, just reinsert 
me".  So, it can make up its own rules about prefixes.  Now, if I were 
WS-I.org and I were doing a profile for features, I might well say 
"specifications for headers to be reinserted should follow the same rules 
and restrictions as for headers not processed."  The SOAP spec defers to 
whoever specifies the header block itself.

That's my understanding anyway.  Hope this helps.

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

Received on Wednesday, 12 February 2003 21:57:33 UTC