Subject: RE: [Simple] Open issues and changes to prescaps

From: [email-masked]
Date: Tue, 4 May 2004 16:20:53 +0300

Hi,

Below it is proposed that <type> element would be removed from <voice>,
<video>, <application>, <data>, <control>, and <text> elements. As I
browsed through previous emails on this subject I remembered that it has
been suggested that element like <type> (for example <subtype>) could be
useful with <voice>, <video>, <application>, <data>, <control>, <text>
elements. Reason for not using <type> is that is contains information
what can be received in SIP requests and not the streaming media type.
If you think it would be useful to have this or if you think this is bad
thing to have please send comments (preferably within next two days as
new version will be out soon).   

- Mikko  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext [email-masked]
> Sent: Tuesday, April 27, 2004 9:26 AM
> To: [email-masked]
> Subject: RE: [Simple] Open issues and changes to prescaps
> 
> 
> > Hi,
> > 
> > Here is a list of open issues and changes that were agreed in Seoul.

> > If I have missed something please let me know. We should get 
> > consensus on open issue(s) quite soon (hopefully within a week or 
> > so).
> > 
> > Open issues:
> > - Extension mechanism. Currently draft contains two extension 
> > mechanisms. One is XML extension mechanism (mechanism 1) and the 
> > other one is based on XML elements token, string, boolean, and 
> > numeric which allow usage of other tags that are not specified in 
> > callee caps (mechanism 2). We have had some list discussion about 
> > this topic and below I try summarize discussion so far: Arguments 
> > for having mechanism 2 have been that for some applications it might

> > be easier to use. Using this mechanism applications would not need 
> > to define new XML namespaces for every new attribute. For 
> > applications which can 'dynamically' use or come up with new 
> > attributes this mechanism would be good. Argument for having only 
> > XML extension mechanism have been that for having two extension
> > mechanisms may lead to some inconsistencies like same 
> > extension attribute could be applied using both mechanisms 
> > simultaneously. It has also being argued that applications 
> > cannot or should not use new attributes unless their 
> > semantics has been clearly defined. Also mechanism 1 may have 
> > some problems with presence authorization and filtering. 
> 
> So far I have received no comments about this. If somebody
> wants to keep the XML element (token, string, boolean, 
> numeric) based extension mechanism please indicate that 
> promptly. Otherwise it will be removed from the next revision. 
> 
> - Mikko
> 
> > Personally I think we can live with only XML extension mechanism 
> > (mechanism 1). For applications that would like to use extension tag

> > this means defining a new XML schema. However, this may be a good 
> > thing because applications must in any case define some kind of 
> > semantics for new attributes and as far as I know this doesn't need 
> > to involve any
> standardization.
> > 
> > Changes:
> > - remove <type> elements from all media type tags (voice, video, 
> > application, data, control, text) and change these to be of boolean 
> > type
> > 
> > - Add separate <type> element into XML schema
> > 
> > - Remove text from section 5 which talks about adding Accept-Contact

> > header based on prescaps into SIP requests.
> > 
> > 
> > - 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
> 

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

---

From: [email-masked]
Date: Tue, 4 May 2004 16:20:53 +0300

Hi,

- Mikko