| MMUSIC WG | M. Garcia-Martin |
| Internet-Draft | Ericsson |
| Intended status: Standards Track | S. Veikkolainen |
| Expires: August 31, 2012 | Nokia |
| R. Gilman | |
| March 1, 2012 |
Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)
SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures.
This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=' line), connection data ('c=' line), and titles ('i=' line for each session or media).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
The Session Description Protocol (SDP) [RFC4566] is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP has been extended with a capability negotiation mechanism framework [RFC5939] which allows the endpoints to negotiate capabilities, such as support for Real-time Transport Protocol (RTP) [RFC3550] and Secure Real-time Transport Protocol (SRTP) [RFC3711]. The SDP media capabilities [I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation capabilities to media lines as well.
The capability negotiation is embedded into the widely used SDP offer/answer procedure [RFC3264]. This memo provides the means to negotiate further capabilities than those specified in the SDP capability negotiation mechanism framework [RFC5939] and the SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities]. In particular, this memo provides a mechanism to negotiate bandwidth ('b='), connection data ('c='), and session or media titles ('i=').
Since the three added capabilities are highly unconnected, it is not expected that implementations will support all of them at the same time. Instead, it is expected that applications will choose their needed capability for their specific purpose. Due to this, we are writing the normative part pertaining to each capability in a self-contained section: Section 3.1.1 describes the bandwidth capability extension, Section 3.1.2 describes the connection data capability extension, and Section 3.1.3 describes the title capability extension. Separate option tags are defined for each capability.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
The SDP Capability Negotiation Framework [RFC5939] and the SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] specify attributes for negotiating SDP capabilities. These documents specify new attributes (e.g., 'acap', 'tcap', 'rmcap', 'omcap') for achieving their purpose. In this document we define three new additional capability attributes for SDP lines of the the general form:
for types 'b', 'c', and 'i'. The corresponding capability attributes are respectively defined defined as:
From the sub-rules of attribute ('a=') line in SDP [RFC4566], SDP attributes are of the form:
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
Capability attributes use only the 'att-field:att-value' form.
The new attributes may be referenced in potential configurations ('a=pcfg') or in latent configurations ('a=lcfg'), as productions conforming to the <extension-config-list> as respectively defined in RFC 5939 [RFC5939] and the SDP media capabilities specification [I-D.ietf-mmusic-sdp-media-capabilities].
extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
ext-cap-name = 1*(ALPHA / DIGIT)
; ALPHA and DIGIT defined in RFC 5234
ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234
The optional "+" is used to indicate that the extension is mandatory and MUST be supported in order to use that potential configuration.
The new attributes may also be referenced in actual configurations ('a=acfg') as productions conforming to the <sel-extension-config> defined in [RFC5939].
sel-extension-config = ext-cap-name "=" 1*VCHAR
The specific parameters are defined in the individual description of each capability, below.
The 'bcap', 'ccap', and 'icap' capability attributes can be provided either at the session or media level. According to the SDP Capability Negotiation [RFC5939], each extension capability must specify the implication of making it part of a configuration at the media level.
According to SDP [RFC4566], 'b=', 'c=', and 'i=' lines may appear either at session or media level. In line with this, the 'bcap', 'ccap', and 'icap' capability attributes, when declared at session level, are to be interpreted as-if that attribute was provided with that value at the session level. The 'bcap', 'ccap' and 'icap' capability attributes declared at media level, are to be interpreted as-if that capability attribute was declared at the media level.
For example, extending the example in [I-D.ietf-mmusic-sdp-media-capabilities] with 'icap' and 'bcap' capability attributes, we get the following SDP:
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=bcap:1 CT:200
a=icap:1 Video conference
m=audio 54320 RTP/AVP 0
a=rmcap:1 L16/8000/1
a=rmcap:2 L16/16000/2
a=pcfg:1 m=1|2, pt=1:99,2:98
m=video 66544 RTP/AVP 100
a=rmcap:3,4 H263-1998/90000
a=rtpmap:100 H264/90000
a=pcfg:10 m=3 pt=3:101 b=1 i=1
The above SDP defines one PCMU audio stream and one H.264 video stream. It also defines two RTP-based media capabilities ('rmcap' numbered 1 and 2), using L16 audio at 8 kbps and 16 kbps, respectively, as well as two RTP-based media capabilities for H.263 video ('rmcap' numbered 3 and 4). The RTP-based media capabilities all appear at the media level. The example also contains a single bandwidth capability ('bcap') and a single title capability ('icap'), both defined at session level. According to the definition above, when the capabilities defined in the 'bcap' and 'icap' attributes are referenced from the potential configuration, in the resulting SDP they are to be interpreted as session level attributes (but the RTP-based media capabilities are to be interpreted as media level attributes).
According to RFC 4566 [RFC4566] the bandwidth field denotes the proposed bandwidth to be used by the session or media. In this memo we specify the bandwidth capability attribute which can also appear either at session or media level. The bandwidth field is specified in RFC 4566 [RFC4566] with the following syntax:
where <bwtype> is an alphanumeric modifier giving the meaning of the <bandwidth> figure.
In this document, we define a new capability attribute: the Bandwidth capability attribute 'bcap'. This attribute lists bandwidth as capabilities according to the following definition:
where <bw-cap-num> is a unique integer between 1 and 2^31-1 (both included) user to number the bandwidth capability, and the other elements are as defined for the 'b=' field in SDP [RFC4566].
This format satisfies the general attribute production rules in SDP [RFC4566] according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
att-field =/ "bcap"
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Negotiation of bandwidth per media stream can be useful when negotiating media encoding capabilities with different bandwidths.
The SDP capability negotiation framework [RFC5939] provides for the existence of the 'pcfg' and 'acfg' attributes. The concept is extended by the SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute that conveys latent configurations.
Extensions to the 'pcfg' and 'lcfg' attributes are defined through <extension-config-list>, and extensions to the 'acfg' attribute are defined through the <sel-extension-config> as defined in the SDP Capability Negotiation [RFC5939].
In this document we extend the <extension-config-list> field to be able to convey lists of bandwidth capabilities in latent or potential configurations, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
extension-config-list =/ bandwidth-config-list
bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list)
; BAR defined in RFC 5939
bw-cap-list = bw-cap-num *("," bw-cap-num)
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Each bandwidth capability configuration is a comma-separated list of bandwidth capability attribute numbers where <bw-cap-num> refers to the <bw-cap-num> bandwidth capability numbers defined explicitly earlier in this document, and hence must be between 1 and 2^31-1 (both included). Alternative bandwidth configurations are separated by a vertical bar ("|").
The above syntax is very flexible, allowing referencing to multiple 'b=' lines per configuration, even for the same <bwtype>. While the need for such definitions is not seen, we have not restricted this, as it is not restricted in SDP [RFC4566] either.
The bandwidth parameter to the actual configuration attribute ('a=acfg') is formulated as a <sel-extension-config> with
sel-extension-config =/ sel-bandwidth-config
sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above.
hence
The SDP Capability Negotiation Framework [RFC5939] allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Hereby, we define a new option tag "bcap-v0" that identifies support for the bandwidth capability. The endpoints using the 'bcap' capability attribute SHOULD add the option tag to other existing option tags present in the 'csup' and 'creq' attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939].
According to SDP [RFC4566], the connection data field in SDP contains the connection data, and it has the following syntax:
where <nettype> indicates the network type, <addrtype> indicates the address type, and the <connection-address> is the connection address, which is dependent on the address type.
At the moment, network types already defined include "IN", which indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]), used for describing Asynchronous Transfer Mode (ATM) bearer connections. The Circuit-Switched (CS) descriptions in SDP document [I-D.ietf-mmusic-sdp-cs] adds a "PSTN" network type for expressing a Public Switched Telephone Network (PSTN) circuit switch.
SDP [RFC4566] permits specification of connection data at the session or at the media level. In order to permit negotiation of connection data at the media level, we define the connection data capability attribute ('a=ccap') in the form:
where <conn-cap-num> is a unique ordinal identifier of the connection data capability, and the other elements are as defined in [RFC4566].
This format corresponds to the [RFC4566] attribute production rules according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
att-field =/ "ccap"
att-value =/ conn-cap-num 1*WSP nettype SP addrtype
SP connection-address
conn-cap-num = 1*DIGIT ; 1 to 2^31-1, inclusive
The 'ccap' capability attribute allows for expressing alternative connection address ('c=') lines in SDP as part of the SDP capability negotiation process. The 'ccap' capability attribute is intended to be used only when there is no other mechanism available for negotiating alternative connection address information, such as when the <nettype> is different among the alternative addresses. The 'ccap' attribute MUST NOT be used in situations where an existing mechanism (such as Interactive Connectivity Establishment (ICE) [RFC5245]) can be used to select between different connection addresses.
The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the 'pcfg' and 'acfg' attributes, which can carry one or more potential configurations to be negotiated. The concept is extended by the the Media Capabilities Negotiation [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute that conveys latent configurations.
In this document we define a <connection-config> parameter to be used to specify a connection data capability in a potential or latent configuration attribute. The parameter follows the form of an <extension-config-list>, with
where, according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
extension-config-list =/ conn-config-list
conn-config-list = "c=" conn-cap-list
conn-cap-list = conn-cap-num *(BAR conn-cap-num)
conn-cap-num = 1*DIGIT ; 1 to 2^32-1 inclusive
Each capability configuration alternative contains a single connection data capability attribute number and refers to the conn-cap-num capability number defined explicitly earlier in this document, and hence must be between 1 and 2^31-1 (both included). The connection data capability allows the expression of only a single capability in each alternative, rather than a list of capabilities, since no more than a single connection data field is permitted per media block. Nevertheless, it is still allowed to express alternative potential connection configurations separated by a vertical bar ("|").
The connection data parameter to the actual configuration attribute ('a=acfg') is formulated as a <sel-extension-config> with
sel-extension-config =/ sel-connection-config
sel-connection-config = "c=" conn-cap-num ; as defined above.
hence
The SDP Capability Negotiation Framework [RFC5939] solution allows for capability negotiation extensions to be defined. Associated with each such extension is an option tag that identifies the extension in question. Hereby, we define a new option tag of "ccap-v0" that identifies support for the connection data capability. This option tag SHOULD be added to other existing option tags present in the 'csup' and 'creq' attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939].
SDP [RFC4566] provides for the existence of an information field expressed in the format of the 'i=' line, which can appear either at the session level or at the media level. An 'i=' line that is present at the session level is known as the "session name", and its purpose is to convey a human-readable textual information about the session.
The 'i=' line in SDP can also appear at the media level, in which case it is used to provide human-readable information about the media stream to which it is related, e.g., it may indicate the purpose of the media stream. The 'i=' line is not to be confused with the label attribute ('a=label:', [RFC4574]) which provides a machine-readable tag. It is foreseen that applications declaring capabilities related to different configurations of a media stream may need to provide different identifying information for each of those configurations. That is, a party might offer alternative media configurations for a stream, each of which represents a different presentation of the same or similar information. For example, an audio stream might offer English or Spanish configurations, or a video stream might offer a choice of video source such as speaker camera, group camera, or document viewer. The title capability is needed to inform the answering user in order to select the proper choice, and the label is used to inform the offering machine which choice the answerer has selected. Hence, there is value in defining a mechanism to provide titles of media streams as capabilities.
According to SDP [RFC4566], the session information ('i=') line has the following syntax:
where "text" represents a human-readable text indicating the purpose of the session or media stream.
In this document we define a new capability attribute: the Title capability 'icap'. This attribute lists session or media titles as capabilities, according to the following definition:
where <title-cap-num> is a unique integer between 1 and 2^31-1 (both included) user to number the unique ordinal identifier of the particular title capability and <text> is a human-readable text that indicates the purpose of the session or media stream it is supposed to characterize.
As an example, one might use:
to define a title capability number 1 to identify a particular source of a media stream.
The title capability attribute satisfies the general attribute production rules in SDP [RFC4566] according to the following Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
att-field =/ "icap"
att-value =/ title-cap-num 1*WSP text
; text defined in RFC 4566
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
The SDP Capability Negotiation Framework [RFC5939] provides for the existence of the 'pcfg' and 'acfg' attributes. The concept is extended by the SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities] with an 'lcfg' attribute that conveys latent configurations.
In this document, we define an <title-config-list> parameter to be used to convey title capabilities in a potential or latent configuration. This parameter is defined as an <extension-config-list> with the following associations:
This leads to the following definition for the title capability parameter:
extension-config-list =/ title-config-list
title-config-list = ["+"] "i=" title-cap-list
title-cap-list = title-cap-num *(BAR title-cap-num)
; BAR defined in RFC 5939
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234
Each potential capability configuration contains a single title capability attribute number where 'title-cap-num' is the title capability number defined explicitly earlier in this document, and hence must be between 1 and 2^31-1 (both included). The title capability allows the expression of only a single capability in each alternative, since no more than a single title field is permitted per block. Nevertheless, it is still allowed to express alternative potential title configurations separated by a vertical bar ("|").
An endpoint includes a plus sign ("+") in this configuration attribute to mandate support for this extension. An endpoint that receives this attribute prefixed with a plus sign and does not support this extension MUST treat that potential configuration as not valid.
The title parameter to the actual configuration attribute ('a=acfg') is formulated as a <sel-extension-config> with
sel-extension-config =/ sel-title-config
sel-title-config = "i=" title-cap-num ; as defined above.
hence
At present, it is difficult to envision a scenario in which the 'icap' attribute must be supported or the offer must be rejected. In most cases, if the icap attribute or its contents were to be ignored, an offered configuration could still be chosen based on other criteria such as configuration numbering. However, one might imagine an SDP offer that contained English and Spanish potential configurations for an audio stream. The session might be unintelligible if the choice is based on configuration numbering, rather than informed user selection. Based on such considerations, it may well prove useful to announce the ability to use the icap attribute and its contents to select media configurations, or to inform the user about the selected configuration(s). Therefore, we define a new option tag of "icap-v0" that identifies support for the title capability. This option tag SHOULD be added to other existing option tags present in the 'csup' and/or 'creq' attributes in SDP, according to the procedures defined in the SDP Capability Negotiation Framework [RFC5939]. The discussion above suggests that "icap-v0" will typically appear in a 'csup' attribute, but rarely in a 'creq' attribute.
The 'bcap', 'ccap' and 'icap' attributes can appear at the session level and/or at the media level. Endpoints MUST interpret capabilities declared at session level as part of the session level in the resulting SDP for that particular configuration. Endpoints MUST interpret capabilities declared at media level as part of the media level in the resulting SDP for that particular configuration.
If a 'bcap' capability for the same bwtype is declared at both session and media level, the media level attribute overrides the value of the session level attribute.
To avoid confusion, the <type-attr-num> for each 'a=bcap', 'a=ccap', and 'a=icap' line must be unique across all capability attributes of the same type within the entire session description.
In this section, we define extensions to the offer/answer model defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP Capability Negotiation [RFC5939] to allow for bandwidth and title capabilities to be used with the SDP Capability Negotiation framework.
When an endpoint generates an initial offer and wants to use the functionality described in the current document, it first defines appropriate values for the bandwidth, connection data, and/or title capability attributes according to rules defined in [RFC4566] for 'b=', 'c=' and 'i=' lines. The endpoint then MUST include the respective capability attributes and associated values in the SDP offer. The preferred configurations for each media stream are identified following the media line in a 'pcfg' attribute. Bandwidth and title capabilities may also be referenced in latent configurations in an 'lcfg' attribute, defined in [RFC5939].
The offer SHOULD include the level of capability negotiation extensions needed to support this functionality in a 'creq' attribute.
When the answering party receives the offer, and if it supports the required capability negotiation extensions, it SHOULD select the most preferred configuration it can support for each media stream, and build the answer accordingly, as defined in Section 3.6.2 of the SDP Capability Negotiation [RFC5939].
When the offerer receives the answer, it MUST process the media lines according to normal SDP processing rules to identify the media stream(s) accepted by the answer, if any. The 'acfg' attribute, if present, may be used to verify the proposed configuration used to form the answer, and to infer the lack of acceptability of higher-preference configurations that were not chosen.
If, at a later time, one of the parties wishes to modify the operating parameters of a session, e.g. by adding a new media stream, or by changing the properties used on an existing stream, it may do so via the mechanisms defined for SDP offer/answer [RFC3264].
To simplify the construction of SDP records, given the need to include fields within the media description in question for endpoints that do not support capabilities negotiation, we define some simple field-replacement rules for those fields invoked by potential or latent configurations. In particular, any 'i=' or 'c=' line invoked by a configuration MUST replace the corresponding line, if present within the media description in question. Any 'b=' line invoked by a configuration MUST replace any 'b=' of the same bandwidth type at the media level.
IANA is hereby requested to register new attributes in the "att-field (both session and media level)" of the "Session Description Protocol (SDP) Parameteres" registry, according to the following registration form:
Attribute name: bcap
Long form name: Bandwidth Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate session or media-level bandwidths
Appropriate values: See RFC XXXX
[Note to the RFC Editor: Please replace the above RFC XXXX
with the RFC number of this specification.
Contact name: Miguel A. Garcia,
Miguel.A.Garcia@ericsson.com
Attribute name: ccap
Long form name: Connection Data Capability
Type of attribute: Both media and session level
Subject to charset: No
Purpose: Negotiate media-level connection data
Appropriate values: See RFC XXXX
[Note to the RFC Editor: Please replace the above RFC XXXX
with the RFC number of this specification.
Contact name: Miguel A. Garcia,
Miguel.A.Garcia@ericsson.com
Attribute name: icap
Long form name: Title Capability
Type of attribute: Both media and session level
Subject to charset: Yes
Purpose: Negotiate human-readable information
describing the session or media
Appropriate values: See RFC XXXX
[Note to the RFC Editor: Please replace the above RFC XXXX
with the RFC number of this specification.
Contact name: Miguel A. Garcia,
Miguel.A.Garcia@ericsson.com
IANA is hereby requested to add the new option tags "bcap-v0", "ccap-v0", and "icap-v0", defined herein, to the "SDP Capability Negotiation Option Tag subregistry" of the "Session Description Protocol (SDP) Parameters" registry.
IANA is hereby requested to add the new parameter identifiers "b" for "bandwidth", "c" for "connection data", and "i" for "title" to the "SDP Capability Negotiation Potential Configuration Parameters" subregistry of the "Session Description Protocol (SDP) Parameters" registry. These parameters are permitted in 'lcfg', 'acfg', and 'pcfg' attributes.
This document provides an extension on top of RFC 4566 [RFC4566], RFC 3264 [RFC3264], SDP Capability Negotiation Framework [RFC5939], and SDP media capabilities negotiation [I-D.ietf-mmusic-sdp-media-capabilities]. As such, the security considerations of those documents apply.
The bandwidth capability attribute may be used for reserving resources at endpoints and intermediaries which inspect the SDP. Modification of the bandwidth value by an attacker can lead to the network being underutilized (too high bandwidth value) or congested (too low bandwidth value). In case it is essential to protect the bandwidth value, one of the security mechanisms proposed in [RFC5939] should be used.
The 'i=' line and thus the value carried in the title capability attribute is intended for human-readable description only. It should not be parsed programmatically.
Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson for arguing for the existence of this document and early reviewing it. Thanks to Flemming Andreasen, Andrew Allen, and Jonathan Lennox for a detailed review and many improvement suggestions.
| [RFC5939] | Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, September 2010. |
| [I-D.ietf-mmusic-sdp-media-capabilities] | Gilman, R, Even, R and F Andreasen, "SDP Media Mapabilities Negotiation", Internet-Draft draft-ietf-mmusic-sdp-media-capabilities-11, February 2011. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3264] | Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. |
| [RFC4566] | Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |