Subject: Re: [Simple] comments on prescaps

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 03:15:16 -0500

Jonathan,

More comments below.

	Thanks,
	Paul

Jonathan Rosenberg wrote:
>> 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.

This also caught my eye. But after thinking about it I decided it was 
ok. While it is important for the prescaps extensions to be capable of 
representing anything in callee-caps, the converse need not hold true. 
If this is useful information, then why not permit it to be encoded?

This type tag is different from that in the registry. It is talking 
about the streaming media. Because of this, it might be best to use a 
different name. Also, encoding the full type here is redundant, because 
it is encoded in the enclosing tag. So maybe what would be better here 
is a <subtype> tag.

>> 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.

As you noted, we already have it because the feature tag already exists, 
and callee-caps permits use of feature tags defined elsewhere.

As such, it would carry over to prescaps as an extension element. There 
*could* be explicit schema for it, but I doubt that is necessary as long 
as the extension mechanism is present. (I sent a separate reply on that.)

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

---

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

I have other comments on this, but I want to single this one as 
especially important.

	Thanks,
	Paul

Jonathan Rosenberg wrote:
>>
>> 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.

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.

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.

	Paul

---

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

Thanks,
	Paul

I disagree!

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Mar 2004 03:15:16 -0500

Jonathan,

More comments below.

	Thanks,
	Paul