Subject: RE: [Simple] Re:draft-ietf-simple-prescaps-ext-04.txt

From: Goix Walter <[email-masked]>
Date: Tue, 14 Jun 2005 01:34:22 +0200

A couple of more comments/questions on the issues raised by Paul.

- Representing caps as elements that need to be registered through iana rather than values of elements seems to be a bit restricting, especially with regards to forthcoming extensions, methods, event packages or whatever that we have not yet been thinking about. Updating the schema or defining prescaps extension namespaces just to add support for an extra cap is a quite heavy process. Any other reason that justifies such a design rather than simple strings such as Paul suggested?

- i agree with paul that service caps, as published into a presence doc, may change dynamically based on a number of reasons (SIP UA configuration may be an additional one). This emphasizes the need to include such information into a presence doc since it may vary over time. I also understand a similar doc may be used to statically describe a UA stack, probably with a wider list of caps than the dynamic - user related - subset of servcaps to be published or notified to a watcher.

- How should <notsupported> be interpreted ? does that mean that any other value not listed within <notsupported> but defined in the namespace is actually supported? are both elements implicitely exclusive, i.e. should the presence of <supported> means that any other value, which is specified is the current namespace, is not supported even if the <notsupported> element is not present? If so, it may be worth detail it a bit more in the document.

- how is the list of supported methods in the servcaps related to the 'methods' parameter of the contact URI in the tuple/contact element whenever present? what if both values are not sync, for example after some filtering on a presence server? which information should be considered the most relevant by a watcher?

- 'unsupported' would save 2 chars per element instead of 'notsupported' ;-)

walter

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

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

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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