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

From: [email-masked]
Date: Wed, 15 Jun 2005 20:16:35 +0300

Hi,

Thanks for comments. Sorry for the delay with this one. 
Inline: 

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

Yes, all the points above are valid. The reason for using 'static' is
that when the text was written the data model ID recommended to use
that. I will remove it from next version as it probably causes more
comfusion that good. 

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

We have been discussion this for ages and we have tried these both
approaches. How the schema is currently written is based on group's
consensus and I won't be doing any changes to these things unless it is
absolute necessary.

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

Will fix

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

Right, will fix

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

Yes, too aggressive replace operation. Will fix

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

Could you elaborate. What kind of use case you have in mind? 
You can specify multiple ranges (use multiple <min>, <max>, etc) inside
a single <supported> tag.

- Mikko 

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

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