Subject: [protocol]Protocol WG Minutes from Quarterly Meeting June 28th - 29th Date: Wed, 18 Jul 2001 17:09:28 -0700 From: Ken Sarno To: "'protocol@ipdr.metratech.com'" CC: Ken Sarno Protocol Working Group Minutes from the Quarterly Meeting June 28-29th, 2001 Attendees --------- Jeff Meyer HP Ken Sarno NARUS Steve Cotton Cotton Management Consulting Aron Heintz IPDR Mike Ullrich Amdocs David Collins Sprint PCS Kevin Zhang Xacct Bill Holtz NEC America Rick Burch Sprint PCS Bill Green CSG Next Conference Call -------------------- Wednesday July 18th, 2001 @ 1pm EDT/10am PDT Dial-in number (404)774-4106 passcode: 6373 Discussion ---------- Jeff posted a propose work plan for the next 6 months, it can be found at: http://www.ipdr.org/members/protocol/minutes/wg_plan_h201_v1.html Our working group is considering focusing on 4 key areas over the next six months: 1. Formalize a mechanism for extending IPDR service definitions by adding new attributes to existing service definitions. 2. Recommend a formal mechanism for managing the "data dictionary" of all the attributes from each of the service definitions. Formalize how attribute names are produced. Also figure out how we preserve snapshots of versions of service defintions. 3. Refine the compact representation and resolve any dependencies that arise in the existing service definitions (annotate them with OIDs). 4. Develop a reference compact encoding implementation. DAY 1 ----- Formal method for extending IPDR service definitions. Currently, IPDR defines a BASE schema, which contains defintions for elements common to all IPDRDocs, like IPDRDoc, IPDR, IPDRRec, SS, SE, SC, etc. Then, for each service defintion, we include the base schema, and extend it by adding service specific attributes. The question is this... how can vendors extend service defintions to add new attributes? In XML includes can be nested. So if a vendor wants to extend one of the service definitions, they just create their own schema, include the IPDR service defintion, and start adding their own attribute names (qualified by the companies name space, to distinguish them from IPDR defined attributes). It would be nice if we had a tool to automatically generate target fields from an abitrary XML schema for a service, and then use a GUI to draw mappings from an interal representation (mediation company) to the appropriate IPDR attributes. Aron: We need to show how one could extend a service definition. Give an example of nesting include files. Add this to section 4.1.2. How would we extend CORBA CDR encoded documents? Need to discuss this more. So, we agreed that the basic mechanism for extending service defintions would be to create a new schema (.xsd) and include the IPDR service definition that you wish to extend. But what is the naming policy for attributes that have been added by vendors via this extension mechanism? In the CORBA CDR documents, a vendor would use an OID that fell under that vendor's namespace. But how does a vendor make their OID's defintion visible to consumers? Action(Jeff): put in an "optional" URL/URI for service schema defintion into the CORBA CDR header section, that would allow vendors to point consumers at a document that describes the vendor defined attributes. In XML documents, a vendor would create new attributes with names that follow this format: . example: If NARUS added an attribute called movie_Ident to the Video_on_Demand service, in an IPDRDoc it would look like this: Star Trek XXI In XML, uniqueness come's from the vendor's private namespace In CORBA CDR, uniqueness is guarenteed by hierarchical uniqueness of OIDs. Action(Bill): Test to see if IPDRDocs validate if we remove "xsi:" from the "type" attribute of the UE element. Can you extend UE-VOIP-TYPE by including the service defintion and extending the pre-defined UE-VOIP-TYPE element? Action(Bill): Create a sampled extended instance document and test how it works? DAY 2 ----- We reviewed the goals of the compact encoding scheme. They can be found at: http://www.ipdr.org/members/protocol/contribs/binary_encoding.html Then we spent the most of the time talking about OIDs. In particular, there was a lot of disagreement about whether they should have a deeply nested hierarchical structure, or whether they should be relatively flat. Action(Aron): do a short write-up about .gz and compressing in file transfer protocol. That it can be used on top of whatever compact encoding scheme we develop. It's use is optional. How should we name/identify attributes in CORBA CDR encoded documents? Should we use a traditional OID, which is a hierarchical naming scheme? Or should we use a flat (ie. single number or a pair of numbers)? With the hierarchical approach, we'd have a namespace for each service as well as a namespace for base attributes. There were some conflicting concerns here. On one hand, some people were concerned about how we would handle promoting a usage attribute from a service defintion to the base record. We might do this is the attribute was discovered to be useful in many more contexts that just the service in which it was originally intended. Once we promote an attribute to "base" status, we would want to rename it to be in the base record namespace but that would entail changing the service defintion, and renumbering the attribute might break backwards compatibility. This lead us to question why we need a hierarchical structure at all. Perhaps we could do just fine with a flat naming scheme, and then use an optional prefixed vendor ID for attributes that are vendor specific. Further discussion on this was postponed until the next conference call. Action Items. ------------ Owner Opened Closed Action ---------- -------- --------- --------------------------------------------------- Steve C. 03/27/01 Describe situations in which undetected gaps and duplicates caused by transmit failures may occur within the file transfer scenario. All 03/28/01 Discuss encoding alternatives with our senior engineers and relay results to the working group. Jeff 05/02/01 Offer up an open source implementation for CORBA encoding and decoding. Jeff 05/23/01 Put IDL compiler stuff on the website. ???? 06/28/01 Create an example of how one could extend a service definition through including it in a new .xsd, place this example in section 4.1.2 of the NDM-U. Jeff 06/28/01 Put in an "optional" URL/URI for service schema defintion into the CORBA CDR header section, that would allow vendors to point consumers at a document that describes the vendor defined attributes. Bill 06/28/01 Test to see if IPDRDocs validate if we remove "xsi:" from the "type" attribute of the UE element. Bill 06/28/01 Create a sample extended instance document and test how it works. _______________________________________________ Protocol mailing list Protocol@ipdr.metratech.com http://ipdr.metratech.com/mailman/listinfo/protocol