draft-ietf-mmusic-msid-01.txt   draft-ietf-mmusic-msid-02.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track August 13, 2013 Intended status: Standards Track November 5, 2013
Expires: February 14, 2014 Expires: May 9, 2014
Cross Session Stream Identification in the Session Description Protocol Cross Session Stream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-01 draft-ietf-mmusic-msid-02
Abstract Abstract
This document specifies a grouping mechanism for RTP media streams This document specifies a grouping mechanism for RTP media streams
that can be used to specify relations between media streams. that can be used to specify relations between media streams.
This mechanism is used to signal the association between the SDP This mechanism is used to signal the association between the SDP
concept of "m-line" and the WebRTC concept of "MediaStream" / concept of "m-line" and the WebRTC concept of "MediaStream" /
"MediaStreamTrack" using SDP signaling. "MediaStreamTrack" using SDP signaling.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 February 14, 2014. This Internet-Draft will expire on May 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Structure Of This Document . . . . . . . . . . . . . . . . 3 1.1. Structure Of This Document . . . . . . . . . . . . . . . . 3
1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3 1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3
1.3. Application to the WEBRTC MediaStream . . . . . . . . . . 4 1.3. Application to the WEBRTC MediaStream . . . . . . . . . . 4
2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . . 4
3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5 3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5
4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . . 6 4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . . 6
4.1. Handling of non-signalled tracks . . . . . . . . . . . . . 7 4.1. Handling of non-signalled tracks . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Design considerations, open questions and and Appendix A. Design considerations, open questions and and
alternatives . . . . . . . . . . . . . . . . . . . . 11 alternatives . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Usage with multiple MediaStreams per M-line . . . . . 11 Appendix B. Usage with multiple MediaStreams per M-line . . . . . 11
B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 11 B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 12
B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 12 B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 13
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13
C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13 C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13
C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13
C.3. Changes from alvestrand-rtcweb-msid-02 to C.3. Changes from alvestrand-rtcweb-msid-02 to
mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13 mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13
C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 13 C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 14
C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14 C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14
C.6. Changes from alvestrand-mmusic-msid-02 to C.6. Changes from alvestrand-mmusic-msid-02 to
ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14 ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14
C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14 C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
1.1. Structure Of This Document 1.1. Structure Of This Document
This document extends the SSRC grouping framework [RFC5888] by adding This document adds a new grouping relation between M-lines that can
a new grouping relation that can cross RTP session boundaries if associate application layer identifiers with the binding between
needed. media streams, attaching identifiers to the media streams and
attaching identifiers to the groupings they form.
Section 1.2 gives the background on why a new mechanism is needed. Section 1.2 gives the background on why a new mechanism is needed.
Section 2 gives the definition of the new mechanism. Section 2 gives the definition of the new mechanism.
Section 4 gives the application of the new mechanism for providing Section 4 gives the application of the new mechanism for providing
necessary semantic information for the association of necessary semantic information for the association of
MediaStreamTracks to MediaStreams in the WebRTC API . MediaStreamTracks to MediaStreams in the WebRTC API .
1.2. Why A New Mechanism Is Needed 1.2. Why A New Mechanism Is Needed
skipping to change at page 5, line 31 skipping to change at page 5, line 31
There may be multiple msid attributes on a single m-line. There may There may be multiple msid attributes on a single m-line. There may
also be multiple m-lines that have the same value for identifier and also be multiple m-lines that have the same value for identifier and
application data. application data.
Endpoints can update the associations between SSRCs as expressed by Endpoints can update the associations between SSRCs as expressed by
msid attributes at any time; the semantics and restrictions of such msid attributes at any time; the semantics and restrictions of such
grouping and ungrouping are application dependent. grouping and ungrouping are application dependent.
3. The Msid-Semantic Attribute 3. The Msid-Semantic Attribute
In order to fully reproduce the semantics of the SDP and SSRC A session-level attribute is defined for signaling the semantics
grouping frameworks, a session-level attribute is defined for associated with an msid grouping. This allows msid groupings with
signaling the semantics associated with an msid grouping. different semantics to coexist.
This OPTIONAL attribute gives the group identifier and its group This OPTIONAL attribute gives the group identifier and its group
semantic; it carries the same meaning as the ssrc-group-attr of RFC semantic; it carries the same meaning as the ssrc-group-attr of RFC
5576 section 4.2, but uses the identifier of the group rather than a 5576 section 4.2, but uses the identifier of the group rather than a
list of SSRC values. list of SSRC values.
This attribute MUST be present if "a=msid" is used.
An empty list of identifiers is an indication that the sender An empty list of identifiers is an indication that the sender
understands the indicated semantic, but has no msid groupings of the understands the indicated semantic, but has no msid groupings of the
given type in the present SDP. given type in the present SDP.
The ABNF of msid-semantic is: The ABNF of msid-semantic is:
attribute =/ msid-semantic-attr attribute =/ msid-semantic-attr
msid-semantic-attr = "msid-semantic:" token (" " identifier)* msid-semantic-attr = "msid-semantic:" token (" " identifier)*
token = <as defined in RFC 4566> token = <as defined in RFC 4566>
The semantic field may hold values from the IANA registries The semantic field may hold values from the IANA registriy "Semantics
"Semantics for the "ssrc-group" SDP Attribute" and "Semantics for the for the msid-semantic SDP attribute" (which is defined by this memo).
"group" SDP Attribute".
An example msid-semantic might look like this: An example msid-semantic might look like this, if a semantic LS was
registered by IANA for the same purpose as the existing LS grouping
semantic:
a=msid-semantic:LS xyzzy forolow a=msid-semantic:LS xyzzy forolow
This means that the SDP description has two lip sync groups, with the This means that the SDP description has two lip sync groups, with the
group identifiers xyzzy and forolow, respectively. group identifiers xyzzy and forolow, respectively.
4. Applying Msid to WebRTC MediaStreams 4. Applying Msid to WebRTC MediaStreams
This section creates a new semantic for use with the framework This section creates a new semantic for use with the framework
defined in Section 2, to be used for associating SSRCs representing defined in Section 2, to be used for associating SSRCs representing
MediaStreamTracks within MediaStreams as defined in MediaStreamTracks within MediaStreams as defined in
skipping to change at page 6, line 33 skipping to change at page 6, line 36
The value of the msid corresponds to the "id" attribute of a The value of the msid corresponds to the "id" attribute of a
MediaStream. MediaStream.
In a WebRTC-compatible SDP description, all SSRCs intending to be In a WebRTC-compatible SDP description, all SSRCs intending to be
sent from one peer will be identified in the SDP generated by that sent from one peer will be identified in the SDP generated by that
entity. entity.
The appdata for a WebRTC MediaStreamTrack consists of the "id" The appdata for a WebRTC MediaStreamTrack consists of the "id"
attribute of a MediaStreamTrack. attribute of a MediaStreamTrack.
If two different SSRCs have the same value for identifier and If two different m-lines have MSID attributes with the same value for
appdata, it means that these two SSRCs are both intended for the same identifier and appdata, it means that these two m-lines are both
MediaStreamTrack. This may occur if the sender wishes to use intended for the same MediaStreamTrack. So far, no semantic for such
simulcast or forward error correction, or if the sender intends to a mixture have been defined, but this specification does not forbid
switch between multiple codecs on the same MediaStreamTrack. the practice.
When an SDP description is updated, a specific msid continues to When an SDP description is updated, a specific msid continues to
refer to the same MediaStream. Once negotiation has completed on a refer to the same MediaStream. Once negotiation has completed on a
session, there is no memory; an msid value that appears in a later session, there is no memory; an msid value that appears in a later
negotiation will be taken to refer to a new MediaStream. negotiation will be taken to refer to a new MediaStream.
The following are the rules for handling updates of the list of The following are the rules for handling updates of the list of
m-lines and their msid values. m-lines and their msid values.
o When a new msid value occurs in the description, the recipient can o When a new msid value occurs in the description, the recipient can
signal to its application that a new MediaStream has been added. signal to its application that a new MediaStream has been added.
o When a description is updated to have more SSRCs with the same o When a description is updated to have more m-lines with the same
msid value, but different appdata values, the recipient can signal msid value, but different appdata values, the recipient can signal
to its application that new MediaStreamTracks have been added to to its application that new MediaStreamTracks have been added to
the media stream. the media stream.
o When a description is updated to no longer list the msid value on o When a description is updated to no longer list the msid value on
a specific ssrc, the recipient can signal to its application that a specific m-line, the recipient can signal to its application
the corresponding media stream track has been closed. that the corresponding media stream track has been closed.
o When a description is updated to no longer list the msid value on o When a description is updated to no longer list the msid value on
any ssrc, the recipient can signal to its application that the any m-line, the recipient can signal to its application that the
media stream has been closed. media stream has been closed.
In addition to signaling that the track is closed when it disappears In addition to signaling that the track is closed when it disappears
from the SDP, the track will also be signaled as being closed when from the SDP, the track will also be signaled as being closed when
all associated SSRCs have disappeared by the rules of [RFC3550] all associated SSRCs have disappeared by the rules of [RFC3550]
section 6.3.4 (BYE packet received) and 6.3.5 (timeout). section 6.3.4 (BYE packet received) and 6.3.5 (timeout).
The association between SSRCs and m-lines is specified in
[I-D.roach-mmusic-unified-plan].
4.1. Handling of non-signalled tracks 4.1. Handling of non-signalled tracks
Pre-WebRTC entities will not send msid. This means that there will Non-WebRTC entities will not send msid. This means that there will
be some incoming RTP packets with SSRCs where the recipient does not be some incoming RTP packets that the recipient has no predefined
know about a corresponding MediaStream id. MediaStream id value for.
Handling will depend on whether or not any MSIDs are signaled in the Handling will depend on whether or not any MSIDs are signaled in the
relevant m-line(s). There are two cases: relevant m-line(s). There are two cases:
o No msid-semantic:WMS attribute is present. The SDP session is o No msid-semantic:WMS attribute is present. The SDP session is
assumed to be a backwards-compatible session. All incoming SSRCs, assumed to be a backwards-compatible session. All incoming media,
on all m-lines that are part of the SDP session, are assumed to on all m-lines that are part of the SDP session, are assumed to
belong to independent media streams, each with one track. The belong to independent media streams, each with one track. The
identifier of this media stream and of the media stream track is a identifier of this media stream and of the media stream track is a
randomly generated string; the label of this media stream will be randomly generated string; the label of this media stream will be
set to "Non-WMS stream". set to "Non-WMS stream".
o An msid-semantic:WMS attribute is present. In this case, the o An msid-semantic:WMS attribute is present. In this case, the
session is WebRTC compatible, and the newly arrived SSRCs are session is WebRTC compatible, and the packets are either caused by
either caused by a bug or by timing skew between the arrival of a bug or by timing skew between the arrival of the media packets
the media packets and the SDP description. These packets MAY be and the SDP description. These packets MAY be discarded, or they
discarded, or they MAY be buffered for a while in order to allow MAY be buffered for a while in order to allow immediate startup of
immediate startup of the media stream when the SDP description is the media stream when the SDP description is updated. The arrival
updated. The arrival of media packets MUST NOT cause a new of media packets MUST NOT cause a new MediaStreamTrack to be
MediaStreamTrack to be signaled. signaled.
If a WebRTC entity sends a description, it MUST include the msid- If a WebRTC entity sends a description, it MUST include the msid-
semantic:WMS attribute, even if no media streams are sent. This semantic:WMS attribute, even if no media streams are sent. This
allows us to distinguish between the case of no media streams at the allows us to distinguish between the case of no media streams at the
moment and the case of legacy SDP generation. moment and the case of legacy SDP generation.
It follows from the above that the WebRTC entity must have the SDP of It follows from the above that the WebRTC entity must have the SDP of
the other party before it can decide correctly whether or not a the other party before it can decide correctly whether or not a
"default" MediaStream should be created. RTP media packets that "default" MediaStream should be created. RTP media packets that
arrive before the remote party's SDP MUST be buffered or discarded, arrive before the remote party's SDP MUST be buffered or discarded,
skipping to change at page 8, line 25 skipping to change at page 8, line 31
NOTE IN DRAFT: Previous versions of this memo suggested adding all NOTE IN DRAFT: Previous versions of this memo suggested adding all
incoming SSRCs to a single MediaStream. This is problematic because incoming SSRCs to a single MediaStream. This is problematic because
we do not know if the SSRCs are synchronized or not before we learn we do not know if the SSRCs are synchronized or not before we learn
the CNAME of the SSRCs, which only happens when an RTCP packet the CNAME of the SSRCs, which only happens when an RTCP packet
arrives. How to identify a non-WMS stream is still open for arrives. How to identify a non-WMS stream is still open for
discussion - including whether it's necessary to do so. Using the discussion - including whether it's necessary to do so. Using the
stream label seems like an easy thing to do for debuggability - it's stream label seems like an easy thing to do for debuggability - it's
not signalled, and is intended for human consumption anyway. not signalled, and is intended for human consumption anyway.
Another alternative is to group the incoming media streams based on
CNAME; this preseerves the synchronization semantics of CNAME, but
means that one cannot signal the MediaStreamTrack before the CNAME of
the SSRC is known (which will happen only on arrival of the relevant
RTCP packet).
5. IANA Considerations 5. IANA Considerations
This document requests IANA to register the "msid" attribute in the This document requests IANA to register the "msid" attribute in the
"att-field (media level only)" registry within the SDP parameters "att-field (media level only)" registry within the SDP parameters
registry, according to the procedures of [RFC4566] registry, according to the procedures of [RFC4566]
The required information is: The required information is:
o Contact name, email: IETF, contacted via mmusic@ietf.org, or a o Contact name, email: IETF, contacted via mmusic@ietf.org, or a
successor address designated by IESG successor address designated by IESG
skipping to change at page 10, line 4 skipping to change at page 10, line 17
reviewing this draft, with many specific language suggestions. reviewing this draft, with many specific language suggestions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[W3C.WD-webrtc-20120209] [W3C.WD-webrtc-20120209]
Bergkvist, A., Burnett, D., Narayanan, A., and C. Bergkvist, A., Burnett, D., Jennings, C., and A.
Jennings, "WebRTC 1.0: Real-time Communication Between Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD-webrtc- Browsers", World Wide Web Consortium WD WD-webrtc-
20120209, February 2012, 20120209, February 2012,
<http://www.w3.org/TR/2012/WD-webrtc-20120209>. <http://www.w3.org/TR/2012/WD-webrtc-20120209>.
8.2. Informative References 8.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,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", Protocol (SDP) Port Numbers",
draft-ietf-mmusic-sdp-bundle-negotiation-03 (work in draft-ietf-mmusic-sdp-bundle-negotiation-04 (work in
progress), February 2013. progress), June 2013.
[I-D.roach-mmusic-unified-plan] [I-D.roach-mmusic-unified-plan]
Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for
Using SDP with Large Numbers of Media Flows", Using SDP with Large Numbers of Media Flows",
draft-roach-mmusic-unified-plan-00 (work in progress), draft-roach-mmusic-unified-plan-00 (work in progress),
July 2013. July 2013.
[I-D.westerlund-avtcore-multiplex-architecture] [I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Burman, B., Perkins, C., and H. Westerlund, M., Perkins, C., and H. Alvestrand,
Alvestrand, "Guidelines for using the Multiplexing "Guidelines for using the Multiplexing Features of RTP",
Features of RTP", draft-westerlund-avtcore-multiplex-architecture-03 (work
draft-westerlund-avtcore-multiplex-architecture-02 (work in progress), February 2013.
in progress), July 2012.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
Appendix A. Design considerations, open questions and and alternatives Appendix A. Design considerations, open questions and and alternatives
This appendix should be deleted before publication as an RFC. This appendix should be deleted before publication as an RFC.
skipping to change at page 14, line 33 skipping to change at page 14, line 43
considering the synchronization problem. considering the synchronization problem.
Removed the space from between "msid-semantic" and its value, to be Removed the space from between "msid-semantic" and its value, to be
consistent with RFC 5576. consistent with RFC 5576.
C.7. Changes from mmusic-msid-00 to -01 C.7. Changes from mmusic-msid-00 to -01
Reworked msid mechanism to be a per-m-line attribute, to align with Reworked msid mechanism to be a per-m-line attribute, to align with
[I-D.roach-mmusic-unified-plan] [I-D.roach-mmusic-unified-plan]
C.8. Changes from mmusic-msid-01 to -02
Corrected several missed cases where the word "ssrc" was not changed
to "M-line".
Added pointer to unified-plan (which should be moved to point to
-jsep)
Removed suggestion that ssrc-group attributes can be used with "msid-
semantic", it is now only the msid-semantic registry.
Author's Address Author's Address
Harald Alvestrand Harald Alvestrand
Google Google
Kungsbron 2 Kungsbron 2
Stockholm, 11122 Stockholm, 11122
Sweden Sweden
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 28 change blocks. 
52 lines changed or deleted 75 lines changed or added

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