Subject: [Simple] WGLC: prescaps

From: [email-masked]
Date: Tue, 11 May 2004 09:58:25 +0300

The WG chairs would like to start a Working Group Last Call on the following internet draft as part of the SIMPLE PIDF profile to be submitted to IESG:

http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-01.txt

This WGLC will end on May 24th and completes the set of IDs for the SIMPLE PIDF profile.

Please send your comments to this mailing list and to the authors. 

If you reviewed the draft and found no issues, please indicate so on the mailing list. This will help us evaluate the level of review and group consensus.

Thanks,
Hisham

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

---

From: [email-masked]
Date: Thu, 13 May 2004 12:27:29 +0300

Hi,
> 
> 
> I'm in favor, with one potential issue:
> 
> I believe in mmusic there has recently been discussion of removing 
> "control" (and also "data" I think) as media types. *If* that 
> is going 
> to happen, should they be removed here as well?
> 
> In some sense it doesn't hurt to have them here even if removed from 
> SDP. OTOH, without a place to reference for semantics, we 
> will be left 
> with something that is meaningless.

It seems that in IANA registry:
http://www.iana.org/assignments/media-types/index.html
exists no registrations for "control" and "data". So, one option could
be to drop these for now. If somebody later finds some use for these
media types they can always be added as an extension.

- Mikko 

> I can go either way on this. Anybody clear on how certain 
> this change is 
> for SDP?
> 
> 	Paul
> 
> [email-masked] wrote:
> > The WG chairs would like to start a Working Group Last Call on the 
> > following internet draft as part of the SIMPLE PIDF profile to be 
> > submitted to IESG:
> > 
> > 
> http://www.ietf.org/internet-drafts/draft->
ietf-simple-prescaps-ext-01.
> > txt
> > If you reviewed the draft and found no issues, please 
> indicate so on 
> > the mailing list. This will help us evaluate the level of 
> review and 
> > group consensus.
> > 
> > Thanks,
> > Hisham
> >

---

From: [email-masked]
Date: Thu, 13 May 2004 12:27:29 +0300

Hi,

- Mikko

---

From: [email-masked]
Date: Thu, 13 May 2004 12:40:17 +0300

There has not been a decision yet in mmusic to deprecate those. We can
leave them in for now and remove them if needed (i.e. if they got
deprecated in SDP) as long at this decision happens no later than the
author's 48 hours.

How does that sound to people?

/Hisham

> -----Original Message-----
> From: Lonnfors Mikko (Nokia-NRC/Helsinki) 
> Sent: 13.May.2004 12:27
> To: 'ext Paul Kyzivat'; Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: RE: [Simple] WGLC: prescaps
> 
> 
> Hi,
> > 
> > 
> exists no registrations for "control" and "data". So, one 
> option could be to drop these for now. If somebody later 
> finds some use for these media types they can always be added 
> as an extension.
> 
> - Mikko 
> 
> > > This WGLC will end on May 24th and completes the set of 
> IDs for the 
> > > SIMPLE PIDF profile.
> > >

---

From: [email-masked]
Date: Thu, 13 May 2004 12:40:17 +0300

/Hisham

---

From: [email-masked]
Date: Mon, 17 May 2004 10:44:57 +0300

There is 1 week left for prescaps WGLC and so far we only received one comment. We are now doing great with other WGLCs. Lets keep up the good work here as well.

This will go to IESG along with RPID, CIPID and future-status as the SIMPLE PIDF profile.

Your comments are much appreciated,
Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext [email-masked]
> Sent: 11.May.2004 09:58
> To: [email-masked]
> Subject: [Simple] WGLC: prescaps
> 
> 
> The WG chairs would like to start a Working Group Last Call 
> on the following internet draft as part of the SIMPLE PIDF 
> profile to be submitted to IESG:
> 

Thanks,
Hisham

---

From: [email-masked]
Date: Tue, 18 May 2004 20:15:24 +0300

Hi Miguel,

Thanks for comments:

> Mikko and Jonathan:
> 
> Since the idea of prescaps is to recreate the Callee 
> capabilities in the 
> PIDF, I think Jonathan's advice (as main author of Callee 
> capabilities) 
> will be welcome on some of the following issues:
> 
> - In my opinion prescaps should create a stronger dependency 
> to Callee 
> capabilities. Particularly in the token definition and 
> extensibility. I 
> don't expect that prescaps defines a new IANA registry for, e.g., 
> <class>, <duplex>, <mobility>, <event>, <priority>, <methods>, 
> <extensions>, <schemes>, <actor>. I expect prescaps to import 
> or reuse 
> the same tokens that are registered for Callee capabilities.
> 
> Therefore, I propose that in each of the above mentioned elements 
> description we add a paragraph noting this relation. Something like:
> 
> "Values appropriate for use with this element: token registered with 
> IANA in the 'SIP Media Feature Tag Registration Tree' under the 
> [sip.methods media feature tag]."

This sounds good. Currently draft only contains references to callee
caps where these things are defined. Making this more explicit is a good
idea.  

> Note that not all of them are SIP Media Feature Tag Registration Tree 
> (see methods and extensions in Callee capabilities).
> 
> 
> - If the above is acceptable, then you need to re-write the schema to 
> allow extensibility of those parameters. We commented 
> something similar 
> for RPID and Jonathan provided guidelines in:
> 
> http://www1.ietf.org/mail-archive/working-groups/simple/curren
> t/msg02943.html

I think this only applies to <mobility>, <class>, <duplex>, and <actor>.
These are defines as enumerated types. All the other ones are strings.

> - Namespace. If the proposed usage of the draft falls within the 
> <status> element of the PIDF, then the namespace you defined is not 
> correct. It should be prepended by the "pidf:status", so the 
> namespace 
> should be:
> 
>      urn:ietf:params:xml:ns:pidf:status:prescaps
> 
> Optionally, you can add some discussion of the motivation for this 
> namespace, i.e., indicating that section 4.2.5 of the PIDF 
> requires it.

Yes, I will change the namespace to
urn:ietf:params:xml:ns:pidf:status:prescaps.

> 
> - I found some places where there is a double normative 
> statement, one 
> expressed in the text, the other in the schema. This is a bad idea, 
> since you may only get trouble if you change one, but not the other. 
> Since the schema is mandatory and normative, I would avoid 
> any normative 
> text that is already expressed in the schema. For instance, 
> in section 
> 3.2 you mention:
> 
>     Root element of this extension namespace is <prescaps>.  The root
>     element MUST be always present.  This element MAY contain 
> one or more
>     elements as specified later in this document.

I will trim use of requirements language.

> which is already covered in the schema. So is the following paragraph:
> 
>     <prescaps> element does not have any attributes and it MAY contain
>     other namespace declarations for the extensions used in 
> the presence
>     XML document.

Right, the paragraph you refer to is more or less redundant and I will
remove it.

> 
> - In all the boolean elements you have a "negated" attribute that 
> puzzles me. Its name is really obscure. For instance:
> 
>       <event-package negated="false">presence.winfo</event-package>
> 
> So this is a double negation, and its not clear enough. I 
> would propose 
> to replace the negative logic by a positive logic. Perhaps you are 
> looking for a "supported" attribute rather than "negated". 
> The example 
> would be rewritten as:
> 
>       <event-package supported="true">presence.winfo</event-package>
> 
> The meaning in both examples is the same, but supported is 
> clearer (IMHO).

This might be an issue if you think that these documents are processed
by humans. I am not sure it this matters for automates. But if others
think that this change makes sense I can do it.

> - If you accept my previous comment this one is not relevant anymore, 
> but just in case. In section 3.15.1 the values "true" and "false" for 
> the "negated" attribute are swapped (you see?, I told you in the 
> previous point that is easy to make mistakes).
> 
> - The <is-focus> element should be renamed to <isfocus>, to 
> be aligned 
> with Callee capabilities

