Subject: [IPTEL] Proposed CPL extension mechanism

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Sep 2000 21:00:41 -0400 (EDT)

Here's my proposal for how to handle CPL extensions.  What do people think?

-- 
Jonathan Lennox
[email-masked]

N CPL Extensions

   Servers MAY support additional CPL features beyond those listed in
   this document. Some of the extensions which have been suggested are a
   more powerful time-switch mechanism, compatible with the recurrence
   rules of the iCal Core Object Specification [1]; a means of querying
   how a call has been authenticated; richer control over H.323
   addressing; and end-system or administrator-specific features.

   CPL extensions are indicated by XML namespaces [2]. Every extension
   MUST have an appropriate XML namespace assigned to it. All XML tags
   and attributes MUST be appropriately qualified so as to place them
   within that namespace.

   Tags or attributes in a CPL script which are in the global namespace
   (i.e., not associated with any namespace) are equivalent to tags and
   attributes in the CPL namespace "http://www.ietf.org/internet-
   drafts/draft-ietf-iptel-cpl-03.txt".

   A CPL server MUST reject any script which contains a reference to a
   namespace which it does not understand. It MUST reject any script
   which contains an extension tag or attribute which is not qualified
   to be in an appropriate namespace.

   A CPL script SHOULD NOT specify any namespaces it does not use. For
   compatibility with non-namespace-aware parsers, a CPL script SHOULD
   NOT specify the base CPL namespace for a script which does not use
   any extensions.

        A syntax such as

        <extension-switch>
          <extension is="http://www.example.com/foo">
             [extended things]
          </extension>
          <otherwise>
             [non-extended things]
          </otherwise>
        </extension-switch>

        was suggested as an alternate way of handling extensions.
        This would allow scripts to be uploaded to a server without
        requiring a script author to somehow determine which
        extensions a server supports. However, experience
        developing other languages, notably Sieve [3], was that
        this added excessive complexity to languages. The
        extension-switch tag could, of course, itself be defined in
        a CPL extension.

        It is unfortunately true that XML DTDs, such as the CPL DTD
        given in appendix A, are not powerful enough to encompass
        namespaces, since the base XML specification (which defines
        DTDs) predates the XML namespace specification. XML schemas
        [4] are a work in progress to define a namespace-aware
        method for validating XML documents, as well as improving
        upon DTDs' expressive power in many other ways.

N.1 Examples of Extensions

   The example in figure 1 shows a hypothetical extension which
   implements distinctive ringing. The XML namespace
   "http://www.example.com/distinctive-ring" specifies a new node named
   ring.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl xmlns="http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-03.txt"
        xmlns:dr="http://www.example.com/distinctive-ring">
     <incoming>
       <address-switch field="origin">
         <address is="sip:[email-masked]">
            <dr:ring ringstyle="warble" />
         </address>
       </address-switch>
     </incoming>
   </cpl>

   Figure 1: Example Script: Hypothetical Distinctive-Ringing Extension

   The example in figure 2 implements a hypothetical new attribute for
   address switches, to allow regular-expression matches. It defines a
   new attribute regex for the standard address node.

   <?xml version="1.0" ?>
   <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">

   <cpl>
     <incoming>
       <address-switch field="origin" subfield="user"
           xmlns:re="http://www.example.com/regex">
         <address re:regex="(.*.smith|.*.jones)">
            <reject status="reject"
                    reason="I don't want to talk to Smiths or Joneses" />
         </address>
       </address-switch>
     </incoming>
   </cpl>

   Figure 2: Example Script: Hypothetical Regular-Expression Extension

Bibliography

   [1] F. Dawson and D. Stenerson, "Internet calendaring and scheduling
   core object specification (icalendar)," Request for Comments 2445,
   Internet Engineering Task Force, Nov. 1998.

   [2] T. Bray, D. Hollander, and A. Layman, "Namespaces in XML," W3C
   Recommendation REC-xml-names-19900114, World Wide Web Consortium
   (W3C), Jan. 1999.  Available at http://www.w3.org/TR/REC-xml-names/.

   [3] T. Showalter, "Sieve: A mail filtering language," Internet Draft,
   Internet Engineering Task Force, May 2000.  Work in progress.

   [4] D. C. Fallside, "XML schema part 0: Primer," Working Draft WD-
   xmlschema-0-20000225, World Wide Web Consortium (W3C), Feb. 2000.
   Available at http://www.w3.org/TR/xmlschema-0/.

Lennox/Schulzrinne                                            [Page 3]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2000 01:34:56 -0400

This looks fine. I'll buy your arguments on the conditional execution stuff
based on support for extensions; I think KISS is very important and it
clearly simplifies things not to try to do that.

As for the actual extension mechanism, this looks fine. I am still annoyed
about the incompatibility of namespaces and DTDs, but thats a much bigger
problem for someone else to solve. Clearly namespaces are the right way to
handle extensions.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Thursday, September 14, 2000 9:01 PM
> To: [email-masked]
> Subject: [IPTEL] Proposed CPL extension mechanism
> 
> 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel