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

[Mark Little <mark_little@hp.com>]

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

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