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

[Alastair Green <alastair.green@choreology.com>]

Kevin,

Sorry to slope sideways into a very active thread, but I just wanted to 
pick up one point, as I try to catch up :-) . Apologies if this repeats 
a point made later.

You said:

"The current mechanism has the registration service generate an 
identifier for the participant which is only understood within the 
domain of the registration service and its associated protocol handling.

"The current suggestion would require an identifier to be generated by 
one domain (the participant) and trusted by a second (the registration 
service).  This would require a globally unique identifier to be created.

"If a participant failed to generate a globally unique identifier then 
the registration service would have no way to know if the registration 
it was seeing was a conflicting identifier or not, at least not with 
this message exchange."

I agree, and I believe that a URI or IRI has the useful property of 
being a globally unique identifier. This seems like a non-problem. Cf. 
Use of URI for /CoordinationContext/Identifier.

Alastair

Kevin Conner wrote:
> Peter Furniss wrote:
>> 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)
>
> I totally agree.  I also think we have to be very careful about adding 
> this retriable funtionality though ;-).
>
> I do not believe we can enforce an idempotent register message as the 
> recovering endpoint may not be successful in obtaining its original 
> endpoint (not all endpoints will have a static IP/port).  If we did 
> specify that it should be idempotent then we have no mechanism of 
> enforcing it as we cannot compare EPRs for equality.
>
> Another issue to be addressed is the participant identifier being 
> suggested.
>
> The current mechanism has the registration service generate an 
> identifier for the participant which is only understood within the 
> domain of the registration service and its associated protocol handling.
>
> The current suggestion would require an identifier to be generated by 
> one domain (the participant) and trusted by a second (the registration 
> service).  This would require a globally unique identifier to be created.
>
> If a participant failed to generate a globally unique identifier then 
> the registration service would have no way to know if the registration 
> it was seeing was a conflicting identifier or not, at least not with 
> this message exchange.
>
>> 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 ?)
>
> Agreed, but I don't see how this changes any suggestion.  The 
> identifier exists somewhere and must be known for retriable register 
> to be possible.
>
>> 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 ?
>
> Sorry, not sure why you think ReferenceParameters are the appropriate 
> extension point.  Could you clarify?
>
>> Are there any reasons why we shouldn't put an identifier in the Register
>> message, comparable to the one in the Context ?
>
> Nope, these were suggested alternatives.
>
>     Kev
>
>