Subject: RE: [Simple] WGLC: prescaps

From: [email-masked]
Date: Wed, 19 May 2004 17:59:49 +0300

Can we do something like:

<methods>
   <supported>
	<INVITE/>
	<MESSAGE/>
   <supported>
   <not-supported>
	<PRACK/>
	<UPDATE/>
   <not-supported>
<methods>

/Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext [email-masked]
> Sent: 19.May.2004 16:03
> To: Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Simple] WGLC: prescaps
> 
> 
> Hi,
> 
> > > I think this only applies to <mobility>, <class>, <duplex>, and 
> > > <actor>. These are defines as enumerated types. All the 
> > other ones are 
> > > strings.
> > > 
> > 
> > So you are saying that <event-package>, <methods>, <extension> and 
> > <scheme> do not need that treatment because they are 
> > currently defined 
> > as strings, which is the current situation, but wrong in my opinion.
> > 
> > If you take a look at the Callee capabilities, all these 
> > media fetures 
> > refer to their respective IANA registry for the list of 
> > possible values 
> > that can be used. This, translated into XML, sounds like usage of 
> > tokens. But since we concluded that tokens are not extensible 
> > in XML, we 
> > should user elements are Jonathan proposed. What I disagree 
> > is to allow 
> > a free string rather than "a value out of a collection". I 
> think this 
> > will kill the purpose of the XML structured information.
> 
> With currect schema this would look like:
> 
> <methods>
> 	<method>INVITE</method>
> 	<method>MESSAGE</method>
> </methods>
> 
> If I understand your proposal this would be:
> 
> <methods>
> 	<INVITE/>
> 	<MESSAGE/>
> <methods>
> 
> Advantage in your proposal is that you can use XML parser to validate
> that only valid method names are being used. Also it would 
> allow method
> specific extensions. However, I have at least one issue which 
> should be
> solved before taking this approach. Correctly we have the 'negated'
> attribute which can be used with any <method> element (and <scheme>,
> etc). Now, I think we want that this same attribute is also usable for
> all future methods as well. If we take your approach there should be
> mechanism which would enable/force usage of this attribute also in
> extensions. For time being I am not sure how to do this.
>  
> > Then we have <priority>. I am confused with this one. Callee 
> > Caps defins 
> > it as an integer, but the fact that there is a mapping 
> > between possible 
> > values of the integer and human-readable values makes me doubt.
> 
> I am not sure I get this. Can you provide an example?
>  
> - 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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 20 May 2004 21:19:13 +0300

I also like this proposal.

- Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 20 May 2004 21:19:13 +0300

- Miguel