Re: Proposed resolution to issue 455

Marc,

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?

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.