draft-ietf-mmusic-rfc4566bis-12.txt   draft-ietf-mmusic-rfc4566bis-13.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 4566 (if approved) V. Jacobson Obsoletes: 4566 (if approved) V. Jacobson
Intended status: Standards Track PARC Intended status: Standards Track PARC
Expires: March 27, 2015 C.S. Perkins Expires: July 17, 2015 C.S. Perkins
University of Glasgow University of Glasgow
A. Begen A. Begen
Cisco Cisco
September 23, 2014 January 13, 2015
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-12 draft-ietf-mmusic-rfc4566bis-13
Abstract Abstract
This memo defines the Session Description Protocol (SDP). SDP is This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of session announcement, session invitation, and other forms of
multimedia session initiation. This document obsoletes RFC 4566. multimedia session initiation. This document obsoletes RFC 4566.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 27, 2015. This Internet-Draft will expire on July 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 32 skipping to change at page 3, line 32
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 39 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 39
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 42 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 42
8.2. Registration of Parameters . . . . . . . . . . . . . . . 43 8.2. Registration of Parameters . . . . . . . . . . . . . . . 43
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 44 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 44
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 45 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 45
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 47 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 47 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 47
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 47 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 47
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 48 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 47
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 48 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 48
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.1. Normative References . . . . . . . . . . . . . . . . . . 55 12.1. Normative References . . . . . . . . . . . . . . . . . . 54
12.2. Informative References . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
skipping to change at page 26, line 38 skipping to change at page 26, line 38
Value: cat-value Value: cat-value
Usage Level: session Usage Level: session
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
cat-value = category cat-value = category
category = byte-string category = none-ws-string
; Note: syntax is vague because usage is not understood
Example: Example:
a=cat:foo.bar a=cat:foo.bar
This attribute gives the dot-separated hierarchical category of the This attribute gives the dot-separated hierarchical category of the
session. This is to enable a receiver to filter unwanted sessions by session. This is to enable a receiver to filter unwanted sessions by
category. There is no central registry of categories. category. There is no central registry of categories. This
attribute is obsoleted.
6.2. keywds (keywords) 6.2. keywds (keywords)
Name: keywds Name: keywds
Value: keywds-value Value: keywds-value
Usage Level: session Usage Level: session
Charset Dependent: yes Charset Dependent: yes
Syntax: Syntax:
keywds-value = keywords keywds-value = keywords
keywords = byte-string keywords = text
; Note: syntax is vague because usage is not understood
Example: Example:
a=keywds:SDP session description protocol a=keywds:SDP session description protocol
Like the cat attribute, this is to assist identifying wanted sessions Like the cat attribute, this is to assist identifying wanted sessions
at the receiver. This allows a receiver to select interesting at the receiver. This allows a receiver to select interesting
session based on keywords describing the purpose of the session; session based on keywords describing the purpose of the session;
there is no central registry of keywords. session-level attribute. there is no central registry of keywords. Its value should be
Its value should be interpreted in the charset specified for the interpreted in the charset specified for the session description if
session description if one is specified, or by default in ISO 10646/ one is specified, or by default in ISO 10646/UTF-8. This attribute
UTF-8. is obsoleted.
6.3. tool 6.3. tool
Name: tool Name: tool
Value: tool-value Value: tool-value
Usage Level: session Usage Level: session
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
tool-value = tool-name-and-version tool-value = tool-name-and-version
tool-name-and-version = byte-string tool-name-and-version = text
; Note: syntax is vague because usage is not understood
Example: Example:
a=tool:foobar V3.2 a=tool:foobar V3.2
This gives the name and version number of the tool used to create the This gives the name and version number of the tool used to create the
session description. session description.
6.4. ptime (packet time) 6.4. ptime (packet time)
Name: ptime Name: ptime
Value: ptime-value Value: ptime-value
Usage Level: media Usage Level: media
skipping to change at page 30, line 8 skipping to change at page 30, line 8
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
rtpmap-value = payload-type SP encoding-name rtpmap-value = payload-type SP encoding-name
"/" clock-rate [ "/" encoding-params ] "/" clock-rate [ "/" encoding-params ]
payload-type = integer payload-type = integer
; do we want to define a limited range for this
; based on how big a PT can be in RTP?
encoding-name = token encoding-name = token
; To be matched in a case-insensitive way! ; To be matched in a case-insensitive way!
; RFC4855 seems to be the primary definition for this. ; RFC4855 seems to be the primary definition for this.
; It refers both to RFC2045 and RFC4288 for the definition. ; It refers both to RFC2045 and RFC4288 for the definition.
; The definition in RFC2045 is messy, ; The definition in RFC2045 is messy,
; but equivalent to SDP <token>. ; but equivalent to SDP <token>.
; The definition in RFC4288 (<subtype-name>) is more ; The definition in RFC4288 (<subtype-name>) is more
; restrictive and governs what can be registered. ; restrictive and governs what can be registered.
; Since ultimately only registered names can be referenced, ; Since ultimately only registered names can be referenced,
; using <token> here seems safe and easy. ; using <token> here seems safe and easy.
skipping to change at page 30, line 39 skipping to change at page 30, line 37
; seems a misdirection - additional parameters are ; seems a misdirection - additional parameters are
; to go into a=fmtp.) ; to go into a=fmtp.)
; Does anyone have an example of other parameters ; Does anyone have an example of other parameters
; using this field? ; using this field?
channels = integer channels = integer
; Is there any reason to make this less restrictive? ; Is there any reason to make this less restrictive?
This attribute maps from an RTP payload type number (as used in an This attribute maps from an RTP payload type number (as used in an
"m=" line) to an encoding name denoting the payload format to be "m=" line) to an encoding name denoting the payload format to be
used. It also provides information on the clock rate and encoding used. It also provides information on the clock rate and encoding
parameters. parameters. Note that the payload type number is indicated in a
7-bit field, limiting the values to incusively between 0 and 127.
Although an RTP profile can make static assignments of payload type Although an RTP profile can make static assignments of payload type
numbers to payload formats, it is more common for that assignment to numbers to payload formats, it is more common for that assignment to
be done dynamically using "a=rtpmap:" attributes. As an example of a be done dynamically using "a=rtpmap:" attributes. As an example of a
static payload type, consider u-law PCM coded single-channel audio static payload type, consider u-law PCM coded single-channel audio
sampled at 8 kHz. This is completely defined in the RTP Audio/Video sampled at 8 kHz. This is completely defined in the RTP Audio/Video
profile as payload type 0, so there is no need for an "a=rtpmap:" profile as payload type 0, so there is no need for an "a=rtpmap:"
attribute, and the media for such a stream sent to UDP port 49232 can attribute, and the media for such a stream sent to UDP port 49232 can
be specified as: be specified as:
skipping to change at page 35, line 21 skipping to change at page 35, line 21
Syntax: Syntax:
type-value = conference-type type-value = conference-type
conference-type = broadcast / meeting / moderated / test / H332 conference-type = broadcast / meeting / moderated / test / H332
broadcast = %x62.72.6f.61.64.63.61.73.74 ; "broadcast" broadcast = %x62.72.6f.61.64.63.61.73.74 ; "broadcast"
meeting = %x6d.65.65.74.69.6e.67 ; "meeting" meeting = %x6d.65.65.74.69.6e.67 ; "meeting"
moderated = %x6d.6f.64.65.72.61.74.65.64 ; "moderated" moderated = %x6d.6f.64.65.72.61.74.65.64 ; "moderated"
test = %x74.65.73.74 ; "test" test = %x74.65.73.74 ; "test"
H332 = %x48.33.33.32 ; "H332" H332 = %x48.33.33.32 ; "H332"
; NOTE: are these names intended to be case-sensitive? ; NOTE: These names are case-sensitive.
; Should there be an extensibility hook? A registry?
Example: Example:
a=type:moderated a=type:moderated
This specifies the type of the multimedia conference. Suggested This specifies the type of the multimedia conference. Suggested
values are "broadcast", "meeting", "moderated", "test", and "H332". values are "broadcast", "meeting", "moderated", "test", and "H332".
"recvonly" should be the default for "type:broadcast" sessions, "recvonly" should be the default for "type:broadcast" sessions,
"type:meeting" should imply "sendrecv", and "type:moderated" should "type:meeting" should imply "sendrecv", and "type:moderated" should
indicate the use of a floor control tool and that the media tools are indicate the use of a floor control tool and that the media tools are
skipping to change at page 36, line 4 skipping to change at page 35, line 48
Specifying the attribute "type:test" is suggested as a hint that, Specifying the attribute "type:test" is suggested as a hint that,
unless explicitly requested otherwise, receivers can safely avoid unless explicitly requested otherwise, receivers can safely avoid
displaying this session description to users. displaying this session description to users.
6.10. charset (character set) 6.10. charset (character set)
Name: charset Name: charset
Value: charset-value Value: charset-value
Usage Level: session
Usage Level: session
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
charset-value = iana-charset-preferred-mime-name charset-value = mime-charset
iana-charset-preferred-mime-name = 1*40VCHAR mime-charset = 1*mime-charset-chars
; Should we be using Preferred MIME Name or Name? mime-charset-chars = ALPHA / DIGIT /
; Should SP be allowed in the name? "!" / "#" / "$" / "%" / "&" /
"'" / "+" / "-" / "^" / "_" /
"`" / "{" / "}" / "~"
This specifies the character set to be used to display the session This specifies the character set to be used to display the session
name and information data. By default, the ISO-10646 character set name and information data. By default, the ISO-10646 character set
in UTF-8 encoding is used. If a more compact representation is in UTF-8 encoding is used. If a more compact representation is
required, other character sets may be used. For example, the ISO required, other character sets may be used. For example, the ISO
8859-1 is specified with the following SDP attribute: 8859-1 is specified with the following SDP attribute:
a=charset:ISO-8859-1 a=charset:ISO-8859-1
The charset specified MUST be one of those registered with IANA, such The charset specified MUST be one of those registered in the IANA
as ISO-8859-1. The character set identifier is a US-ASCII string and Character Sets registry (http://www.iana.org/assignments/character-
MUST be compared against the IANA identifiers using a case- sets), such as ISO-8859-1. The character set identifier is a US-
ASCII string and MUST be compared against identifiers from the "Name"
or "Preferred MIME Name" field of the registry using a case-
insensitive comparison. If the identifier is not recognised or not insensitive comparison. If the identifier is not recognised or not
supported, all strings that are affected by it SHOULD be regarded as supported, all strings that are affected by it SHOULD be regarded as
octet strings. octet strings.
Note that a character set specified MUST still prohibit the use of Note that a character set specified MUST still prohibit the use of
bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring
the use of these characters MUST define a quoting mechanism that the use of these characters MUST define a quoting mechanism that
prevents these bytes from appearing within text fields. prevents these bytes from appearing within text fields.
6.11. sdplang (SDP language) 6.11. sdplang (SDP language)
skipping to change at page 37, line 5 skipping to change at page 37, line 5
Name: sdplang Name: sdplang
Value: sdplang-value Value: sdplang-value
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
sdplang-value = Language-Tag sdplang-value = Language-Tag (as defined in <xref
Language-Tag = token target="RFC5646"/>)
; the actual definition of <Language-Tag> is in RFC5646.
; That is a proper subset of <token>. Since the use here is
; to reference definitions done elsewhere against the
; more restrictive definition, it seems reasonable to use
; the simpler syntax here.
; Should we actually reference the RFC5646 definition?
Example: Example:
a=sdplang:fr a=sdplang:fr
This can be a session-level attribute or a media-level attribute. This can be a session-level attribute or a media-level attribute.
Multiple sdplang attributes can be provided either at session or Multiple sdplang attributes can be provided either at session or
media level if the session description or media use multiple media level if the session description or media use multiple
languages. languages.
skipping to change at page 38, line 4 skipping to change at page 37, line 45
6.12. lang (language) 6.12. lang (language)
Name: lang Name: lang
Value: lang-value Value: lang-value
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
Syntax:
lang-value = Language-Tag Syntax:
; <Language-Tag> defined with sdplang.
lang-value = Language-Tag (as defined in <xref
target="RFC5646"/>)
Example: Example:
a=lang:de a=lang:de
Multiple lang attributes can be provided either at session or media Multiple lang attributes can be provided either at session or media
level if the session or media use multiple languages, in which case level if the session or media use multiple languages, in which case
the order of the attributes indicates the order of importance of the the order of the attributes indicates the order of importance of the
various languages in the session or media, from most important to various languages in the session or media, from most important to
least important. least important.
skipping to change at page 40, line 4 skipping to change at page 39, line 41
quality. For video, the value is in the range 0 to 10, with the quality. For video, the value is in the range 0 to 10, with the
following suggested meaning: following suggested meaning:
10 - the best still-image quality the compression scheme 10 - the best still-image quality the compression scheme
can give. can give.
5 - the default behaviour given no quality suggestion. 5 - the default behaviour given no quality suggestion.
0 - the worst still-image quality the codec designer 0 - the worst still-image quality the codec designer
thinks is still usable. thinks is still usable.
6.15. fmtp (format parameters) 6.15. fmtp (format parameters)
Name: fmtp Name: fmtp
Value: fmtp-value Value: fmtp-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
fmtp-value = fmt SP format-specific-params fmtp-value = fmt SP format-specific-params
format-specific-params = byte-string format-specific-params = byte-string
; Notes: ; Notes:
; - I've assumed a space separator is required. ; - The format parameters are media type parameters and
; - the rest is vague because it is format-specific. need to reflect their syntax.
Example: Example:
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
This attribute allows parameters that are specific to a particular This attribute allows parameters that are specific to a particular
format to be conveyed in a way that SDP does not have to understand format to be conveyed in a way that SDP does not have to understand
them. The format must be one of the formats specified for the media. them. The format must be one of the formats specified for the media.
Format-specific parameters may be any set of parameters required to Format-specific parameters may be any set of parameters required to
be conveyed by SDP and given unchanged to the media tool that will be conveyed by SDP and given unchanged to the media tool that will
skipping to change at page 45, line 41 skipping to change at page 45, line 35
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the "Specification Required" policy of [RFC5226], provided that the
specification includes the following information: specification includes the following information:
o Contact name, email address, and telephone number. o Contact name, email address, and telephone number.
o Attribute name (as it will appear in SDP). This MUST conform to o Attribute name (as it will appear in SDP). This MUST conform to
the definition of <att-field>. the definition of <att-field>.
o Attribute value: the name of an ABNF syntax rule defining the
syntax of the value. Absence of a rule name indicates that the
attribute takes no value. Enclosing the rule name in "[" and "]"
indicates that a value is optional.
o Long-form attribute name in English.
[ED: I propose that we drop the long form. It hasn't been used
and isn't needed.]
o Usage level of the attribute. (One or more of: session, media). o Usage level of the attribute. (One or more of: session, media).
o Whether the attribute value is subject to the charset attribute. o Whether the attribute value is subject to the charset attribute.
o An ABNF definition of the attribute value rule. The rule MUST NOT o An ABNF definition of the attribute value rule. The rule MUST NOT
match anything that is not also matched by <att-value>. The rule match anything that is not also matched by <att-value>. The rule
name SHOULD [MUST?] NOT be defined as an Incremental Alternative name SHOULD [MUST?] NOT be defined as an Incremental Alternative
to <att-value>. to <att-value>.
o An explanation of the purpose and usage of the attribute. o An explanation of the purpose and usage of the attribute.
skipping to change at page 54, line 22 skipping to change at page 54, line 5
addresses in case of ICE-like SDP extensions. addresses in case of ICE-like SDP extensions.
Normative and informative references have been updated. Normative and informative references have been updated.
The text regarding the session vs. media-level attribute usage has The text regarding the session vs. media-level attribute usage has
been clarified. been clarified.
The case-insensitivity rules from RFC 4855 have been included in this The case-insensitivity rules from RFC 4855 have been included in this
document. document.
The following purely editorial changes have been made:
o Section 4.6: fix typo in first sentence: "sets" -> "set"
o Section 5: clarify second paragraph (SDP field and attribute names
use the US-ASCII subset of UTF-8).
o Section 5: clarify that an SDP session description can contain
only a session-level section, with no media-level section, and
that a media-level section can be terminated by the end of the
session description, and not always by another media-level
section.
o Section 5: clearly differentiate "media" and "media description"
in the description of the "c=" line.
o Section 5.2: when describing the <unicast-address> field, clarify
that "an" address of the machine is used, rather than "the"
address of the machine, since IP addresses identify interfaces,
not hosts.
o Section 5.6: use "session" rather than "conference"
o Section 5.10: fix typo: "To make description" -> "To make the
description"
o Section 5.11: use "session description" rather than "session
announcement" in the final paragraph
o Section 7: fix typo: "distribute session description" ->
"distribute session descriptions"
11. Acknowledgements 11. Acknowledgements
Many people in the IETF Multiparty Multimedia Session Control Many people in the IETF Multiparty Multimedia Session Control
(MMUSIC) working group have made comments and suggestions (MMUSIC) working group have made comments and suggestions
contributing to this document. In particular, we would like to thank contributing to this document.
Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna,
Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan
Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, Spencer
Dawkins, Alfred Hoenes, Brett Tate and Paul Kyzivat.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
 End of changes. 31 change blocks. 
98 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/