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

[Mark Little <mark_little@hp.com>]

> but there are still terminology problems, which mean we aren't
understanding
> each other's proposals.  (I'm accepting use of some terms for this
> discussion that I don't want to see in the spec, by the way)

Just as a slight aside, there are many things that people may not "want to
see" in the specification, but we have to live by majority rule.

> We are agreed that we should use URI at identification level (the
> payload-id).

That's a good start.

> But I don't agree to using URI's at addressing level. Depending on
details,
> it loses flexibility, imposes complexity or is just a syntactic tweak. But
> I'll hold that as secondary issue for now.
>
> suggestion to clarify terms: on re-reading the first paragraph in rfc 2396
> 1.2, one finds that the URN and URL definitions actually depend on their
> use, not their internal syntax.

Which is precisely what Jim has been saying for the past 2 days. Glad to see
that you are now reading the same page.

> so type A is "is a URL and a URN", type B "is a URL, not a URN"
> there is also type C, "is a URN, not a URL" (can only be uses as an
> identifier)

They are URIs and we impose semantics on how they can (or cannot) be used.
If I try to use type B on my web browser then it won't resolve to anything.

> I don't think that last sentence is what you meant, or your defintion of
> type B was what I've called C. I think you meant:
>
> "If it [the payload-id] is of type C [i.e. is an identifier only ] then
> additional information must appear in the payload [ i.e. at least one of
the
> optional addressing URIs must be present ]"
>
> ( as written it said "if the id used for identification can't be used for
> identification, you must have extra information for addressing")

Incorrect. What it said was "If the URI is for identification only then I
cannot use it for addressing and if I want to contact the entity that the id
represents I have to use additional information."

> Questions:
> are your "optional URIs for addressing" used for identification in any
> circumstances ?  (i.e. are they specified as being URNs for the (same)
> identified thing as payload-id identifies, as well as URLs)

No, they are used purely for addressing.

> are you using "end-point" as Jim was, to mean the specific object (sensu
> latu) that is concerned with a single transaction/inferior, or can it be
> something that has access/responsibility for multiple transactions ?

That's up to the implementation and the interpretation of the URI.

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

The format of the URI determines how it can be used, but what type of URI
actually appears in the payload is down to whatever created the payload in
the first place (roughly speaking).

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

Yes.

Mark.

----------------------------------------------
Dr. Mark Little (mark_little@hp.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2606216
Fax   +44 191 2606250