ok

> - In the example replace <mobile> with <mobility>
> 
> - Schema definition: I believe all the boolean elements should be 
> present just 0 or 1 times. Therefore I miss a 'maxOccurs="1"' 
> attribute 
> to most of them.

The default value for 'maxoccurs' is 1. Of course if it makes the schema
more readable I can add maxOccurs="1" attributes.

> - Schema definition: the <actor> element allows a repetition of up to 
> "4", which is a weird number. I suspect you intend to allow 
> repetition, 
> one per possible actor value. 

Yes, that was the original idea.

> I don't think this is right, first you 
> don't allow extensibility. Second, I am not sure if this is the best 
> method to indicate repetitions. Perhaps you want to define a 
> token list, 
> something similar to what RPID does with the <sphere> element.

Will be fixed.

- Mikko

> - I have also a number of small editorial comments. I will 
> send Mikko a 
> separate e-mail with them.
> 
> Regards,
> 
>           Miguel
> 
> 
> > There is 1 week left for prescaps WGLC and so far we only 
> received one 
> > comment. We are now doing great with other WGLCs. Lets keep up the 
> > good work here as well.
> > 
> > This will go to IESG along with RPID, CIPID and 
> future-status as the 
> > SIMPLE PIDF profile.
> > 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of 
> >>ext 
> >>http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps
> > 
> > -ext-01.txt
> > 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
>

---

From: [email-masked]
Date: Wed, 19 May 2004 10:15:42 +0300

Hi,

> > >       <event-package 
> negated="false">presence.winfo</event-package>
> > > 
> > >       <event-package 
> supported="true">presence.winfo</event-package>
> > > 
> I think "negated" is that is used in callee caps. 

yes

> But would 
> it make more sense to use ! in the element values instead?

This has been discussed before. Motivation for not to use ! was that
applications don't have to parse ! from element values. Using XML
attributes you can use XML parser to handle all parsing work

- Mikko

---

From: [email-masked]
Date: Wed, 19 May 2004 10:02:29 +0300

> ext [email-masked]
> Sent: 18.May.2004 20:15
> To: Garcia Miguel.An (Nokia-NRC/Helsinki); [email-masked]
> Cc: [email-masked]

I think "negated" is that is used in callee caps. But would it make more sense to use ! in the element values instead?

/Hisham

---

From: [email-masked]
Date: Wed, 19 May 2004 10:15:42 +0300

Hi,

yes

- Mikko

---

From: [email-masked]
Date: Wed, 19 May 2004 15:56:06 +0300

> ext Miguel Garcia
> Sent: 19.May.2004 14:25
> To: Lonnfors Mikko (Nokia-NRC/Helsinki)
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Simple] WGLC: prescaps
> 
> 
> Lonnfors Mikko (Nokia-NRC/Helsinki) wrote:
> 
> >> Miguel wrote
>  >>
> So you are saying that <event-package>, <methods>, <extension> and 
> <scheme> do not need that treatment because they are 
> currently defined 
> as strings, which is the current situation, but wrong in my opinion.
> 
> If you take a look at the Callee capabilities, all these 
> media fetures 
> refer to their respective IANA registry for the list of 
> possible values 
> that can be used. This, translated into XML, sounds like usage of 
> tokens. But since we concluded that tokens are not extensible 
> in XML, we 
> should user elements are Jonathan proposed. What I disagree 
> is to allow 
> a free string rather than "a value out of a collection". I think this 
> will kill the purpose of the XML structured information.

I agree that this should be done with elements, for extensibility purposes.

> >>      <event-package supported="true">presence.winfo</event-package>

Supported is ok with me as well.

/Hisham

---

From: [email-masked]
Date: Wed, 19 May 2004 16:02:37 +0300

Hi,

> > I think this only applies to <mobility>, <class>, <duplex>, and 
> > <actor>. These are defines as enumerated types. All the 
> other ones are 
> > strings.
> > 
> 

With currect schema this would look like:

<methods>
	<method>INVITE</method>
	<method>MESSAGE</method>
</methods>

If I understand your proposal this would be:

<methods>
	<INVITE/>
	<MESSAGE/>
<methods>

Advantage in your proposal is that you can use XML parser to validate
that only valid method names are being used. Also it would allow method
specific extensions. However, I have at least one issue which should be
solved before taking this approach. Correctly we have the 'negated'
attribute which can be used with any <method> element (and <scheme>,
etc). Now, I think we want that this same attribute is also usable for
all future methods as well. If we take your approach there should be
mechanism which would enable/force usage of this attribute also in
extensions. For time being I am not sure how to do this.
 
> Then we have <priority>. I am confused with this one. Callee 
> Caps defins 
> it as an integer, but the fact that there is a mapping 
> between possible 
> values of the integer and human-readable values makes me doubt.

I am not sure I get this. Can you provide an example?
 
- Mikko

---

From: [email-masked]
Date: Wed, 19 May 2004 17:59:49 +0300

Can we do something like:

<methods>
   <supported>
	<INVITE/>
	<MESSAGE/>
   <supported>
   <not-supported>
	<PRACK/>
	<UPDATE/>
   <not-supported>
<methods>

/Hisham

> Sent: 19.May.2004 16:03
> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]

---

From: [email-masked]
Date: Tue, 25 May 2004 18:19:42 +0300

Hi,

> I understand your concern. My preference is (if possible) to
> define the 
> suppported attribute in the "template". I don't know if the schema is 
> valid, but something like this:
> 
> <xs:element name="activity" minOccurs="0">
>             <xs:complexType>
>               <xs:sequence>
>                 <xs:element ref="ts:methods"
>                   minOccurs="1" maxOccurs="1">
>                     <attribute name="supported" type="xs:boolean"/>
>                 </xs:element>
>               </xs:sequence>
>             </xs:complexType>
>           </xs:element>
> 
> And then each method will inherit the attribute (I guess).
> 
> <xs:element name="INVITE" substitutionGroup="ts:methods"/>
> 
> And an example:
> 
> <methods>
>     <INVITE/>
>     <REFER supported="no"/>
> </methods>
> 
> But as I said, I haven't checked if the syntax is legal in XML.

This looks quite nice in a case it actually works. I haven't had time to
test this but I will see if it will work. If not then other option is to
go for solution what Hisham send to the list (separate <supported> and
<notsuported> elements). I wasn't able to find much info about use of
substitutionGroup attribute. If anyone knows good references please let
me know.

> >>Then we have <priority>. I am confused with this one. Callee Caps 
> >>defins it as an integer, but the fact that there is a mapping
> >>between possible 
> Yes. The problem is that callee capabilities defines the 
> sip.priority as 
> a media feature tag whose value is an integer. Therefore, we have a 
> continuous value. However, callee capabilities also maps some values 
> into discrete values, and this sounds more like a token kind 
> of thing. 
> According to callee caps:
> 
>        Each
>        integral value corresponds to one of the possible values of the
>        Priority header field as specified in SIP [1]. The mapping is
>        defined as:
> 
>        non-urgent: Integral value of 10. The device supports 
> non-urgent
>           calls.
> 
>        normal: Integral value of 20. The device supports normal calls.
> 
>        urgent: Integral value of 30. The device supports urgent calls.
> 
>        emergency: Integral value of 40. The device supports 
> calls in the
>           case of an emergency situation.
> 
> 
> I was just saying that it is not clear to me whether this is 
> an integer 
> or a token. Perhaps it should be an integer like callee caps.

I would also think that only reasonable way to represent this is to use
integer values as we in any case need to be able to represent other
values than 10, 20, 30,40. 

- Mikko

> - Miguel