RE: Proposed resolution to issue 455

 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Marc Hadley
> Sent: 26 February 2004 15:29
> To: Jacek Kopecky
> Cc: XMLP Dist App
> Subject: Re: Proposed resolution to issue 455
> 
> 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.

But surely such a URI would be refer "to the 'none' header block in some
way"

Gudge

> 
> 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 10:52:59 UTC