draft-ietf-mmusic-rfc4566bis-28.txt   draft-ietf-mmusic-rfc4566bis-29.txt 
Network Working Group A. Begen Network Working Group A. Begen
Internet-Draft Networked Media Internet-Draft Networked Media
Obsoletes: 4566 (if approved) P. Kyzivat Obsoletes: 4566 (if approved) P. Kyzivat
Intended status: Standards Track Intended status: Standards Track
Expires: November 22, 2018 C. Perkins Expires: December 7, 2018 C. Perkins
University of Glasgow University of Glasgow
M. Handley M. Handley
UCL UCL
May 21, 2018 June 5, 2018
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-28 draft-ietf-mmusic-rfc4566bis-29
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 22, 2018. This Internet-Draft will expire on December 7, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 11, line 24 skipping to change at page 11, line 24
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.2 c=IN IP4 233.252.0.2
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0 m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
Text containing fields such as the session name and information are Text containing fields such as the session-name-field and
octet strings that may contain any octet with the exceptions of 0x00 information-field are octet strings that may contain any octet with
(Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII
sequence CRLF (0x0d0a) is used to end a record, although parsers carriage return). The sequence CRLF (0x0d0a) is used to end a
SHOULD be tolerant and also accept records terminated with a single record, although parsers SHOULD be tolerant and also accept records
newline character. If the "a=charset" attribute is not present, terminated with a single newline character. If the "a=charset"
these octet strings MUST be interpreted as containing ISO-10646 attribute is not present, these octet strings MUST be interpreted as
characters in UTF-8 encoding (the presence of the "a=charset" containing ISO-10646 characters in UTF-8 encoding (the presence of
attribute may force some fields to be interpreted differently). the "a=charset" attribute may force some fields to be interpreted
differently).
A session description can contain domain names in the "o=", "u=", A session description can contain domain names in the "o=", "u=",
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply
with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) with [RFC1034], [RFC1035]. Internationalized domain names (IDNs)
MUST be represented using the ASCII Compatible Encoding (ACE) form MUST be represented using the ASCII Compatible Encoding (ACE) form
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or
any other encoding (this requirement is for compatibility with any other encoding (this requirement is for compatibility with
[RFC2327] and other early SDP-related standards, which predate the [RFC2327] and other early SDP-related standards, which predate the
development of internationalized domain names). development of internationalized domain names).
skipping to change at page 14, line 33 skipping to change at page 14, line 33
Inclusion of an email address or phone number is OPTIONAL. Inclusion of an email address or phone number is OPTIONAL.
If an email address or phone number is present, it MUST be specified If an email address or phone number is present, it MUST be specified
before the first media description. More than one email or phone before the first media description. More than one email or phone
line can be given for a session description. line can be given for a session description.
Phone numbers SHOULD be given in the form of an international public Phone numbers SHOULD be given in the form of an international public
telecommunication number (see ITU-T Recommendation E.164 [E164]) telecommunication number (see ITU-T Recommendation E.164 [E164])
preceded by a "+". Spaces and hyphens may be used to split up a preceded by a "+". Spaces and hyphens may be used to split up a
phone field to aid readability if desired. For example: phone-field to aid readability if desired. For example:
p=+1 617 555-6011 p=+1 617 555-6011
Both email addresses and phone numbers can have an OPTIONAL free text Both email addresses and phone numbers can have an OPTIONAL free text
string associated with them, normally giving the name of the person string associated with them, normally giving the name of the person
who may be contacted. This MUST be enclosed in parentheses if it is who may be contacted. This MUST be enclosed in parentheses if it is
present. For example: present. For example:
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
skipping to change at page 15, line 38 skipping to change at page 15, line 38
address. Additional sub-fields MAY be added after the connection address. Additional sub-fields MAY be added after the connection
address depending on the value of the <addrtype> sub-field. address depending on the value of the <addrtype> sub-field.
When the <addrtype> is IP4 and IP6, the connection address is defined When the <addrtype> is IP4 and IP6, the connection address is defined
as follows: as follows:
o If the session is multicast, the connection address will be an IP o If the session is multicast, the connection address will be an IP
multicast group address. If the session is not multicast, then multicast group address. If the session is not multicast, then
the connection address contains the unicast IP address of the the connection address contains the unicast IP address of the
expected data source, data relay or data sink as determined by expected data source, data relay or data sink as determined by
additional attribute fields. It is not expected that unicast additional attribute-fields. It is not expected that unicast
addresses will be given in a session description that is addresses will be given in a session description that is
communicated by a multicast announcement, though this is not communicated by a multicast announcement, though this is not
prohibited. prohibited.
o Sessions using an IP4 multicast connection address MUST also have o Sessions using an IP4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with address. The TTL and the address together define the scope with
which multicast packets sent in this session will be sent. TTL which multicast packets sent in this session will be sent. TTL
values MUST be in the range 0-255. Although the TTL MUST be values MUST be in the range 0-255. Although the TTL MUST be
specified, its use to scope multicast traffic is deprecated; specified, its use to scope multicast traffic is deprecated;
skipping to change at page 17, line 52 skipping to change at page 17, line 52
sending simultaneously. sending simultaneously.
A prefix "X-" is defined for <bwtype> names. This is intended for A prefix "X-" is defined for <bwtype> names. This is intended for
experimental purposes only. For example: experimental purposes only. For example:
b=X-YZ:128 b=X-YZ:128
Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-" Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-"
prefix) <bwtype> names SHOULD be defined, and then MUST be registered prefix) <bwtype> names SHOULD be defined, and then MUST be registered
with IANA in the standard namespace. SDP parsers MUST ignore with IANA in the standard namespace. SDP parsers MUST ignore
bandwidth fields with unknown <bwtype> names. The <bwtype> names bandwidth-fields with unknown <bwtype> names. The <bwtype> names
MUST be alphanumeric and, although no length limit is given, it is MUST be alphanumeric and, although no length limit is given, it is
recommended that they be short. recommended that they be short.
The <bandwidth> is interpreted as kilobits per second by default The <bandwidth> is interpreted as kilobits per second by default
(including the transport and network-layer but not the link-layer (including the transport and network-layer but not the link-layer
overhead). The definition of a new <bwtype> modifier MAY specify overhead). The definition of a new <bwtype> modifier MAY specify
that the bandwidth is to be interpreted in some alternative unit (the that the bandwidth is to be interpreted in some alternative unit (the
"CT" and "AS" modifiers defined in this memo use the default units). "CT" and "AS" modifiers defined in this memo use the default units).
5.9. Time Active ("t=") 5.9. Time Active ("t=")
skipping to change at page 21, line 14 skipping to change at page 21, line 14
5.13. Attributes ("a=") 5.13. Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level" be defined to be used as "session-level" attributes, "media-level"
attributes, or both. attributes, or both.
A media description may have any number of "a=" lines (attribute- A media description may contain any number of "a=" lines (attribute-
fields) that are media description specific. These are referred to fields) that are media description specific. These are referred to
as "media-level" attributes and add information about the media as "media-level" attributes and add information about the media
description. Attribute fields can also be added before the first description. Attribute-fields can also be added before the first
media description; these "session-level" attributes convey additional media description; these "session-level" attributes convey additional
information that applies to the session as a whole rather than to information that applies to the session as a whole rather than to
individual media descriptions. individual media descriptions.
Attribute fields may be of two forms: Attribute-fields may be of two forms:
o A property attribute is simply of the form "a=<attribute>". These o A property attribute is simply of the form "a=<attribute>". These
are binary attributes, and the presence of the attribute conveys are binary attributes, and the presence of the attribute conveys
that the attribute is a property of the session. An example might that the attribute is a property of the session. An example might
be "a=recvonly". be "a=recvonly".
o A value attribute is of the form "a=<attribute>:<value>". For o A value attribute is of the form "a=<attribute>:<value>". For
example, a whiteboard could have the value attribute example, a whiteboard could have the value attribute
"a=orient:landscape" "a=orient:landscape"
skipping to change at page 22, line 12 skipping to change at page 22, line 12
attribute is received that is not understood, it MUST be ignored by attribute is received that is not understood, it MUST be ignored by
the receiver. the receiver.
5.14. Media Descriptions ("m=") 5.14. Media Descriptions ("m=")
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" line (media-field) and is Each media description starts with an "m=" line (media-field) and is
terminated by either the next "m=" line or by the end of the session terminated by either the next "m=" line or by the end of the session
description. A media field has several sub-fields: description. A media-field has several sub-fields:
<media> is the media type. This document defines the values <media> is the media type. This document defines the values
"audio", "video", "text", "application", and "message". This list "audio", "video", "text", "application", and "message". This list
is extended by other memos and may be further extended by is extended by other memos and may be further extended by
additional memos registering media types in the future (see additional memos registering media types in the future (see
Section 8). For example, [RFC6466] defined the "image" media Section 8). For example, [RFC6466] defined the "image" media
type. type.
<port> is the transport port to which the media stream is sent. The <port> is the transport port to which the media stream is sent. The
meaning of the transport port depends on the network being used as meaning of the transport port depends on the network being used as
specified in the relevant "c=" line, and on the transport protocol specified in the relevant "c=" line, and on the transport protocol
defined in the <proto> sub-field of the media field. Other ports defined in the <proto> sub-field of the media-field. Other ports
used by the media application (such as the RTP Control Protocol used by the media application (such as the RTP Control Protocol
(RTCP) port [RFC3550]) MAY be derived algorithmically from the (RTCP) port [RFC3550]) MAY be derived algorithmically from the
base media port or MAY be specified in a separate attribute (for base media port or MAY be specified in a separate attribute (for
example, "a=rtcp:" as defined in [RFC3605]). example, "a=rtcp:" as defined in [RFC3605]).
If non-contiguous ports are used or if they don't follow the If non-contiguous ports are used or if they don't follow the
parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:"
attribute MUST be used. Applications that are requested to send attribute MUST be used. Applications that are requested to send
media to a <port> that is odd and where the "a=rtcp:" is present media to a <port> that is odd and where the "a=rtcp:" is present
MUST NOT subtract 1 from the RTP port: that is, they MUST send the MUST NOT subtract 1 from the RTP port: that is, they MUST send the
skipping to change at page 23, line 32 skipping to change at page 23, line 32
This document provides no semantics for using multiple "m=" lines This document provides no semantics for using multiple "m=" lines
using the same transport address. This implies that, unlike using the same transport address. This implies that, unlike
limited past practice, there is no implicit grouping defined by limited past practice, there is no implicit grouping defined by
such means and an explicit grouping framework (for example, such means and an explicit grouping framework (for example,
[RFC5888]) should instead be used to express the intended [RFC5888]) should instead be used to express the intended
semantics. Such semantics may alo be added as extensions. For semantics. Such semantics may alo be added as extensions. For
instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation].
<proto> is the transport protocol. The meaning of the transport <proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type sub-field in the protocol is dependent on the address type sub-field in the
relevant "c=" line. Thus a "c=" field of IP4 indicates that the relevant "c=" line. Thus a "c=" line with an address type of IP4
transport protocol runs over IP4. The following transport indicates that the transport protocol runs over IP4. The
protocols are defined, but may be extended through registration of following transport protocols are defined, but may be extended
new protocols with IANA (see Section 8): through registration of new protocols with IANA (see Section 8):
* udp: denotes that the data is transported directly in UDP with * udp: denotes that the data is transported directly in UDP with
no additional framing. no additional framing.
* RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for
Audio and Video Conferences with Minimal Control [RFC3551] Audio and Video Conferences with Minimal Control [RFC3551]
running over UDP. running over UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol * RTP/SAVP: denotes the Secure Real-time Transport Protocol
[RFC3711] running over UDP. [RFC3711] running over UDP.
skipping to change at page 34, line 31 skipping to change at page 34, line 31
a=sdplang:fr a=sdplang:fr
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.
As a session-level attribute, it specifies the language for the As a session-level attribute, it specifies the language for the
session description (not the language of the media). As a media- session description (not the language of the media). As a media-
level attribute, it specifies the language for any media-level SDP level attribute, it specifies the language for any media-level SDP
information field associated with that media (again not the language information-field associated with that media (again not the language
of the media), overriding any sdplang attributes specified at session of the media), overriding any sdplang attributes specified at session
level. level.
In general, sending session descriptions consisting of multiple In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple sesssion descriptions languages is discouraged. Instead, multiple sesssion descriptions
SHOULD be sent describing the session, one in each language. SHOULD be sent describing the session, one in each language.
However, this is not possible with all transport mechanisms, and so However, this is not possible with all transport mechanisms, and so
multiple sdplang attributes are allowed although NOT RECOMMENDED. multiple sdplang attributes are allowed although NOT RECOMMENDED.
The "sdplang" attribute value must be a single [RFC5646] language tag The "sdplang" attribute value must be a single [RFC5646] language tag
skipping to change at page 42, line 40 skipping to change at page 42, line 40
For other protocols, formats MAY be registered according to the rules For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification. of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols Registrations of new formats MUST specify which transport protocols
they apply to. they apply to.
8.2.4. Attribute Names ("att-field") 8.2.4. Attribute Names ("att-field")
8.2.4.1. New Attributes 8.2.4.1. New Attributes
Attribute field names ("att-field") MUST be registered with IANA and Attribute-field names ("att-field") MUST be registered with IANA and
documented, to avoid any issues due to conflicting attribute documented, to avoid any issues due to conflicting attribute
definitions under the same name. Unknown attributes in SDP are definitions under the same name. Unknown attributes in SDP are
simply ignored, but conflicting ones that fragment the protocol are a simply ignored, but conflicting ones that fragment the protocol are a
serious problem. serious problem.
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC8126], provided that the "Specification Required" policy of [RFC8126], provided that the
specification includes the following information: specification includes the following information:
o Contact Name. o Contact Name.
skipping to change at page 45, line 22 skipping to change at page 45, line 22
o Reference: A new reference MUST be provided. o Reference: A new reference MUST be provided.
Items SHOULD be omitted if there is no impact to them as a result of Items SHOULD be omitted if there is no impact to them as a result of
the attribute update. the attribute update.
8.2.5. Bandwidth Specifiers ("bwtype") 8.2.5. Bandwidth Specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers ("bwtype" fields) MUST be registered with New bandwidth specifiers (<bwtype> sub-field values) MUST be
IANA. The submission MUST reference a standards-track RFC specifying registered with IANA. The submission MUST reference a standards-
the semantics of the bandwidth specifier precisely, and indicating track RFC specifying the semantics of the bandwidth specifier
when it should be used, and why the existing registered bandwidth precisely, and indicating when it should be used, and why the
specifiers do not suffice. existing registered bandwidth specifiers do not suffice.
IANA has registered the bandwidth specifiers "CT" and "AS" with IANA has registered the bandwidth specifiers "CT" and "AS" with
definitions as in Section 5.8 of this memo (these definitions update definitions as in Section 5.8 of this memo (these definitions update
those in [RFC4566]). those in [RFC4566]).
8.2.6. Network Types ("nettype") 8.2.6. Network Types ("nettype")
New network types (the "nettype" sub-field) MUST be registered with New network types (<nettype> sub-field values) MUST be registered
IANA if SDP needs to be used in the context of non-Internet with IANA if SDP needs to be used in the context of non-Internet
environments. The registration is subject to the "RFC Required" environments. The registration is subject to the "RFC Required"
policy of [RFC8126]. Although these are not normally the preserve of policy of [RFC8126]. Although these are not normally the preserve of
IANA, there may be circumstances when an Internet application needs IANA, there may be circumstances when an Internet application needs
to interoperate with a non-Internet application, such as when to interoperate with a non-Internet application, such as when
gatewaying an Internet telephone call into the Public Switched gatewaying an Internet telephone call into the Public Switched
Telephone Network (PSTN). The number of network types should be Telephone Network (PSTN). The number of network types should be
small and should be rarely extended. A new network type cannot be small and should be rarely extended. A new network type cannot be
registered without registering at least one address type to be used registered without registering at least one address type to be used
with that network type. A new network type registration MUST with that network type. A new network type registration MUST
reference an RFC that gives details of the network type and address reference an RFC that gives details of the network type and address
skipping to change at page 54, line 28 skipping to change at page 54, line 28
12.1. Normative References 12.1. Normative References
[E164] International Telecommunication Union, "E.164 : The [E164] International Telecommunication Union, "E.164 : The
international public telecommunication numbering plan", international public telecommunication numbering plan",
ITU Recommendation E.164, November 2010. ITU Recommendation E.164, November 2010.
[I-D.ietf-mmusic-data-channel-sdpneg] [I-D.ietf-mmusic-data-channel-sdpneg]
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
Marcon, J., and R. Even, "SDP-based Data Channel Marcon, J., and R. Even, "SDP-based Data Channel
Negotiation", draft-ietf-mmusic-data-channel-sdpneg-18 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-19
(work in progress), May 2018. (work in progress), May 2018.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018. (work in progress), February 2018.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
skipping to change at page 55, line 52 skipping to change at page 55, line 52
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-51 (work in progress), May 2018. negotiation-52 (work in progress), May 2018.
[ITU.H332.1998] [ITU.H332.1998]
International Telecommunication Union, "H.323 extended for International Telecommunication Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332, loosely coupled conferences", ITU Recommendation H.332,
September 1998. September 1998.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998,
<https://www.rfc-editor.org/info/rfc2327>. <https://www.rfc-editor.org/info/rfc2327>.
 End of changes. 20 change blocks. 
36 lines changed or deleted 37 lines changed or added

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