Subject: RE: [Simple] comments on prescaps - extension elements

From: [email-masked]
Date: Mon, 1 Mar 2004 10:46:39 +0200

Hi,

> 
> > 
> > I know I spoke in favor of this approach in the past, but I never
> > guarantee the self consistency of my argumetns over time, and I now 
> > think that this is not a good idea.
> > 
> > The reasons are:
> > 
> >   1. XML has a mechanism for extensibility; this defines a 
> separate one
> >   2. an element could appear as an extension as you have 
> defined it, 
> > or,
> > if later we do define a matching set of real XML extensions 
> to carry it, 
> > it could appear there. You dont want to have two valid ways 
> of carrying 
> > the data
> >   3. there is an argument to be made that the PA should not 
> generally be 
> > conveying infomraiton it doesnt understand, and that is the 
> case here
> > 
> > As such, I would recommend dropping this entire section.
> 
> I disagree!
> 
> The extension mechanism in callee-caps has means that don't 
> require any 
> registration at all. This is very good for cases when there 
> are features 
> that are very transient. For instance, it is possible to define a 
> feature tag for something like frobitz-sales, or widget-help. 
> And then I 
> can use callerprefs to select an endpoint with the appropriate 
> capability. This allows end users to take advantage of 
> callerprefs for 
> features that matter to them. (Assuming sufficiently smart devices.)
> 
> When using presence, I would like the same to hold true. If it is 
> necessary to define a new xml schema before I can announce a 
> capability 
> for widget-help in my presence then nothing this dynamic can 
> be a feature.

This is definitely a use case where mandating a new XML schema may not
work. I originally thought that making new XML schema would not be that
big deal but if you want this kind of automation then making new XML
schema on the fly may not be possible. 
Only doubt that I have is that can the end point which receives this
information really use it? If this info in generated on the fly then how
the receiving end really knows to look for this?
 
> If there is a problem, it is that the draft forbids use of 
> the extension 
> mechanism when there is specific schema for the same purpose.

Well, I think this restriction is quite useful. I think there should be
a rule that _same_ data cannot be placed into two different places. If
this happens it may be very confusing for applications processing this
information to decide what to do. 
My intension with the restriction you refer to was to forbid use of
extension tags to represent standard tags defined in callee caps. 

-Mikko

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 04:20:02 -0500

> the receiving end really knows to look for this?

This can work as long as it is a community of users with a common 
understanding of what they use. Such a community may have no ability to 
alter the code of the devices, so this is the best they can expect.

> extension tags to represent standard tags defined in callee caps. 

The problem here is that a given tag may initially be represented as an 
extension tag. Later, somebody decides it would be nice to have a custom 
schema for that tag. Once that starts to be implemented there is an 
interop problem between those that have adopted the new schema and those 
still using the old way.

Perhaps we could say something more bounded - things in the sip tree 
cannot be represented using the extension syntax, while things outside 
the sip tree should only be represented via the extension syntax.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 04:20:02 -0500

Thanks,
	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 09:49:58 -0500

Paul Kyzivat wrote:

> 
>>> I disagree!
>>>
>>> The extension mechanism in callee-caps has means that don't require 
>>> any registration at all. This is very good for cases when there are 
>>> features that are very transient. For instance, it is possible to 
>>> define a feature tag for something like frobitz-sales, or 
>>> widget-help. And then I can use callerprefs to select an endpoint 
>>> with the appropriate capability. This allows end users to take 
>>> advantage of callerprefs for features that matter to them. (Assuming 
>>> sufficiently smart devices.)
>>>
>>> capability for widget-help in my presence then nothing this dynamic 
>>> can be a feature.

I'm not sure I agree with this premise. Presence is not callee caps. 
With caller prefs, I can ask to a device that does frobitz-sales, 
without learning whether there exists such a device, or which it is. 
Thus, there are no privacy concerns per se with the use case you describe.

However, if every callee caps attribute automatically goes into pidf, 
then information can be revealed to a presentity. How do we control 
that? How would privacy policies work with the extensibility model you 
desire?

>> schema on the fly may not be possible. Only doubt that I have is that 
>> can the end point which receives this

It seems you need the ability to modify the devices to take advantage of 
the extension mechanism you want. As I pointed out during the meeting, 
the currently documented extension technique works when the callee and 
the watcher understand the extension, but the presence server does not. 
In such a case, it seems to me that the devices necessarily have to be 
able to change, no?

> 
>>> If there is a problem, it is that the draft forbids use of the 
>>> extension mechanism when there is specific schema for the same purpose.
>>
>>
>> information to decide what to do. My intension with the restriction 
>> you refer to was to forbid use of

Exactly - this is one of the arguments for having just one extensibility 
mechanism.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Mar 2004 09:49:58 -0500

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 23:51:41 -0500

> that? How would privacy policies work with the extensibility model you 

I'm not saying that every callee caps attribute automatically goes into 
pidf. I am only asking that there be defined notation so that any callee 
caps attribute *can* go into pidf.

There are two cases for how it actually gets there:

1) the UA that registers with callee caps also publishes presence with 
the same information, or a restricted subset if it likes.

2) the UA registers with callee caps. The PA subscribes to the reg 
package, collects the callee caps info and publishes it.

Either way, configuration controlled by the UA's user then determines 
how much of that ends up in notifications.

>> understanding of what they use. Such a community may have no ability 
>> to alter the code of the devices, so this is the best they can expect.
> 

Is this true with the new authentication model? Content will be filtered 
out if not explicitly authorized to be included. There is now plan to 
move to a semantic model. With that model, will there be a way to 
authorize inclusion of entities that aren't understood by the PA?

If that is true, and if it is possible to create ad hoc xml extensions 
to pidf without the involvement of any standards organization, then 
maybe it would be possible to get the same effect as this part of 
prescaps. I'm not sure these ifs are both true. And that would only work 
with (1) above, not (2).

But including these extensions makes it much easier to use the same 
capability model in registration and pidf.

>> The problem here is that a given tag may initially be represented as 
>> an extension tag. Later, somebody decides it would be nice to have a 
>> custom schema for that tag. Once that starts to be implemented there 
>> is an interop problem between those that have adopted the new schema 
>> and those still using the old way.
> 

In another reply I proposed a solution to this: Require custom scheme 
for feature tags in the sip namespace, but use the extension scheme for 
feature tags in other namespaces. Then the case of something migrating 
will never occur unless it gets a new feature tag name.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 23:51:41 -0500

Paul