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)


[Forgot to CC this to the list at the time, sorry]

Peter:

[snip]
> what an unconstrained URI will give you.

That's just the point. The passport number in the abstract cannot locate
you, but put it into a concrete (i.e. constrained) situation and it starts
working.

> 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.

In that case, they correlate it with the guy with the beard trying to get
into a country - very concrete.

> 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.

Yes, and I think the syntax and semantics of a URI is dependent on the
binding used. I know the syntax and sematics of URLs for example and
SOAP-over-HTTP will be a popular binding.

> If it is one Identifier and it carries the addressing
> information, then we limit the functionality of BTP

I'm not sure I understand this.

> If there are mulitple Identifiers, each carrying addressing
> information, then identifier matching becomes horrid

There will be mulitple identifiers, some of which may appear more than once
in a given system (i.e. we both have a handle on the same transaction), some
of which may not. I don't see this as a major issue. This scheme does have
the advantage of centralising all the information I need to talk to an
entity. Now I agree that at the entity's side, then the logic supporting
that entity might have to work hard (e.g. by separating address and
identifier in some protocol-specific way), but that's not my problem (unless
I am building that logic, of course ;-)

> If the Identifier identifies, and the addresses carry
> addressing information, things are generally simpler.

Again, why? I now have to look at two different pieces of information just
to resolve to the same entity. This same addressing scheme seems to work
quite well (!) for the post office. Their postal staff don't get given a bag
with "street name" on it containing letters with "house number" stamped on
the front (which of course is a valid approach), instead each letter is
effectively given a URI which identifies unambiguously the endpoint to which
that letter should be sent. Why? Simply because it's easier that way, errors
are quicker to spot and it is an approach that people feel comfortable with.

Bother: proof (!) by analogy is such an unsatifactory method, even if it was
a nice analogy :-)

Jim


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC