Re: Proposed resolution to issue 455

Marc, 

a little bit of thinking about 'none' here made me understand your
point. Data inside headers targeted at none can only be used if pointed
to by normal XML linking mechanisms - an ID, XPath etc, whose scope is
the whole Envelope. I admit it would be a bit of a stretch if we said
URI being the same as that of this header applied to this situation.

Therefore I withdraw my suggestion that "none" should be used for
Representation.

With that in mind, I'd phrase rule iii as 

(iii) Even if an intermediary understands (and processes) the
Representation header, relaying is governed by the soap:relay attribute.

I don't think this changes the semantics of the attribute significantly,
it just makes it useful in situations where it wouldn't normally apply.

Jacek

On Thu, 2004-02-26 at 16:28, Marc Hadley wrote:
> On Feb 26, 2004, at 5:42 AM, Jacek Kopecky wrote:
> >
> > I see a problem with point iii: let's say I'm a node playing several
> > roles, next amongst them (naturally). I look at the headers and it 
> > turns
> > out there is a Representation header targeted for me. Why should I care
> > which me (which of the roles I play) it is, just to vary the 
> > reinsertion
> > rules?
> >
> So a variation of (iii) to address your concern would be:
> 
> (iii) If an intermediary processes a Representation header block then 
> it should reinsert it.
> 
> I guess the only problem with that is how do I create a message such 
> that the Representation header block is removed at some point in the 
> message path ?
> 
> As I stated in the call, I think the use of the 'none' role is wrong in 
> this case. Use of 'none' requires that intermediaries and the ultimate 
> recipient shouldn't process the header block directly (it would be OK 
> to process it if another header block targeted to the node referred to 
> the 'none' header block in some way). Having the header block 'in 
> scope' for URI resolution but not being part of the node processing of 
> the message seems quite wrong to me.
> 
> Marc.
> 
> > I think reinsertion rules should be specified regardless of the role 
> > for
> > which a header is targeted. Therefore either it should always be
> > reinserted or it should always be dropped (unless a node doesn't
> > understand the header and relay says to reinsert it).
> >
> > I don't see why the Representation header should specify that it should
> > be reinserted in any case. Like Gudge, I think the role 'none' is
> > precisely for this usecase - whoever wants it may use it, nobody drops
> > it. In applications where I want to target a specific non-none role (no
> > matter whether application role or next or ultimate recipient) it means
> > I know who I intend this representation for.
> >
> > Anyway, since I haven't seen an actual deployment that uses
> > intermediaries and roles, I expect normal usage won't specify the role
> > (i.e. ultimate recipient) or should just say 'none' if my 
> > interpretation
> > of it prevails. 8-)
> >
> > Best regards,
> >
> >                    Jacek Kopecky
> >
> >                    Systinet Corporation
> >                    http://www.systinet.com/
> >
> >
> >
> >
> > On Wed, 2004-02-25 at 23:03, Marc Hadley wrote:
> >> I took an action to propose a resolution to issue 455[1]. The issue
> >> concerns the relationship of the Representation header block to the
> >> SOAP processing model.
> >>
> >> The proposed resolution:
> >>
> >> (i) A representation header block is only 'in scope' wrt to URI
> >> resolution if the representation header block is targetted at a role
> >> played by the SOAP node.
> >>
> >> (ii) The normal SOAP processing rules apply: the role, mustUnderstand
> >> and relay attributes all function as normal.
> >>
> >> (iii) If the header block is targetted at the standard 'next' role and
> >> is processed by an intermediary then it should be reinserted.
> >>
> >> (iv) Another (different) header block could be used to override (iii)
> >> above.
> >>
> >> The issue also includes the following question:
> >>
> >> "If I want to specifically cause two different representations, of the
> >> same
> >> media type for the same resource, to be sent to A and B respectively,
> >> can I
> >> safely use multiple representation headers that differ in their
> >> soap:roles
> >> to do this?  I would think so."
> >>
> >> I think the answer is yes, but (unfortunately) our current rules would
> >> require that, when using our SOAP binding, each representation header
> >> include a different MIME part (since we disallow multiple inclusions 
> >> of
> >> a single MIME part) - i.e. this would require multiple copies of the
> >> data in the XOP package.
> >>
> >> Regards,
> >> Marc.
> >>
> >> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x455
> >>
> >> ---
> >> Marc Hadley <marc.hadley at sun.com>
> >> Web Products, Technologies and Standards, Sun Microsystems.
> >
> >
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Products, Technologies and Standards, Sun Microsystems.

Received on Thursday, 26 February 2004 11:07:23 UTC