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

From: Goix Walter <[email-masked]>
Date: Thu, 16 Jun 2005 21:09:37 +0200

comments inline...

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

As I commented to Paul this issue has been discussed before. One of the
reasons that you need to define new XML schema for new elements is that
doing so you also define the semantic for that element.

[walter]  i have a similar concern than paul regarding this issues. i agree with you on the risk of different vendors using the same value for different meanings if no semantics is defined, but it may strongly limit the evolution of the schema to add new caps while extensions are being defined. Typically, values we've been discussing on need to be registered with iana and have some meaning associated. if some vendor uses some value which is not registered with iana but can possibly be defined in the future then we may end up with interop issues, unless each cap has a well-defined naming convention (e.g. feature tags) that allows for proprietary values. in the latter case, i don't see any true issue in using free values since we will be able to distinguish between proprietary and standard values. this would add a lot more flexibilitity (e.g. for feature tags)

regarding event packages, there names have to be registered with iana anyway so i wouldn't expect proprietary event packages and hence different meanings. we are close to get 'dialog' and probably 'sip-profile' as RFCs so it would be interesting to add them to the draft as soon as they become rfc. The point is that such a solution will freezee the list of such elements at the time the prescaps draft will become rfc, and would typically need subsequent versions for each new extension/evt pkg.

 [snip]

>- How should <notsupported> be interpreted ? does that mean
>that any other value not listed within <notsupported> but
>defined in the namespace is actually supported?

No, all values listed in <notsupported> are explicitly not supported.
Values that are listed may or may not be supported but the presentity
doesn't want you to make decisions based on those.

[walter]  may a watcher interprete a <notsupported> value for a specific method as a dnd? As an example, would <notsupported> MESSAGE mean not "willing" to receive it or not "able"? Is this again only a hint? How should the presentity answer to a MESSAGE in this case, 501 because it is truly not supported, or may it accept it anyway? How to guarantee "message dnd" not to be implemented this way? or on the contrary would you see it as a reasonable way to implement it?

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jun 2005 15:57:21 -0400

> [walter]  may a watcher interprete a <notsupported> value for a specific method as a dnd? As an example, would <notsupported> MESSAGE mean not "willing" to receive it or not "able"? Is this again o…

The semantics here should not be redefined, but rather should only be by 
reference to callee caps RFC 3840.

IMO that means not willing or not able - the watcher can't tell.

	Paul