Re: Proposed resolution to issue 455

On Feb 26, 2004, at 10:52 AM, Martin Gudgin wrote:
>>
>> 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"
>
I was thinking more along the lines of another header block whose 
semantics specifically enable one or more Representation headers. You 
could say that any header that contains a URI that matches the URI of 
the Representation header does that implicitly but the linkage seems 
rather weak. This would also mean that you couldn't support the use 
case in the issue:

> "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."

If both Representation header blocks are in scope how could I target 
them ?

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.
>>
>>
---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.