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

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

> > D) if the identification only identifies, and the addresses
> > only locate, the total information shipped is probably less.
> > The addresses would (typically) only be the general endpoint
> > - you could use the same address on every transaction that
> > was run from that process (at least)
>
> OK, so we're basically back where we were, where address+identifier ==
> endpoint (your version), or identifer == endpoint (my version).

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


> In general, there is some token or combination of tokens that get youto an
> endpoint for a given protocol binding. I want that to be a single
> token for
> simplicity, at the expense of shipping round potentially longer
> identifiers.

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.

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.

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.

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.

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.

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)


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.

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

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

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.


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

Peter