[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] addresses and identification
> If, in the specification, the only requirement on the name is that is > globally unambiguous, then it is opaque to all but the "owner" - those > endpoints that are or might become the access path for the entity so > identified. However, I can maintain a globally unambiguous name *and* address within the same structure (URI). This is down to the carrier-binding to specify and it's entirely possible that some bindings simply would not support this, but others would. > But, and this was the point of my example above, at the "owner", > it is not necessary that it be opaque - it can contain structure that is > meaningful to the owner - allowing it to contain "local" aliasing > information. But no-one else, especially another implementation sending a > message containing this need understand the structure, let alone the values > extracted from the subelements. And our example of the compounded URI would function in exactly the same way. The sender has a compound URI which contains addressing information for the carrier and the receiver. For example, going back to the good old cgi days: http://mymachine.co.uk/cgi-bin/dboperation?lookup+homepage+1234 where the http://mymachine.co.uk is used at one level to get to the machine, the cgi-bin/dboperation is used to locate the script/program, the lookup is used to invoke a specific method supported by that script/program and homepage+1234 are interpreted in some other manner. If I move the "object" and rename it (say to "oldhomepage") then the URI becomes: http://mynewmachine.co.uk/cgi-bin/dboperation?lookup+oldhomepage+1234 > So, since there are no external contraints > on the name, making a globally unambiguous one that will never need changing > is not that difficult. "never need" is again a subjective statement. As I said earlier, can we really say that is true over all time and all carrier-protocols and all deployment environments? You would say "yes", presumably, and we'd say "no". So, if the protocol can be extended in such a manner as to allow both mechanisms in a way that does not break either (and may well be carrier specific), where is the problem. As long as it remains interoperable I don't see the issue (e.g., if you use your addressing scheme in outgoing messages and we use ours in replies it should still work). > if the name is also used as an address, then there is less flexibility on > its construction - it is constrained by the need to be understood elsewhere, > when it it will be used as an address. *All* of the information in your identifier and address separation should be available in a URI, unless I have misunderstood URI formats. So we don't lose anything. > Those constraints may be more or less > flexibile, but any flexibility must be specified either as part of > addressing scheme, or as part of the btp use of the addressing scheme. Agreed. > ( there is also the possibility that the name is not used as an address but > is unambiguous only within the scope of a particular address (or set of > addresses). But this is the status quo ante, which I thought we agreed we > didn't want, and which required all the disambiguating addresses. ) Mark. ---------------------------------------------- Dr. Mark Little, Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191 2606216 Fax : +44 191 2606250
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC