[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] Re: [bt-spec] URIs and address-as-X (M AJOR)
> > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC