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