Subject: [Sip] Re: Question on 3840 terminology in answermode draft

From: Dean Willis <[email-masked]>
Date: Wed, 28 Feb 2007 16:27:13 -0600

ok, I'm stuck.

Keith's draft PROTO writeup for draft-ietf-sip-answermode-01 says:

> Section 4.1.2 of the document indicates the existence of an  
> "answermode" SIP extension feature tag. First, although the  
> reference given is RFC 3840, this document does not use the  
> terminology of "SIP extension feature tag". Secondly it is assumed  
> that any new feature tag carries some form of IANA registration  
> requirements which do not appear to be made.

in reference to document text, which currently says:

> 4.1.2.  REGISTER Transactions
>
> To indicate that it supports the answer-mode negotiation feature, a  
> UA includes a SIP extension feature tag of:
>
>     extensions="answermode"
>
> in the Contact: header field of its REGISTER requests. This usage  
> of feature tags is described in [7] (Rosenberg, J., Schulzrinne,  
> H., and P. Kyzivat, “Indicating User Agent Capabilities in the  
> Session Initiation Protocol (SIP),” August 2004.).

I'm not exactly sure how to resolve this and need guidance from the  
WG on how it should be documented.

As I understand it, RFC 3840 defines the sip.extensions feature tag  
as follows:

10.15.  Extensions

    Media feature tag name: sip.extensions

    ASN.1 Identifier: 1.3.6.1.8.4.15

    Summary of the media feature indicated by this tag: Each value of  
the
       sip.extensions feature tag (note the plurality) is a SIP  
extension
       (each of which is defined by an option-tag registered with IANA)
       that is understood by the UA.  Understood, in this context, means
       that the option tag would be included in a Supported header field
       in a request.

    Values appropriate for use with this feature tag: Token with an
       equality relationship.  Values are taken from the option tags
       table in the IANA SIP parameters registry.

    The feature tag is intended primarily for use in the following
       applications, protocols, services, or negotiation mechanisms:  
This
       feature tag is most useful in a communications application for
       describing the capabilities of a device, such as a phone or PDA.

    Examples of typical use: Choosing to communicate with a phone that
       supports quality of service preconditions instead of one that  
does
       not.

The SIP extensions feature tag refers to extensions by their option  
tags. The answermode draft defines  an options tag:

8.3.  Registration of SIP Option Tags

This document defines the SIP option tag "answermode".

The following row shall be added to the "Option Tags" section of the  
SIP Parameter Registry:
Name	        Description	          Reference
answermode 	This option tag is for    [RFCXXXX]
                 support of the Answer-Mode
                 and Priv-Answer-Mode
                 extensions used to
                 negotiate automatic or
                 manual answering of a
                 request.

Editor Note: [RFCXXXX] should be replaced with the designation of  
this document.

So, what's not clear? Is it "SIP extension feature tag" instead of  
"sip.extensions feature tag"? What's the preferred construction?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 17:55:58 -0500

I would suggest:

"... a UA includes the extensions Contact header field parameter with a 
value that includes answermode:

;extensions="answermode"

-Jonathan R.

Dean Willis wrote:

>> "answermode" SIP extension feature tag. First, although the  reference 
>> given is RFC 3840, this document does not use the  terminology of "SIP 
>> extension feature tag". Secondly it is assumed  that any new feature 
>> tag carries some form of IANA registration  requirements which do not 
>> appear to be made.
> 
> 
> 
>> in the Contact: header field of its REGISTER requests. This usage  of 
>> feature tags is described in [7] (Rosenberg, J., Schulzrinne,  H., and 
>> P. Kyzivat, “Indicating User Agent Capabilities in the  Session 
>> Initiation Protocol (SIP),” August 2004.).
> 
> 
> 
> I'm not exactly sure how to resolve this and need guidance from the  WG 
> on how it should be documented.
> 
> As I understand it, RFC 3840 defines the sip.extensions feature tag  as 
> follows:
> 
> 10.15.  Extensions
> 
>    Summary of the media feature indicated by this tag: Each value of  the
>       sip.extensions feature tag (note the plurality) is a SIP  extension
>       applications, protocols, services, or negotiation mechanisms:  This
>       supports quality of service preconditions instead of one that  does
>       not.
> 
> 
> Editor Note: [RFCXXXX] should be replaced with the designation of  this 
> document.
> 
> 
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Feb 2007 17:06:54 -0600

On Feb 28, 2007, at 4:55 PM, Jonathan Rosenberg wrote:

> I would suggest:
>
> "... a UA includes the extensions Contact header field parameter  
> with a value that includes answermode:
>
> ;extensions="answermode"
>
>

ok, my text now has this as:

> 4.1.1.2.  REGISTER Transactions
>
> UA includes an extensions parameter with a value that includes  
> "answermode":
>
>   ;extensions="answermode"
>

Does that parse OK?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Feb 2007 18:33:52 -0500

Dean,

> value that includes answermode:

The above seems ok to me, though maybe it would be good to show with 
other options and make clear this is is an example:

   ... value that includes answermode. E.g.:

   ;extensions="100rel,answermode,gruu"

The intent is that valid values of the extensions feature tag should be 
values that are permitted to be used in a Supported or Required header. 
RFC 3427 defines the iana registry for those and the rules for extending 
it. You've included the iana considerations to define answermode as a 
new option, so the example should be legal.

	Paul

>>> feature tags is described in [7] (Rosenberg, J., Schulzrinne,  H., 
>>> and P. Kyzivat, “Indicating User Agent Capabilities in the  Session