Re: [bt-spec] RE: Proposal to resolve URI issue

[Alastair Green <alastair.green@choreology.com>]

Mark,

Mark Little wrote:

> > So, what are the cases when one wants to consider an identifier as an
> > address too?
>
> When I want to cut down on the amount of information I am sending around the
> network and I know that my identifier uniquely identifies an end-point as
> well as a transaction. Simple as that.

I fear it's a small tail wagging a fairly sizeable dog.

The problems I suspect with this proposed scheme are that it assumes

a) that all addresses for all protocol stacks are URLs
b) that all URLs have space for user data
c) that the user data must be everted via a shim protocol between BTP and the
real carrier
d) that we need to create URI schemes for BTP which are not necessary otherwise

My objections lessen enormously if I have misunderstood, and you are not
proposing to drop "target-additional-information". Can you clarify this point?

Alastair

>
> > -Identifier is not reachable (is not an address), is a URN
> > -Address is reachable (can be located), used for end-points, is a URL
> >
> > Both identifier and address are URIs. One is locatable and the other is
> not.
>
> But if the identifier is a URI that can be interpreted as a communication
> end-point as well (used not just for uniqueness) why send both?
>
> >
> > Also, the same question that Peter asked.
> >
> > >Is the determination that a particular URI in a payload-id is type A or
> > type
> > C (i.e. whether or not it can be used for addressing) on the basis of the
> > "application environment", or on the basis of some part of the URI itself
> ?
>
> See previous answers.
>
> >
> > >Does "putting structure on the BTP URIs" mean defining one or several BTP
> > URI schemes ? [perhaps best clarified by example - what URI scheme(s)
> would
> > you expect for payload-id and "optional URIs for addressing" where the
> > binding was the soap-http-1 that we have in the spec, when used in the
> > "common", interoperable way? )
> >
> > BTP URI schemes seems like a bad idea. We already have elements which
> define
> > the context in which these URIs are used. e.g. The value of element
> > <x-identifier> should not be used to locate x. The value of element
> > <y-address> should not be used to uniquely identify y.
> >
> > Am I missing something here?
>
> See previous answers.
>
> Mark.
>
> ----------------------------------------------
> Dr. Mark Little (mark_little@hp.com)
> Transactions Architect, HP Arjuna Labs
> Phone +44 191 2606216
> Fax   +44 191 2606250
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard