[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] URIs and address-as-X (MAJOR)
> Peter: > > > No, you meant URL. URNs do not "sit within the context of a > > protocol". They are unambiguous names for things. They no > > more tell you where something is than "UK Passport number > > 020011112" tells you where it or its holder is. > > Which can resolve unambiguously in a given situation, e.g. immigration. But the question before an implementation holding one of these is it has got work out where to send the message from that information alone. Keeping the example: Take that as an unambiguous identification for me. How are you going to contact from that alone ? There is no way that identification will tell you where I am, and that is what an unconstrained URI will give you. Of course, if you know they correlate with: email: peter.furniss@choreology.com phone: +44 20 7670 1679 direct: +44 20 7670 1783 mobile: 07951 536168 post: 13 Austin Friars, London EC2N 2JX you've got a variety of binding names and binding addresses you can try. But those are in different fields. > > > The fact remains: URIs can be used as a globally unambiguous naming > > > mechanism, whose form is defined according to the rules of the > > > protocol that the particular URI is bound to, which is more > > > conventional (i.e. accessible > > > to the lay person) and loses nothing in expressiveness over > > the current > > > address+identifier scheme. > > > > I agree it is better than the current (0.9.1) > > address+identifier scheme. > > Good :-) > > > We think it is worse than the proposed 77, 78 > > location-unaware identifier, identification-independent > > address scheme. > > To quote, "To summarise: The "Identifier" will be defined as a URI, and > therefore as globally unambiguous." > > Which is pretty much what Mark and I said. Having decided to go > that way, we > can then simplify a bunch of stuff, as per previous mail exchanges. I think you've only deferred the complexity - somewhere has got to specify the syntax and semantics of those URLs, or define the lookup mechanisms that must be deployed. Doing the former is what makes the address description somewhat complex. If it is one Identifier and it carries the addressing information, then we limit the functionality of BTP If there are mulitple Identifiers, each carrying addressing information, then identifier matching becomes horrid If the Identifier identifies, and the addresses carry addressing information, things are generally simpler. Peter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC