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

From: [email-masked]
Date: Thu, 16 Jun 2005 15:41:25 +0300

Hi,

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

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

Yes, this will be changed.

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

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

I can add more text about this.

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

I haven't actually though about this at all. I have been thinking that
URI value in contact would not be parsed to detect support for specific
capabilities but would only be used by watchers to contact presentity. I
would imagine that values in servcaps would be most relevant for the
watcher in decision making.

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

Yes, we could even do <supported> -> <s> and <notsupported> -> <ns>

- Mikko

>walter

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jun 2005 11:37:02 -0400

> doing so you also define the semantic for that element. 

I'm not so much bothered by the need to define a new schema as I am by 
the lack of any clear way to discover if that has been done. There could 
be a new feature tag value registered in IANA, and you and I could both 
decide we want to use it in prescaps. We could each go ahead and define 
an XML extension to handle it. And they we would not interoperate.

And I'm not *as* concenred with entirely new feature tags as I am with 
new values for existing ones.

	Paul