PRF2: Any "scheme"
is in fact going to have to repeat some information between the
enrol and the application response. The distinguishing characteristics of
the service are going to be stated in the application response (including
things like price etc), and any human-parsable field used in the
inferior-name is going to be some reference to that. but since its a
reference, it doesn't really have to be understandable. and there already
is a unique
identifier.
<ml>The identifier has to be
understandable (or at least a component of it does). Simply having
"foobar:1234abcd" doesn't convey enough information to a decider that "foobar"
is actually "Acme taxi". So as long as the "handle" the decider uses has this
parse-ability it doesn't matter about the name IMO.</ml>
<prf> the
need is to associate some application work (at the service) with the
identifier that is used on the PREPARE_INFERIORS etc. The
identifier itself doesn't have to be understandable, just the
terminator application has to know which identifier will affect which bit
of work. If the (opaque) identifier is present as a field of or
associated with the application response, the terminator can just remember the
identifier as having that assoication.
So
<taxi:reservation>
<taxi:provider>acme</taxi:provider>
<taxi:location>13 Railway Cuttings, East
Cheam</taxi:location>
<taxi:pickuptime>20020415T2100Z</taxi:pickuptime>
<taxi:confirmationcode
type="btp"><btp:identifier>urn:foobar:1234abcd</btp:identifier></taxi:confirmationcode>
<taxi:resrervation>
would tell the
terminator application all it needs to
know.
That one doesn't use
the name at all. The name allows a sort of indirection, and one might
have
<taxi:confirmationcode
type="btpname">acme-345624</taxi:confirmationcode>
and appearing in the
INFERIOR_STATUSES
<btp:status-item>
<btp:inferior-
identifier>urn:foobar:abcd1234</btp:inferior-handle>
<btp:status>prepared</btp:status>
<btp:qualifiers>
<btpq:inferior-name>
<btpq:inferior-name>acme-345624</btpq:inferior-name>
</btpq:inferior-name>
</btp:qualifiers>
</btp:status-item>
</prf>
The application message could carry a
field that was known to be in the ENROL
- this could be the "inferior name", but the identifier would probably be more use, precisely because it is known to
be unambiguous. (In fact, I'm not so
sure the inferior name is any use on thinking this through). This is clearly an application [protocol]
responsibility - the identifier becomes a parameter on their
message.
<ml>I think the confusion could be my fault if
I was using name instead of identifier in text. Meant "whatever handle the
decider
has to
control termination", which is the indentifier.</ml>
<prf>
Yes -
INFERIOR_STATUSES presents both the application(serivce)-chosen name
(if there was one) and the btp-chosen
identifier. PREPARE_INFERIORS etc use only the identifier.
</prf>
Peter