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

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:someone@example.com">
> >>
> >>     <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 g.sip!foo@tags.example.com>
> >>                            !red,blue</ext:other-tag>
> >>                         <ext:other-tag g.sip!bar@tags.example.com>
> >>                            TRUE</ext:other-tag>
> >>    		</ext:prescaps>
> >>    	</status>
> >>    	<contact>sip:someone@examaple.com</contact>
> >>       </tuple>
> >>    </presence>
> >>
> >>This is equivalent to the following contact:
> >>
> >>    Contact: sip:someone@examaple.com;
> >>             video;audio;mobile;
> >>             methods="INVITE,MESSAGE,ACK,BYE,CANCEL";
> >>             +sip.priority="#=5,!#<=10"
> >>             +language="!en";
> >>             +g.sip!foo@tags.example.com="!red,blue";
> >>             +g.sip!bar@tags.example.com;
> >>
> >>or equivalently:
> >>
> >>    Contact: sip:someone@examaple.com;
> >>             video;audio;mobile;
> >>             methods="INVITE,MESSAGE,ACK,BYE,CANCEL";
> >>             priority="#=5,!#<=10";
> >>             language="!en"
> >>             +g.sip!foo@tags.example.com="!red,blue";
> >>             +g.sip!bar@tags.example.com
> >>
> >>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
> >>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
> >>
> > 
> > 
> 
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple