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.

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.