Received-SPF: pass (google.com: domain of abnf-discuss-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) client-ip=2001:1900:3001:11::2c;
Message-ID: <53BAB55A.2090008@alum.mit.edu>
Date: Mon, 07 Jul 2014 10:57:30 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "abnf-discuss@ietf.org" <abnf-discuss@ietf.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/abnf-discuss/AMFq9rAApXwa_NIYK4ElH2-NlyY
Subject: [abnf-discuss] defining "compatible" extensions
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: abnf-discuss-bounces@ietf.org
Sender: "abnf-discuss" <abnf-discuss-bounces@ietf.org>

I've been bothered by something for a long time. Now it has come up 
again in the context of rfc4566bis (mmusic).

The question is how best to define an extensible syntax, and then later 
define corresponding extensions.

I'll give a couple of examples:

RFC4566 defines:

    attribute-fields =    *(%x61 "=" attribute CRLF)
    attribute =           (att-field ":" att-value) / att-field
    att-field =           token
    att-value =           byte-string

It defines an iana registry for attributes, keyed by <att-field> tokens.
Those implementing SDP are required to ignore any attributes they don't 
understand/support.

RFC4566 also defines a number of attributes. It does not provide ABNF 
for them - it defines the syntax informally. That is something I've 
proposed to fix in 4566bis, and is driving this query.

Many new attributes have been defined (in separate RFCs) since the 
publication of RFC4566, using a variety of techniques. A popular one is 
to define new ones as:

    attribute /= new-att
    new-att = "new-att-name:" new-att-value
    new-att-value = some-abnf

To be valid, the definition of <new-att-value> then needs to be 
"compatible" with the definition of <att-value>. But there is no way to 
indicate this formally in the abnf.

SIP approached this differently. It has:

    message-header  =  (Accept
                    /  Accept-Encoding
    ...
                    /  WWW-Authenticate
                    /  extension-header) CRLF

    extension-header  =  header-name HCOLON header-value
    header-name       =  token
    header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)

    Accept            =  "Accept" HCOLON
                       [ accept-range *(COMMA accept-range) ]

RFC6086 gives an example of an extension header defined elsewhere:

    message-header      =/ (Info-Package / Recv-Info) CRLF
    Info-Package        =  "Info-Package" HCOLON Info-package-type
    Recv-Info           =  "Recv-Info" HCOLON [Info-package-list]
    Info-package-list   =  Info-package-type *( COMMA Info-package-type )
    Info-package-type   =  Info-package-name *( SEMI Info-package-param )
    Info-package-name   =  token
    Info-package-param  =  generic-param

Again, the definitions of <Info-Package> and <Recv-Info> must also be 
*compatible* with <extension-header>. But there is nothing in the ABNF 
that says this.

(Note: I had to hunt extensively to find an extension that was defined 
this cleanly. Most of them, even more recent ones, aren't this clean. 
And somehow they slipped by me, who cares about such things, even while 
I was chair of sipcore.)

I don't think that ABNF *must* solve this problem, but I can imagine 
extensions to ABNF that would *help* with this. Or else, recommendations 
of how to approach this.

The key thing is that an extension definition needs to satisfy *two* 
ABNF rules. For instance, above we need that both of the following be true:

    new-att = "new-att-name:" new-att-value
    new-att = (att-field ":" att-value) / att-field

I have brought this issue up previously wrt 4566, and have seen 
conflicting opinions on the best way to deal with this. But this problem 
isn't really unique to RFC4566 or mmusic, or RAI. It is a general issue.

I welcome your thoughts.

	Thanks,
	Paul

_______________________________________________
abnf-discuss mailing list
abnf-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/abnf-discuss