FW: [bt-spec] URIs and address-as-X (MAJOR)

["WEBBER,JIM (HP-UnitedKingdom,ex1)" <jim_webber@hp.com>]

Whoops, forgot to CC this to the list...

> -----Original Message-----
> From: WEBBER,JIM (HP-UnitedKingdom,ex1) 
> Sent: 28 January 2002 17:27
> To: 'Peter Furniss'
> Subject: RE: [bt-spec] URIs and address-as-X (MAJOR)
> 
> 
> Peter:
> 
> I've a few suggestions to add to your ideas. Inlined.
> 
>  1. Context
> Problem: The transaction here is uniquely identified by a 
> "set of BTP addresses" and superior identifier. This is way 
> too complex and in my mind breaks encapsulation since I don't 
> actually care that this transaction is present at/managed by 
> by a number of BTP superior addresses.
> 
> Remedy: Remove Superior Identifier and Superior Addresses, 
> replace with URIs (which at the back-end may well map onto a 
> number of places where the transaction can be managed).
>  
> I think it still needs to carry the Superior address set, 
> because otherwise there is no knowledge of where to send the 
> ENROL (unless it happens to be appropriate to one-shot, but 
> it isn't always). The globally unambiguous Identifier says 
> what it is. The address set tells you where to talk to 
> someone who knows about it.
> 
> [JW] It still does carry the set of superior addresses here, 
> but in URI form "URIs (which at the back-end may well map 
> onto a number of places where the transaction can be managed)."
> 
> 3. Request_Status
> 
> Problem: Target Address, Reply Address, and target identifier 
> all appear here. Target address and reply address are 
> transport issues. Target identifier is useless without the 
> target address.
> 
> Remedy: Target identifier becomes a URI. Reply address and 
> target address disappear. The request_status operation is 
> invoked on the endpoint described by target identifier and 
> the reply address is implicity assumed to be the same 
> endpoint as the entity that issued the message (this is 
> easily catered for in most common transports like HTTP and 
> SMTP). The situation where a reply address is actually 
> different from the sender's address can be handled by the 
> sender simply redirecting replies on behalf of the real recipient.
>  
> Except that you shouldn't assume the target identifier 
> describes an endpoint. It identifies a state, which is 
> accessible at an endpoint. Otherwise, I think this is just an 
> example of what is specified in the binding details. In 
> practice, I would think it very unlikely that an 
> implementation using the soap http binding would do anythng 
> other than omit the reply address, which (in accordance with 
> the request/response exploitation rules) forces the target 
> actor to put the reply on the http response.
> 
> [JW] Isn't this just wordplay? The request_status message 
> gets me the state of an actor (which obviously has some kind 
> of endpoint) at a particular instant. The point is that the 
> request_status message can be simplified.
> 
> 22. Redirect
> 
> Problem: The redirect message seems overly complex. The 
> mechanism isn't too bad per se (new addresses for the same 
> identifiers), however it may be possible reconcile 
> redirection with the new URI-based philosophy.
> 
> Remedy: Ditch the new and old addresses. Instead go for a 
> (set of?) new superior/inferior identifiers as URIs.
>  
> 
> Ouch. This is why it is a really bad idea to bundle 
> location/routing/accessing information into the identifiers. 
> The only way the Superior (say) can sort out which inferior 
> is which is from the identifier - and now you change its 
> name. And it's always possible for a REDIRECT to get lost, so 
> we now get messages turning up from what appear to be 
> entirely unknown Inferiors. With the old way of doing things, 
> at least the identifier was unambiguous within the scope of 
> all the addresses it might have (actually the old way was 
> subtly broken at this point - but this would be much more broken). 
> 
> Make the identifiers globally unambiguous and 
> location-agnostic..  Have addresses to say where things are 
> at the moment.
> 
> [JW] A subtle break is possibly the worst kind since it is 
> likely to go un-noticed. Perhaps this is symptomatic of a 
> much deeper set of problems with addressing and redirection.
> 
> Issue: do alternate addresses (e.g., list of 
> address-as-decider) contain the primary end-point as well as 
> the alternates, or just the alternates?
>  
> all of them. In practice, I expect most implementations will 
> use a list of one. But the minority are very important.
> 
> [JW] Maybe just the alternates since the "primary" is already 
> known and being used where failures requiring redirection do 
> not occur.
> 
> [JW] In short I think what Mark and I were getting at is that 
> there are a number of redundant entities in the message set 
> which could be simplified (which is to the good). URIs don't 
> tie you to a protocol, and the given URN counter-example will 
> make sense within a particular BTP deployment. For our 
> SOAP-over-HTTP binding URLs are just the ticket. I see no 
> harm in fully qualifying each entity with a URI rather than 
> messing around with addresses plus differentiators which is 
> no more or no less descriptive, but is more difficult to understand.
> 
> 
> Jim
>