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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Oct 2003 09:39:38 -0500

Mikko - response inline.

	Paul

> method names should be presented?

No. I mean your xml format doesn't cover:
- negation
- number ranges
- distinction between tokens and strings
   (tokens use case-insensitive compare,
    strings use case-sensitive compare)

> 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

Sounds good to me, but it would be nice to get input from others.

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Oct 2003 09:39:38 -0500

Mikko - response inline.

	Paul

	description="<a string>"
as: