Subject: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Oct 2003 10:37:29 -0500

I see that this revision has tried to align the format of the new 
elements with the other elements in PIDF and RPIDS. Stylistically that 
is good.

But, in the process, something important has been lost. In 
draft-ietf-sip-callee-caps-01 there is the possibility of using both 
base-tags defined explicitly in that document, and other-tags. But 
prescaps only represents the base-tags. I think it is important to 
provide a representation for those as well.

Additionally, the xml representations of the values for base-tags does 
not cover the range of possibilities defined in callee-caps.

In spite of this (or perhaps because of it) there is a nice simplicity 
to the elements now defined in the document.

To fix the limitations, I suggest that one other element be defined: 
<other-tag>. Unlike the base tags where we can bake in the particular 
value representation that is permitted, for <other-tag> we can't know 
which specific value representation is appropriate, and so must support 
all the possibilities. I can see a few ways to do this:

1) use what was proposed in draft-lonnfors-simple-prescaps-ext-01.

    pros: we already have a proposal for it
    cons: it has a bug - can't distinguish between token
          and string values; its kind of wordy

2) use the literal string representation used in contact headers
    in draft-ietf-sip-callee-caps-01.

    pros: the mapping is straightforward; it covers all cases;
          easy to use the same matching algorithm with both
          presence data and registration data

    cons: it isn't very user friendly if ever presented directly
          to a user; it isn't a very convenient representation
          for code that doesn't need to implement the matching alg.

3) convert the value to rfc 2533 format, and embed that in the element.

    pros: the mapping is well defined and covers all the cases;
          convenient for someone implementing the matching alg
          by literally using 2533.
    cons: truly an arcane representation; very inconvenient for
          anyone not implementing 2533 literally; doesn't lend
          itself to representing each "other-tag" and value
          separately.

I conclude that (2) is probably the best overall. (Other opinions welcome.)

The following is the example from prescaps, extended in this way:

    <?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:ietf:params:xml:ns:pidf"
    xmlns:ext="urn:ietf:params:xml:ns:simple-prescaps-ext"
    entity="pres:[email-masked]">

     <tuple id="joi9877866786ua9">
    	<status>
    		<basic>open</basic>
    		<ext:prescaps>
    			<ext:video>true</ext:video>
    			<ext:audio>true</ext:audio>
    			<ext:mobile>true</ext:mobile>
    			<ext:methods>INVITE,MESSAGE,
    			ACK,BYE,CANCEL</ext:methods>
                         <ext:other-tag sip.priority>
                            #=5,!#<=10</ext:other-tag>
                         <ext:other-tag language>
                            !en</ext:other-tag>
                         <ext:other-tag [email-masked]>
                            !red,blue</ext:other-tag>
                         <ext:other-tag [email-masked]>
                            TRUE</ext:other-tag>
    		</ext:prescaps>
    	</status>
    	<contact>sip:[email-masked]</contact>
       </tuple>
    </presence>

This is equivalent to the following contact:

    Contact: sip:[email-masked];
             video;audio;mobile;
             methods="INVITE,MESSAGE,ACK,BYE,CANCEL";
             +sip.priority="#=5,!#<=10"
             +language="!en";
             [email-masked]="!red,blue";
             [email-masked];

or equivalently:

    Contact: sip:[email-masked];
             video;audio;mobile;
             methods="INVITE,MESSAGE,ACK,BYE,CANCEL";
             priority="#=5,!#<=10";
             language="!en"
             [email-masked]="!red,blue";
             [email-masked]

Note that not only does this address other tags, it also addresses 
values for base-tags that are more complex than the simple 
representation can handle.

	Paul

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple