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

From: [email-masked]
Date: Mon, 3 Nov 2003 11:24:32 +0200

Hi,

Inline

> > 
> >>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.
> > 
> > 
> > Yes, I also think that support for other-tags would be good. During 
> > update I wasn't able to come up with any good solution so I just 
> > dropped it.
> >  
> > 
> >>Additionally, the xml representations of the values for
> base-tags does
> >>not cover the range of possibilities defined in callee-caps.
> > 
> > 
> > Could you be bit more specific. Do you meant that for example for
> > <methods> element XML schema should define the exact structure how 
> > method names should be presented?
> 
> No. I mean your xml format doesn't cover:
> - negation

Correct, this seems to be missing from all string typed attributes. For
boolean types value 'false' can probably be interpreted as negation. 
There are currently two ways that String types are used:
- enumerated types (like class)
- lists (like methods)
For enumeration types negation is easily added into XML syntax. For
lists this is not that trivial. One option is to add negation as ! mark
into value string like: <methods>INVITE, !MESSAGE</methods>. Other
alternative would be to redesign these lists bit differently like:

<methods>
	<method>INVITE</method>
	<method negated="true">MESSAGE>
</methods> 

Second alternative is bit heavier one but I still think it is the better
one. 

> - number ranges

Do you mean for 'priority' tag? If yes I can add it to next version.

> - distinction between tokens and strings
>    (tokens use case-insensitive compare,
>     strings use case-sensitive compare)

For me it is not clear what is the intended usage of comparison
operations is this context. There are at least two cases:
1) XML document level comparison
So, in this case two XML documents (or parts if them) are compared
directly. I am not aware of any XML representation which would allow
these type of operations (case insensitive/sensitive) and also I am not
sure if this is relevant case for us. 
2) Element value comparison
In this case you would extract the values of the XML elements and then
compare the extracted values. Here we can do:
- Specify these things in the draft (no XML representation)
- Add new attribute into XML structure like <xxx token="true"> which can
specify if element contains case sensitive or insensitive data. 
 
> >>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.
> > 
> > 
> > I am not sure if this is that big problem. I would think
> that if client
> > does not know how what particular attribute means it probably won't
> > display it to the user. At least you probably cannot expect
> client to
> > take any actions based on attributes which it doesn't understand.
> 
> You will note that I concluded this was the best alternative in spite 
> of the limitations. I mentioned them in the interest of trying to do 
> an honest evaluation of the alternatives.
> 
> > For me option 2 sounds ok. I will modify draft accordingly if nobody
> > objects.
> 
> Sounds good to me, but it would be nice to get input from others.

Definitely

> If you look closely at the examples I provided, I sidestepped one 
> issue:
> 
> I didn't show how to represent the distinction between strings and 
> tokens. In callee-caps it is done as "token" vs "<this is a
> string>". My
> xml skills aren't very good, and so I don't have a clear idea what 
> would be the best way to render this difference in xml. But I do know 
> that
> rendering:
> 
> 	description="<a string>"
> as:
> 	<ext:description><a string></ext:video>
> 
> is *not* the answer! So I need a suggestion from somebody on how best 
> to do this.

How about:
<ext:other-tag token="true">

Well, now that I spend some time looking your proposal there seems to be
few things which needs to be fixed. I think it is not possible to define
something like:  <ext:other-tag language>
!en</ext:other-tag>

This can be fixed at least in two ways:
1)
<ext:other-tag name="language">!en</ext:other-tag>
2)
<ext:other-tag>
	<name>language</name>
	<value>!en</value>
</ext:other-tag>

I would think second one is better as all the required data can be
retrieved from XML document directly. And if we add all the other things
we end up with:

<ext:other-tag token="true">
	<name>language</name>
	<value negated="true">en</value>
</ext:other-tag>

- Mikko

> 
> > There are also some other open issues with existing draft
> and I will try
> > to compose a separate mail about those before the next meeting.
> > 
> > - Mikko
> > 
> > 
> >>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
> >>
> > 
> > 
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Nov 2003 10:12:41 -0500

> boolean types value 'false' can probably be interpreted as negation. 

Right. Negation is pretty silly for boolean types. So its easy during 
publication to represent !TRUE as FALSE and visa versa.

> Second alternative is bit heavier one but I still think it is the better

The first seems more convenient, to read, to generate, and to process.

Yet another possibility is to keep the simple types simple and use the 
general form for anything more complex.

> Do you mean for 'priority' tag? If yes I can add it to next version.

The priority tag is the only one among the base tags. But of course it 
is also needed for extension tags.

> specify if element contains case sensitive or insensitive data. 

Well, presence publication is analogous to callee-caps. It standardizes 
nothing analogous to callerprefs - no matching algorithm.

Nevertheless, the matching algorithms of callerprefs depend on the 
syntax of the values to determine case sensitive vs case insensitive 
matching. The specification of individual features specifies what kinds 
of values should be used, but the algorithms that process these aren't 
expected to know those definitions.

So it is important to preserve the semantic of whether a particular 
value is to be compared in a case sensitive or case insensitive way.

So I think I agree with your 2nd alternative in (2) above - we need 
something in the xml structure to indicate this. Because tokens are more 
frequently used than strings, it probably makes sense for the default to 
be tokens.

Note that string comparison is different than token comparison in 
another way - commas in strings don't delimit tokens.

One more thing - the way numeric values are handled may enter the 
picture here - they are a third variant. Note that in theory you could 
write something like:

	priority="#=5"
or
	priority="5"

Both are syntactically correct, but the second is a token rather than a 
number, and comparison rules are different. It is probably improper 
usage to mix the two notations for the same parameter value, but a piece 
of code that doesn't know the particular feature should still understand 
how to compare.

("#=5" matches "#=005" and "#<=6", but "5" doesn't match "005").

Maybe could do something like:

      <ext:other-tag sip.methods type=token>
          INVITE,OPTIONS,BYE</ext:other-tag>
      <ext:other-tag sip.priority type=number>
          <=3,=5</ext:other-tag>
      <ext:other-tag sip.description type=string>
          A string, with comma</ext:other-tag>

And then the base types can imply the proper type without having to 
specify it.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Nov 2003 10:12:41 -0500

priority="#=5"
or
	priority="5"

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Nov 2003 22:10:24 -0500

inline.

> The first seems more convenient, to read, to generate, and to process.

I prefer the second, actually. Generally, the reason is that it avoids 
another layer of parsers to be implemented. The callee caps syntax is 
not a pride point in design; its ugliness needed because of the 
constraints of encoding the information as header parameters. XML 
gives you a rich structure. Why bother defining a new syntax for lists 
within an element, when you can use XML natively to do that? 
Similarly, I would do negation with an attribute, rather than include 
the ! within the value. Also, I don't see the need for a methods tag 
AND a method tag. Why not:

<method>INVITE</method>
<method negated="true">MESSAGE</method>

> frequently used than strings, it probably makes sense for the default to 

I would rather propose that you have this as part of the xml element 
itself, and so instead of using "other-tag", instead have "token", 
"string", "range" etc. as elements:

<method>INVITE</method>
<string name="new-string">Foobar</string>
<token name="new-token">ball</token>

>          A string, with comma</ext:other-tag>

I would prefer:

<range name="sip.priority" less-than-or-equal-to="3"/>
<range name="sip.priority" eqeual="5"/>

to the range syntax above.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Nov 2003 22:10:24 -0500

inline.

<method>INVITE</method>

<method>INVITE</method>

I would prefer:

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Nov 2003 15:20:15 -0500

Jonathan Rosenberg wrote:
> constraints of encoding the information as header parameters. XML gives 
> you a rich structure. Why bother defining a new syntax for lists within 
> an element, when you can use XML natively to do that? Similarly, I would 
> do negation with an attribute, rather than include the ! within the 
> value.

I don't feel strongly about this. I agree that the callee caps syntax is 
nothing to be proud of.

But if we don't like that syntax, maybe we should consider simply 
rerendering the 2533 syntax in xml. Perhaps something like:

<AND><string-tag name="sip.desccription">The description</string-tag>
      <boolean-tag name="sip.audio" value="true"/>
      <boolean-tag name="sip.video" value="false"/>
      <OR><token-tag name="sip.methods" value="INVITE"/>
          <token-tag name="sip.methods" value="BYE"/>
      </OR>
      <NOT><token-tag name="sip.class" value="business"/></NOT>
      <OR><numeric-tag name="sip.priority" le="3"/>
          <numeric-tag name="sip.priority" eq="5"/>
      </OR>
</AND>

If we aren't going to do that, then we have to make a decision: do we do 
a syntax rich enough to map to all of 2533, or just to map all of what 
callee-caps can say, or somewhere in between. (I find it hard to pick 
someplace in between.)

 > Also, I don't see the need for a methods tag AND a method tag.
> Why not:
> 
> <method>INVITE</method>

Note that this approach does start to become wordy:

   <method>INVITE</method>
   <method>OPTIONS</method>
   <method>BYE</method>
   <method>UPDATE</method>
   <method>PRACK</method>
   <method>SUBSCRIBE</method>
   <method>NOTIFY</method>
   <method>PUBLISH</method>

rather than:

<method>INVITE,OPTIONS,BYE,UPDATE,PRACK,SUBSCRIBE,NOTIFY,PUBLISH</method>

It also introduces a semantic issue:

   <method>SUBSCRIBE</method>
   <method>NOTIFY</method>

means something quite different semantically in terms of matching 
algorithms than does:

   <method>SUBSCRIBE</method>
   <event>presence</event>

even though syntactically they are very similar. One should result in a 
disjunction and the other in a conjunction. This can be dealt with via 
explanation text - that things corresponding to the same feature tag 
should first be combined into a disjunction, and then the results 
combined into a conjunction. But it would be clearer if the syntax was 
closer to the semantics.

>> Well, presence publication is analogous to callee-caps. It 
>> standardizes nothing analogous to callerprefs - no matching algorithm.
>>
>> matching. The specification of individual features specifies what 
>> kinds of values should be used, but the algorithms that process these 
>> aren't expected to know those definitions.
>>
>> something in the xml structure to indicate this. Because tokens are 
>> more frequently used than strings, it probably makes sense for the 
>> default to be tokens.
> 

Hadn't thought of that. I sort of like the approach.

> <range name="sip.priority" eqeual="5"/>

Are you competing to be champion of verbosity? :-)

There is also negation to deal with here. Could do:

  <range name="sip.priority" less-than-or-equal-to="3" negated=true/>

or

  <range name="sip.priority" gt="3"/>

Namely, just expand the list of relational operations to be complete:

   eq, ne, gt, ge, lt, le

so that negation isn't needed. That also can be used to cover true 
ranges too. E.g. priority="#3:5" could be:

  <range name="sip.priority" ge="3" le="5"/>

It isn't needed for booleans or strings either, so then we only need to 
support negation for tokens.

As it happens, the way negation is defined in callee-caps, negation with 
tokens only makes sense in one very limited case - a single negated 
token. Any other case is degenerate:

- methods="!PRACK,!UPDATE" matches PRACK, UPDATE, and everything else
- methods="!PRACK,INVITE" is same as methods="!PRACK"

Having talked thru all this, I think I am inclined to seek something 
semantically equivalent to the 2533 syntax, while perhaps being more 
concise than a literal transformation.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Nov 2003 15:20:15 -0500

<method>INVITE</method>
   <method>OPTIONS</method>
   <method>BYE</method>
   <method>UPDATE</method>
   <method>PRACK</method>

rather than:

or

   eq, ne, gt, ge, lt, le

	Paul