Subject: RE: [Simple] WGLC: prescaps

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

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 17 May 2004 16:28:59 +0300

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

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/current/msg02943.html

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

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

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.

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

- 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

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

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

- I have also a number of small editorial comments. I will send Mikko a 
separate e-mail with them.

Regards,

          Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 17 May 2004 16:28:59 +0300

Mikko and Jonathan:

Regards,

          Miguel