Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-04.txt

From: [email-masked]
Date: Fri, 03 Jun 2005 15:58:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: User Agent Capability Extension to  Presence 
			  Information Data Format (PIDF)
	Author(s)	: M. Lonnfors, K. Kiss
	Filename	: draft-ietf-simple-prescaps-ext-04.txt
	Pages		: 32
	Date		: 2005-6-3
	
Interoperation of instant messaging and presence systems has been
   defined in the IMPP working group.  The IMPP WG has come up with
   baseline interoperable operations and formats for presence and
   instant messaging systems.  This memo defines an extension  to
   represent RFC3840 capabilities in the Presence Information Document
   Format (PIDF) compliant presence documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-prescaps-ext-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-prescaps-ext-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2005 13:47:34 -0400

I just took a look at this again. I have a few suggestions.

	Thanks for continuing to push this,
	Paul

> 3.2  Service capability document
> 
>    Elements belonging to this document are used to describe
>    characteristics of a service.  All elements defined in this section
>    describe static data about the service.
               ^^^^^^

Why is this described as static data? Capabilities can change for a 
variety of reasons:

- a capability may be enabled or disabled by the user.
   E.g. a phone may potentially have video capabilities,
   but the user may have disabled them because he does not
   want to be seen.

- the resources needed to support the capability may be
   temporarily unavailable. E.g. a softphone may be temporarily
   unavailable for audio because another application on the
   device has taken control of the audio components of the device.

- a capability may be temporarily unavailable because the
   service has the necessary resources committed to other
   calls that it is processing.

I believe all of these to be valid reasons to change the set of 
capabilities that are published.

I suggest that the 2nd sentence of section 3.2 be removed.

> 3.2.11  <class> element
> 
>    The <class> element indicates the setting, business or personal, in
>    which a communications service is used as defined in RFC3840 [6].
> 
>    The <class> element can contain two elements: <supported> and
>    <notsupported>.  All classes that are supported by the service are
>    listed under <supported> element and all classes that are not
>    supported by the service are listed under <notsupported> element.
> 
>    <supported> and <notsupported> elements can contain <business> and
>    <personal> elements followed by any number of optional extension
>    elements from other namespaces.  The semantics of business and
>    personal are defined in RFC3840 [6] as:
> 
>    o  <business>: The service is used for business communications.
> 
>    o  <personal>: The service is used for personal communications.
> 
>    Any value that is register to IANA to SIP Media Feature Tag
>    Registration Tree as sip.class media feature tag can be used as a
>    value of an extension element.  If appropriate value is not
>    registered it SHOULD be registed as defined in RFC3840 [6].

The above confuses me. Suppose another value (e.g. 'charity') were added 
to the sip.class feature tag registration. How does a new element 
<charity> get defined?

Similar comment for 3.2.12, 3.2.14, 3.2.16, 3.2.17, 3.2.19, 3.3.2.

The problem is that someone can go through the iana process for adding a 
new feature tag value and then it can be used in sip callee caps. But to 
use it in a presence document you will need to define an xml element to 
represent it. There will be no mechanism to trace which extension xml 
element goes with a particular new feature tag value. Two people could 
define independent xml extensions for the same value.

This could be solved by making the iana registry for feature tags cross 
reference an xml element definition. But that doesn't seem feasible.

I think I prefer the approach you have taken for schemes and languages.

> 3.2.15.1  <lowerthan> element
> 
>    The <min> element has a single attribute called "maxvalue".  The
          ^^^^^

s/<min>/<lowerthan>/

> 3.3.3  <priority> element

This is essentially the same as 3.2.15. The schema only defines it once, 
but that isn't clear from this description. I think it might be 
sufficient to cross reference 3.2.15 from this section.

> 5.  Examples
...
>          <caps:decapsription>
>            Example service
>          </caps:decapsription>
                   ^^^^^^^^^^^^^
The above seems to be the result of some kind of editing error.

>     <!-- PRIORITY -->
>     <xs:complexType name="prioritytype">
>       <xs:sequence>
>         <xs:element name="supported" type="tns:prioritytypes"
>           minOccurs="0"/>
>         <xs:element name="notsupported" type="tns:prioritytypes"
>           minOccurs="0"/>
>      </xs:sequence>
>     </xs:complexType>

My knowledge of xml is very limited, but I believe to get the equivalent 
to what is in callee caps, supported and unsupported each need 
maxOccurs="unbounded".