RE: [business-transaction] Re: [bt-spec] URIs and address-as-X (M AJOR)

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

> No, (our version) address == endpoint.  identifier == transaction

Right, in my mind an endpoint == transaction since an address just gets me
halfway there.

> it is spurious simplicity, because you have to specify the 
> rules for how to treat the different parts of your identifier 
> so that something that wants to use it to send a message 
> knows which bit to pass to its end of the carrier 
> implementation, and which bit to ignore, because it is only 
> going to be used at the destination to distinguish the 
> transaction among the several that
> (normally) exist at that endpoint.

How the URI is treated depends on the behaviour of the transport stack that
you're using. Of course if you want to use raw TCP sockets then you'll have
to do a lot of work yourself. If you hook into some other, higher-level part
of a stack then your URI should be understood.

> I'm going to try another analogy -
> 
> posit: I wish to send a written instruction to my bank, to do 
> something with my account.  I write this on a piece of paper, 
> giving the bank sortcode and the account number. Those 
> unambiguously identify the account.

OK.

> There are various ways I could send this to the bank - post, 
> fax, take it into the branch. None of these affect the 
> content of the paper.  The information on the paper does not 
> tell me the postal address, fax number or branch location - 
> but that's ok, because the bank told me how to address things 
> to it by any of those means. And each means has its own 
> address format.

And when you choose one of these, you must pick a binding, and at that point
you must pick a concrete form of the address. For example, the fax binding
actually does have a different address from the postal binding since they
have different URI forms.

> But note the addressing information is the same for any other 
> account I have there. If I fax them the document, they know 
> which account to change because of the identification on the 
> paper - which wasn't used in the routing at all.

Not true. The addressing information is binding dependent. It may be the
case that your bank uses the same identifier (in your sense) for each
addressing scheme, but then again it may not.

> the addresses can also use standard means of representation 
> (i.e. not specific to banks) - so
> fax: 020 8345 3384 is equivalent to a url for an endpoint.

No, it's equivalent to one of your addresses surely?

> and the sort code and account number can be used by anyone 
> who holds it to see that two references are references to the 
> same account.(however the comparer might send a message to do 
> something to, or received a message about the account)

This is a false economy. In order to see that two different-looking remote
references actually refer to the same thing you can't just look at the last
few characters and guess.

> but in your scheme, the sortcode, account number and the 
> address are all run together. In this case there would be 
> three different URLs, each containing a different address.

No, there would be one URI for each possible form of access to that
endpoint. E.g., from RFC 2396:

http://www.bank.com/10-11-12/12345678
mailto:robot@bank.com?subject=sort:10-11-12,acc:12345678

Or something similar.

> But they aren't the regular url's for the carriers -
>   fax: 020 8345 3384/60-05-29/24568754
> is not well-formed for its scheme

Why? If you define a standard URI for fax transmissions and adhere to it,
then it would be well formed.

> it would have to be something like
>    bank:fax:02083453384/60-05-29:24568754
> and define the rules for whats what, so the sender can work 
> out what to dial and what to ignore when making the fax call

Erm, no. You are implying semantics at the sender's end of this URI. All the
sender knows is that there is probably an entity that it wants to talk to at
the end of the "pointer." The "bank:" in the above is not relevant since it
is application specific and has nothing to do with transport.

> comparing identifications requires the comparison to be 
> against the full set of dual-purpose urls (and gets very 
> badly broken if the bank changes their fax number); or one of 
> the set is nominated for identification purposes, even if 
> different means are used for sending; or all the url's have 
> consistent syntax so the identification information can be 
> extracted. But the last two of those are actually our scheme obscured.

As I said, comparing the value of a two pointers in a distributed system
does not necessarily tell you whether the thign they both reference is the
same.

> bunging everything in dual-purpose UR*s is a mistake. It is 
> precisely confounding "payload" and "delivery".

I fundamentally disagree here because there are two issues being
unfortunately mixed. It just so happens that since things "live" at unique
addresses (the thing that transports deal with) we might as well use that
unique ID without bothering to cobble together our own just for the sake of
it.

Now as for the transport issues being mixed with payload. Mostly things like
target and reply addresses need to be left to the transport. Sometimes IDs
need to get propagated around, and sometimes the places things get
transported to needs to change. Isn't it useful if I can just give the
transport layer what I perceive as an ID (i.e. go there!) and the transport
layer automatically knows what to do since to the transport the ID is
actually a valid endpoint URI.

Seems neat enough to me.

Jim