[Sip] Question on Accept ABNF

"Christer Holmberg" <christer.holmberg@ericsson.com> Wed, 09 January 2008 19:34 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCggt-0006jQ-4P; Wed, 09 Jan 2008 14:34:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCggr-0006Ys-A3 for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 14:34:17 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCggq-0006Ws-Vn for sip@ietf.org; Wed, 09 Jan 2008 14:34:16 -0500
Received: from mailgw4.ericsson.se ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCggq-0000N2-Cr for sip@ietf.org; Wed, 09 Jan 2008 14:34:16 -0500
Received: from mailgw4.ericsson.se (unknown []) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A6D5D21184; Wed, 9 Jan 2008 20:34:15 +0100 (CET)
X-AuditID: c1b4fb3e-b0ea3bb00000459d-8c-478521b720a2
Received: from esealmw126.eemea.ericsson.se (unknown []) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83E602009A; Wed, 9 Jan 2008 20:34:15 +0100 (CET)
Received: from esealmw113.eemea.ericsson.se ([]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 20:34:15 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 9 Jan 2008 20:34:14 +0100
Message-ID: <CA9998CD4A020D418654FCDEF4E707DFEE0944@esealmw113.eemea.ericsson.se>
Thread-Topic: Question on Accept ABNF
Thread-Index: AchSzBq1jJI0SVz/Ts2YtJ3bh1GVwAAIiICwAAGQ2r4=
References: <CA9998CD4A020D418654FCDEF4E707DF03F7A681@esealmw113.eemea.ericsson.se><4784D875.7080508@cisco.com> <CA9998CD4A020D418654FCDEF4E707DFEE0940@esealmw113.eemea.ericsson.se>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 09 Jan 2008 19:34:15.0381 (UTC) FILETIME=[9E72B850:01C852F6]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: -1.0 (-)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Subject: [Sip] Question on Accept ABNF
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I appologize if the following issue has already been dealt with.
In RFC3261 the ABNF for the Accept header is the following:
Accept              =  "Accept" HCOLON[ accept-range *(COMMA accept-range) ]
accept-range    =  media-range *(SEMI accept-param)
media-range     =  ( "*/*" / ( m-type SLASH "*" )  / ( m-type SLASH m-subtype )) *( SEMI m-parameter )
accept-param   =  ("q" EQUAL qvalue) / generic-param
qvalue               =  ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )
generic-param  =  token [ EQUAL gen-value ]
gen-value         =  token / host / quoted-string
m-parameter     =  m-attribute EQUAL m-value
m-attribute       =  token
m-value            =  token / quoted-string

Now, when I receive: Accept: xxxx/yyyy;myParam=isThis

...how does my parser know whether "myParam" is a m-parameter, or an accept-param?

In RFC2616 (HTTP) it is solved by specifying that the first accept-param MUST be a "q" value, so unless you also have a "q" m-parameter you know that anything that comes before "q" is m-parameter, and the rest (including "q" is accept-param):
accept-params  = ";" "q" "=" qvalue *( accept-extension )

RFC2616 also says:
"Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params."
"Note: Use of the "q" parameter name to separate media type
 parameters from Accept extension parameters is due to historical
 practice. Although this prevents any media type parameter named
 "q" from being used with a media range, such an event is believed
 to be unlikely given the lack of any "q" parameters in the IANA
 media type registry and the rare usage of any media type
 parameters in Accept. Future media types are discouraged from
 registering any parameter named "q"."
Now, RFC3261 DOES say that Accept follows the syntax defined in RFC2616, but then it is confusing that the 3261 Accept ABNF is not identical.

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip