Subject: RE: [Simple] WGLC: prescaps

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
> 
> 
> [email-masked] wrote:
> 
> > 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
> > 
> > 
> >>-----Original Message-----
> >>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:
> >>
> >>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
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
> 

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 19 May 2004 14:25:23 +0300

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.

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.

> think that this change makes sense I can do it.

On this one I would like to hear other opinions. My opinion is that we 
are doing a protocol that should be debugged by humans. An automata can 
read anything is programmed to read, but I feel that we humans 
understand bettter "supported" than "negated".

> more readable I can add maxOccurs="1" attributes.

No need then. I missed the default value is 1.

Regards,

         Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 19 May 2004 14:25:23 +0300

Regards,

         Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2004 08:56:45 -0400

> values of the integer and human-readable values makes me doubt.

This always gave me some discomfort.

The Priority header has an ordered enumeration of tokens. But in 
callerprefs there was a need to do calculations on them, and the 
feature-tag stuff needed numbers to do that. So Jonathan put in a 
mapping to numbers for that purpose.

The issue is in callerprefs, so any attempt to fix it would need to go 
there first. But I don't think doing that is high on anyone's priority list.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2004 08:56:45 -0400

Paul