RE: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

["Peter Furniss" <peter.furniss@choreology.com>]

On a couple of points point from Kevin's message


> The August 2005 WS-Addressing spec does not define a means of 
> comparing 
> EPRs but it does not prevent it.  We have the option to define EPR 
> structure and/or rules for comparison within WS-C.

One of the nastiest things protocol standards writers can do to
implementors is take a
supporting specification which has some fields that are of only local
significance and
start adding semantics to them in a higher specification that have to be
understood elsewhere.

An implementation of the supporting spec (WS-A, in this case) can then
wander along quite
happily, meeting all the requirements of that spec, then has to be
re-worked to
used for something else. 

Yes, we could add to the EPR semantics, but we would have to be very
careful.
( not saying anyone has suggested carelessness so far)

> The spec also states that the message ID should be 'an 
> absolute URI that 
> uniquely identifies the message'.  What it doesn't state is 
> the context 
> within which this holds true, whether this is intended to be 
> global or 
> within the context of the sender.
> 
> After all this there appear to be three choices
>   - use the message ID as the identifier and require it to be
>     globally unique (comparison rules already exist).
>   - define a structure for the EPRs to make them globally unique
>     and rules to make them comparable.
>   - Change the request so that it includes a unique 
> identifier associated
>     with the EPR.

Surely it isn't the endpoint you want to identify, but the participant.
There could
be coordination types in the WS-C family that want to know this is the
same participant, perhaps
registering with a different protocol. (actually, is there utility in
knowing that an
interposed coordinator has registered for both volatile and durable
WS-AT, even if the 
EPR's differ ?)

> My initial opinion was that the message ID already does the 
> job so why 
> do we need another mechanism?  We could easily use this to handle 
> retransmission issues.
>
> Having clarified my thoughts while writing this response I 
> now believe 
> that the second or third choice would be preferable.  The 
> only question 
> now would be whether the EPR should remain totally opaque (the last 
> choice) or whether we should have a mechanism to associate an 
> EPR with a 
> participant (the second choice).

It must be kept as an absolute rule that ReferenceParameters are utterly
opaque to anything other than that which is addressed by the Address.
WS-A has promised its implementors they are opaque; we must respect that
(and e.g. allow implementors to have different RefParams for the "same"
endpoint) or we aren't using WS-A. Putting other fields in at the EPR
extension point would be legitimate, but why are we putting our
semantics in someone else's space ?

(probably I'm getting over-excited here :-)

Are there any reasons why we shouldn't put an identifier in the Register
message, comparable to the one in the Context ?

Peter