BTP - protocol qualification fields

[Peter Furniss <peter.furniss@choreology.com>]

One of Mark Little's comments on the context definition in the models etc.
document was:

> I’d like to see some “vendor” id and “implementation specific data” here,
> so different vendors can piggyback optimisations etc. If a recipient can’t
> understand the id it shouldn’t use the extra data (so the data should
> only be used for optimisations), and also shouldn’t propagate it on
> (c.f., activity service specification).

This seems fairly reasonable. There are some possible dangers - allowing
modification of the messages with this sort of thing can make
interoperability fail if you aren't careful.

It would also seem reasonable to allow this sort of extra stuff to be
carried in the btp messages themselves - allowing consenting implementations
to qualify (but not contradict) the basic semantics of the messages (e.g.
warnngs of heuristic risk).

In general, it would seem plausible that this sort of data might be affected
by application/user options (if an optimisation isn't implemented by all
vendors because it doesn't suit all, there may equally be features that
aren't appropriate to all applications, so the application will want to set
such options).

This leads to the idea that there should be the opportunity for a set of
enhancement/option fields, each with some unambiguous identifier and
essentially arbitrary content. I believe, given that we are encoding in XML,
this should be very easy to do. Especially good, I don't think we need a
special registration authority/scheme - we can just use URIs in the same way
that namespaces do (different URIs).  We perhaps define the basic element,
with a required attribute that is the identification and arbitrary content.
Then both the btp context and the btp messages contain an arbitrary number
of these.

If we have such a mechanism, this may make the process of agreeing BTP
itself easier - it makes it easy to move slightly questionable features to
"standard extensions", with identification and specification defined in the
BTP TC, but not part of the main protocol. This might be the place to put
such things as must-interpose flags, anticipated timescale estimates,
prepare qualifications.

Following is a sketch of the xml of such a context (with ... for incomplete
bits). Apologies for any solecisms in such.  Since the fields are
essentially qualifications to the protocol (c.f. codicils or riders to the
contract), I've called them such here.


<btp:context>
	<btp:coordinatoraddress>
		...
	</btp:coordinatoraddress>
	...
	<btp:protocol_qualifications>
		<btp:qualification btp:qualification_id="http://is.org/extras/1213"
					xmlns:is="http://is.org/schemas/abc">
			<is:a ....
			</is:a>
			<is:b ...
			</is:b>
		</btp:qualification>
		<btp:qualification
btp:qualification_id="http://hp.org/arjuna/btp_extension_2">
			...
		</btp:qualification>
	</btp:protocol_qualifications>
</btp:/context>

As Mark suggests, the spec should include rules that if you don't understand
it, you ignore it (or perhaps we should have a MUST_UNDERSTAND switch for
these). (We could put them in a separate header (in SOAP, at least), but
since these are qualifications of the BTP itself, it makes more sense to put
them inside our stuff)

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX