IPDR Protocol Working Group H2'01 Work Plan

The following key work items are planned deliverables from the Protocol Working Group for the next half of this year.

Formalize mechanism to extend standard “base services”
Produce recommendations on managing a common “data dictionary”
Refine alternative compact / Binary specification and any dependencies on Service Definitions
Develop reference compact encoding implementation

Extension of Base Services

There have been a number of inquiries regarding how vendors can create extensions to IPDR service definitions to reflect parameters specific to a given implementation of a service. The current NDM-U 2.6 documentation does not formally address this.

Two basic approaches to extensions are:

Create a new definition which may borrow attribute definitions from existing services, but which derives directly from the base IPDRDoc. (Copy/Paste extension)
Create a new definition which incorporates an existing service by reference (i.e. XML include), only the extensions are enumerated in the new service definition. (Inheritance extension)

We should agree upon one of these and provide guidelines and examples.

Managing Service Definitions (Data Dictionary)

Versioning

Our experience over the past year and a half has shown that individual service definitions themselves are evolving over time. A versioning model for service specifications should be put in place.

One possible technique would be to follow the example used by the W3C in managing their formal specifications (e.g. the XML 1.0 specification). They use naming conventions as follows:

This allows references to be made either to the latest document (which may change over time) or a specific snapshot of a document, by identifying the specific version.

Service Definition Tools

The definition of a reference schema loader API should be considered. This would allow information to be easily extracted from a service specification. This would allow a richer interactive experience for users operating in an IPDR world. In particular they could browse service specifications when configuring tools to consume or produce IPDRs and have a better context for chosing the service attributes of interest.

Refine Compact Specification and Service Definition Dependencies

Define format for encoding usage information based on existing IPDR Service Definition and consistent with information content in existing XML based IPDRDoc.

Define additional service definition annotation in order to assign object identifiers to each attribute

Address any attributes which currently utilize XML attributes in their tags (e.g. <serviceCounter units="packets">). A fixed default for these tag attributes should be defined, or the service definiton should be explicit in units (or other tag attributes) and eliminate this field.

Ensure that the appropriate type mapping from XML Data types to IDL types is in place (should be trivial, verify)

Compact Encoding Development Plan

Note: Unless stated otherwise, CDR in this context will refer to the CORBA's Common Data Representation encoding and does not mean Call Detail Record.

Provide reference implementation (opensource) for basic CDR encoding and decoding (Java and C++)
Provide reference implementation for object id encoding and decoding (Java and C++)
Provide recordDescriptor encode and decode API (Java and C++)
Provide ipdrRecordData encode and decode API

must determine the input model for this API. Does the API simply expose a means to build up a octet string, based on multiple calls to encode each attribute, or is do we define an input structure which contains the attributes in some intermediate format (e.g. Narus IpdrAV from their contributed XML API)

Provide overall ipdrDoc encode and decode API which constructs from the building blocks identified above: CDR encoding, objectId, recordDescriptor, ipdrRecordData.