Subject: [Simple] comments on prescaps

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Feb 2004 10:12:25 -0500

> 3.3 <audio> element
> 
>    The <audio> element indicates that the device supports audio as a
>    streaming media type as defined in [6].
> 
>    The <audio> element can contain 'negated' attribute. This attribute
>    is of boolean type. Value 'true' indicates that device supports audio
>    media type and value 'false' indicates that device does not support
>    audio media type as defined in [6]. Default value for 'negated'
>    attribute is 'false'.
> 
>    <audio> element can contain any number of <type> elements which can
>    be used to describe audio media types supported by the device. If
>    'negated' attribute has value 'true' it is NOT RECOMMENTED to include
>    <type> elements. Media types included in <type> elements MUST start
>    with 'audio/'.

This is inconsistent with callee-caps. In callee-caps, the audio tag 
means that the device supports streaming audio. The type tag, which 
already existed in the registry, indicates MIME types that the SIP 
client supports in SIP messages, NOT in streaming media. Thus, there is 
no callee cap mapping to the <type> element you define above. I would 
suggest that we not include a <type> in order to keep alignment with 
callee-caps.

Same with the others - application, data, video, etc.

> Open issue: Do we need to also allow separate <type> elements outside
>       media tags? This would allow representation of other media type
>       which are not included into this document (like multipart or
>       message).

I suggest alignment with callee caps, and thus, no.

> 3.23 Extension elements
> 
>    This section defines how extension features present in "Indicating
>    User Agent Capabilities in the Session Initiation Protocol (SIP)"
>    [6]	can be used in this extension.

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.

> 5. Generating SIP request based on 'prescaps' extension
> 
>    UA receiving PIDF documents with 'prescaps' extension may wish to
>    generate SIP request which would route to UA having capabilities
>    described by 'prescaps' extension. UA MAY add Accept-Contact: header
>    based on 'prescaps' extension elements. However, as discussed in
>    Section 4 device capabilities described by this extension may not be
>    consistent what UA has indicated in its registration. Due to this
>    request may not route to correct UA.

It should not be necessary, in fact, to do this at all. The contact URI 
should route you to a UA that has these capabilities.

> 9.1  URN sub-namespace registration for
>     'urn:ietf:params:xml:ns:simple-prescaps-ext'
> 
>    URI:
>    urn:ietf:params:xml:ns:simple-prescaps-ext
> 
>    Description:
>    This is the XML namespace for XML elements defined by [[[RFCXXXX]]]
>    to describe communication means extension for CPIM-PIDF presence
>    document format in application/cpim-pidf+xml content type.
> 
>    Registrant Contact:
>    IETF, SIMPLE working group, <[email-masked]>
>    Mikko Lonnfors, <[email-masked]>
> 
>    XML:
> 
>    BEGIN
>    <?xml version="1.0"?>
>    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
>    "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
>    <html xmlns="http://www.w3.org/1999/xhtml
>    <head>
>         <meta http-equiv="content-type"
>         content="text/html;charset=iso-8859-1"/>
>         <title>PIDF User Agent capability extension</title>
>    </head>
>    <body>
>        <h1>Namespace for PIDF User Agent capability extension</h1>
>        <h2>application/cpim-pidf+xml</h2>
>        <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
>     </body>
>     </html>
>    END

The namespace included in <h2> above is a mime type. It should be the 
namespace. This is a bug in pidf that appears to have carried into 
nearly every xml based extension to come out of simple...

Also, we appear to be all over the map in terms of how we are using XML 
namespaces for our extensions. I'll send a separate note on that.

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

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

---

From: [email-masked]
Date: Mon, 1 Mar 2004 02:54:49 +0200

Hi,

Thanks for comments. Inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Jonathan Rosenberg
> Sent: Monday, March 01, 2004 12:12 AM
> To: Simple WG
> Subject: [Simple] comments on prescaps
> 
> 
> > 3.3 <audio> element
> > 

Right, thanks for clarifying this. Based on this it is probably best
idea to remove <type> from <voice>, <video>,  and so on.

> I suggest alignment with callee caps, and thus, no.

There is also one other tag (language) which is not present in callee
caps. To keep the draft's scope consistent it might be reasonable to
remove both of these.
 
There might exist good use cases for both of these (type and language)
so I would like to hear how other people feel about this. 

> it, it could appear there. You dont want to have two valid ways of 

Good point

> As such, I would recommend dropping this entire section.

I am fine with this proposal. It is probably better to have only one
extension mechanism instead of existing two.

> should route you to a UA that has these capabilities.

Are you saying that adding Accept-Contact: doesn't make any difference
in proxies in case there exists multiple UAs for a single AoR? 
But in any case you are right that contact URI should route to correct
UA.

> nearly every xml based extension to come out of simple...

Yes, I also realized this yesterday. Will be fixed.

- Mikko

---

From: [email-masked]
Date: Mon, 1 Mar 2004 02:54:49 +0200

Hi,

 

Good point

- Mikko