Minutes of CPPA Negotiation
Conference Call
Attendees: Marty Sachs, Neelakantan Kartha, Dale Moberg
This meeting was devoted to discussions of negotiability of elements and attributes. The discussion centered on the latest version of the elements and attributes spreadsheet distributed by Dale today, and around Kartha’s writeup of patterns of negotiability that he distributed June 24.
Marty pointed out that there are several cases of enumerations that have to be dealt with:
- Some enumerations are laid out in the CPP instance documents (e.g. certificates).
- Some enumerations are laid out in the CPPA schema itself.
- Some enumerations may be defined only in the text of the CPPA specification and would have to be put into the NDD schema.
- Some enumerations are not listed in full anywhere (e.g. the W3C forms of encryption algorithm name)
- Some may be defined elsewhere, perhaps as a set of URIs.
It was agreed that all the enumerations have to be explained and put into the NDD. In some cases, especially those that are defined in the CPPA schema, only the items in an enumeration that are acceptable to the party that is preparing the NDD instance document have to be listed in the NDD. An example is the versions of the specification that are acceptable to the party.
Marty pointed out that the CPPA schema itself can be considered as input to the negotiation process. Therefore, enumerations that are defined in full in the CPPA schema don’t necessarily have to be defined in full in the NDD schema. (MWS afterthought: They may have to be defined in the NDD schema so that a parser can validate the NDD instance document. This needs more thought.)
We discussed preference order. Preference order of items should be defined to be consistent with the CPPA specification. If there is no preference order in the enumeration, then (at least for version 1), the negotiation algorithm may pick out any item that both parties are willing to support. We will also need rules to cover the case where, for example, Party 1 allows elements A and B with a preference for A, while Party 2 also allows both A and B but prefers A.
Regarding extensibility, we agreed that extensibility should be provided in the NDD schema. An example is that a party may propose some element in an enumeration that both parties can support but was not included in the NDD specification. Extensions are negotiable. It can be done by indicating what foreign namespaces a party accepts. Dale will review how extensibility is used in the CPPA version-2 specification.
Regarding elements or attributes whose cardinalities include zero (omission), the main negotiable thing is “presence or absence”. However, if it is agreed to include that element or attribute, it is then necessary to negotiate its value (or child elements in the case of an element). PersistDuration is an example. If the two parties agree to include it, they then have to negotiate its value.
For negotiating values, the negotiation depends on the type of value. It could be a range of values, a step size, members of an enumeration, etc. The type information is in the CPPA schema and may not have to be repeated in the NDD or NDD schema.
We discussed transport endpoints. We agreed that they are not really negotiable since any party can define whatever endpoints it chooses. There may be issues of matching endpoint characteristics. One example is the endpoint type. Parties may need to negotiate what endpoint types are used. It was not clear to us how much use will be made of endpoint types other than “all purpose”. For items whose wide use is not certain, it may be better not to design in detail in the first version. Instead, we could include a non-normative note on whatever we understand about each such item and leave it for future versions to consider the need to negotiate it.
We decided not to meet on July 3.
Respectively submitted,
Marty Sachs