RE: treatment of ns prefixes by intermediaries

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?

-Matt Long


> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]
On
> Behalf Of Noah Mendelsohn/Cambridge/IBM
> Sent: Tuesday, February 11, 2003 6:55 PM
> To: mlong@phalanxsys.com
> Cc: 'David Fallside'; 'Martin Gudgin'; 'Sanjiva Weerawarana';
xml-dist-
> app@w3.org
> Subject: RE: treatment of ns prefixes by intermediaries
> 
> 
> > I assume that 'preserve' and 'reuse' are distinct,
> > i.e., that an intermediary is not required to 'reuse'
> > prefixes for inserted headers.
> 
> I think Matt raises an interesting question.  We have the model (which
> I've always thought was a bit too tricky, BTW), that processed headers
are
> removed, but that possibly identical ones can be reinserted if the
feature
> so directs.  Fine, but this means that each feature should specify
whether
> the reinserted headers must preserve prefices.
> 
> I think interop would be improved if we could basically say.
> "Specifications for such features SHOULD, when practical, ensure that
the
> infoset of the reinserted header conforms to the rules that would have
> applied if the header had not been processed."  I'm sure there's a
less
> lumpy way to say it, but I'm trying to give transparency to the next
> downstream node.  If A sends to B sends to C, then C gets the same
header
> regardless of whether B ignored or processed and reinserted.  Possible
> spec clarification?
> 
> ------------------------------------------------------------------
> 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 07:51:43 UTC