[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [bt-spec] Proposal to resolve URI issue
Can we consider this as an alternative proposal to the URI/identity/address issue? We all seem to agree that we should use URIs across the board, i.e., at addressing and identification level (which I'll refer to as payload-id for now)? The difference seems to be between whether or not the payload-id can also be used as an address endpoint. I believe we can solve this problem by putting structure on the BTP URIs. So, if we assume that everything is a URI then we are free to define these in our own format. Let's say that we assign URIs of type A to mean "I can be used as an address and an identifier" and URIs of type B to mean "I can only be used as an address". Now, we then say that all payloads that require what you would consider to be identifiers and addresses contain URIs for identification and optional URIs for addressing. If the URI a sender uses for payload-id is of type A then no other information need appear in the payload. However, if it is of type B then additional information must appear in the payload. In this way, an application that runs in an environment that knows payload-ids can always unambiguously refer to the end-point service can avoid sending additional information. Other application environments can suitably enhance the payload. Mark. ---------------------------------------------- Dr. Mark Little (mark_little@hp.com) Transactions Architect, HP Arjuna Labs 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