OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[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