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

From: [email-masked]
Date: Fri, 31 Oct 2003 14:45:52 +0200

Hi Paul,

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?

> 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.

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. 

> 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.)

For me option 2 sounds ok. I will modify draft accordingly if nobody
objects.

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