draft-ietf-mmusic-image-attributes-00.txt   draft-ietf-mmusic-image-attributes-01.txt 
Network Working Group I. Johansson Network Working Group I. Johansson
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track K. Jung Intended status: Standards Track K. Jung
Expires: August 10, 2009 Samsung Electronics Co., Ltd. Expires: September 7, 2009 Samsung Electronics Co., Ltd.
Feb 6, 2009 Mar 6, 2009
Negotiation of Generic Image Attributes in SDP Negotiation of Generic Image Attributes in SDP
draft-ietf-mmusic-image-attributes-00 draft-ietf-mmusic-image-attributes-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 10, 2009. This Internet-Draft will expire on September 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document proposes a new generic session setup attribute to make This document proposes a new generic session setup attribute to make
it possible to negotiate different image attributes such as image it possible to negotiate different image attributes such as image
size. A possible use case is to make it possible for a e.g a low-end size. A possible use case is to make it possible for a e.g a low-end
hand-held terminal to display video without the need to rescale the hand-held terminal to display video without the need to rescale the
image, something that may consume large amounts of memory and image, something that may consume large amounts of memory and
processing power. The draft also helps to maintain an optimal processing power. The draft also helps to maintain an optimal
bitrate for video as only the image size that is desired by the bitrate for video as only the image size that is desired by the
skipping to change at page 2, line 27 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4
3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4 3. Defintion of Attribute . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5 3.2. Attribute syntax . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5 3.2.1. Overall view of syntax . . . . . . . . . . . . . . . . 5
3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 8 3.2.2. Syntax description . . . . . . . . . . . . . . . . . . 8
3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 9 3.3.1. No imageattr in 1st offer . . . . . . . . . . . . . . 10
3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Asymmetry . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10 3.3.3. sendonly and recvonly . . . . . . . . . . . . . . . . 10
3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10 3.3.4. Sample aspect ratio . . . . . . . . . . . . . . . . . 10
3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 11 3.3.5. SDPCapNeg support . . . . . . . . . . . . . . . . . . 11
3.3.6. Interaction with codec parameters . . . . . . . . . . 11 3.3.6. Interaction with codec parameters . . . . . . . . . . 11
3.3.7. Change of display in middle of session . . . . . . . . 13 3.3.7. Change of display in middle of session . . . . . . . . 13
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.8. Addition of parameters . . . . . . . . . . . . . . . . 13
4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Informative References . . . . . . . . . . . . . . . . . . 16 10.1. Informative References . . . . . . . . . . . . . . . . . . 17
10.2. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Normative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document proposes a new attribute to make it possible to This document proposes a new attribute to make it possible to
negotiate different image attributes such as image size. The term negotiate different image attributes such as image size. The term
image size is defined here as it may differ from the physical screen image size is defined here as it may differ from the physical screen
size of e.g a hand-held terminal. For instance it may be beneficial size of e.g a hand-held terminal. For instance it may be beneficial
to display a video image on a part of the physical screen and leave to display a video image on a part of the physical screen and leave
space on the screen for e.g menus and other info. space on the screen for e.g menus and other info.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
However, what must then be considered is that: However, what must then be considered is that:
o Rescaling on the sender/encoder side is likely to be easier to do o Rescaling on the sender/encoder side is likely to be easier to do
as the camera related software/hardware already contains the as the camera related software/hardware already contains the
necessary functionality for zooming/cropping/trimming/sharpening necessary functionality for zooming/cropping/trimming/sharpening
the video signal. Moreover, rescaling is generally done in RGB or the video signal. Moreover, rescaling is generally done in RGB or
YUV domain and should not depend on the codecs used. YUV domain and should not depend on the codecs used.
o The encoder may be able to encode in a number of formats but may o The encoder may be able to encode in a number of formats but may
not know which format to choose. not know which format to choose as it, without the image
attribute, does not know the receivers performance or preference.
o The quality drop due to digital domain rescaling using o The quality drop due to digital domain rescaling using
interpolation is likely to be lower if it is done before the video interpolation is likely to be lower if it is done before the video
encoding rather than after the decoding esp. when low bitrate encoding rather than after the decoding esp. when low bitrate
video coding is used. video coding is used.
o If low-complexity rescaling operations such as cropping only must o If low-complexity rescaling operations such as cropping only must
be performed after all, the benefit with having this functionality be performed after all, the benefit with having this functionality
on the sender side is that it is then possible to present a on the sender side is that it is then possible to present a
miniature "what you send" image on the display to help the user to miniature "what you send" image on the display to help the user to
skipping to change at page 4, line 29 skipping to change at page 4, line 30
Several of the existing standards ([H.263], [H.264] and [MPEG-4]) Several of the existing standards ([H.263], [H.264] and [MPEG-4])
have support for different resolutions at different framerates. The have support for different resolutions at different framerates. The
purpose of this document is to provide for a generic mechanism and is purpose of this document is to provide for a generic mechanism and is
targeted mainly at the negotiation of the image size but to make it targeted mainly at the negotiation of the image size but to make it
more general the attribute is named "imageattr". A problem statement more general the attribute is named "imageattr". A problem statement
and discussion that gives a motivation to this document can be found and discussion that gives a motivation to this document can be found
in [S4-080144]. in [S4-080144].
The draft is limited to unicast scenarios in general and more The draft is limited to unicast scenarios in general and more
specific peer to peer situations. The attribute may be used in specific peer to peer or client to server situations. The attribute
centralized conferencing scenarios as well but due to the abundance may be used in centralized conferencing scenarios as well but due to
of configuration options it may then be difficult to come up with a the abundance of configuration options it may then be difficult to
configuration that fits all parties. come up with a configuration that fits all parties.
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
3. Defintion of Attribute 3. Defintion of Attribute
A new image attribute is defined with the name "imageattr". The A new image attribute is defined with the name "imageattr". The new
image attribute contains a set of different image-resolution options SDP attribute contains a set of image attribute options that the
that the offerer can provide. The receiver can then select the offerer can provide. The receiver can then select the desired image
desired image attribute (e.g image size) and may then have the attribute (e.g image size in pixels) and may then have the ability to
ability to avoid costly transformations (e.g rescaling) of the avoid costly transformations (e.g rescaling) of the images. In this
images. In this approach only the image resolution and optionally approach only the image resolution and optionally sample aspect
sample aspect ratio, allowed range in picture aspect ratio and ratio, allowed range in picture aspect ratio and preference is
preference is covered but the framework makes it possible to extend covered but the framework makes it possible to extend with other
with other image related attributes that make sense. image related attributes that make sense.
3.1. Requirements 3.1. Requirements
The new image attribute should meet the following requirements: The new image attribute should meet the following requirements:
REQ-1: Support the offer of a specific image size on the receiver REQ-1: Support the offer of a specific image size on the receiver
display or in other words, reduce or avoid the need for rescaling display or in other words, reduce or avoid the need for rescaling
images in the receiver to fit a given portion of the screen. images in the receiver to fit a given portion of the screen.
REQ-2: Support asymmetric setups i.e the very likely scenario where REQ-2: Support asymmetric setups i.e the very likely scenario where
skipping to change at page 6, line 27 skipping to change at page 6, line 29
---- ----
set= "[" "x=" range "," "y=" range [",sar="range] set= "[" "x=" range "," "y=" range [",sar="range]
[",par=" range] [",q=" value] "]" [",par=" range] [",q=" value] "]"
x is the horizontal image size range x is the horizontal image size range
y is the vertical image size range y is the vertical image size range
sar (sample aspect ratio) is the sample aspect ratio associated sar (sample aspect ratio) is the sample aspect ratio associated
with the set (optional and MAY be ignored) with the set (optional and MAY be ignored)
par (picture aspect ratio) is the allowed ratios between the par (picture aspect ratio) is the allowed ratios between the
displays x and y physical size (optional) displays x and y physical size (optional)
q (optional with range [0.0..1.0], default value 0.5) q (optional with range [0.0..1.0], default value 0.5)
is the preference for the given set, a higher value means higher is the preference for the given set, a higher value means
preference from the sender point of view higher preference from the sender point of view
range is expressed in a few different formats range is expressed in a few different formats
1) range= value 1) range= value
a single value a single value
2) range= "[" value1 ":" [ step ":" ] value2 "]" 2) range= "[" value1 ":" [ step ":" ] value2 "]"
values between value1 and value2 inclusive, values between value1 and value2 inclusive,
if step is omitted a stepsize of 1 is implied. if step is omitted a stepsize of 1 is implied.
3) range= "[" value 1*( "," value ) "]" 3) range= "[" value 1*( "," value ) "]"
any value from the list of values any value from the list of values
4) range= "[" value1 "-" value2 "]" 4) range= "[" value1 "-" value2 "]"
any real value between value1 and value2 inclusive any real value between value1 and value2 inclusive
value is a positive integer or real value value is a positive integer or real value
step is a positive integer or real value step is a positive integer or real value
If step is left out in the syntax a stepsize of 1 is implied. If step is left out in the syntax a stepsize of 1 is implied.
Note the use of brackets [..] if more that one value specified. Real values are only applicable for the
sar, par and q parameters.
Note the use of brackets [..] if more that one value
is specified.
---- ----
Some further guidelines for the use of the attribute is given below: Some further guidelines for the use of the attribute is given below:
o The image attribute is bound to a specific media by means of the o The image attribute is bound to a specific media by means of the
payload type number. A wild card (*) can be specified for the payload type number. A wild card (*) can be specified for the
payload type number to indicate that it applies to all payload payload type number to indicate that it applies to all payload
types in the media description. Several image attributes can be types in the media description. Several image attributes can be
defined e.g for different video codec alternatives conditioned defined e.g for different video codec alternatives conditioned
that the payload type number differs. that the payload type number differs.
o The preference for each set is 0.5 by default, setting the o The preference for each set is 0.5 by default, setting the
skipping to change at page 7, line 16 skipping to change at page 7, line 22
o The preference for each set is 0.5 by default, setting the o The preference for each set is 0.5 by default, setting the
optional q parameter to another value makes it possible to set optional q parameter to another value makes it possible to set
different preferences for the sets. A higher value gives a higher different preferences for the sets. A higher value gives a higher
preference for the given set. preference for the given set.
o The sar parameter specifies the sample aspect ratio associated to o The sar parameter specifies the sample aspect ratio associated to
the given range of x and y values. The sar parameter is defined the given range of x and y values. The sar parameter is defined
as dx/dy where dx and dy is the size of the pixels. Square pixels as dx/dy where dx and dy is the size of the pixels. Square pixels
gives a sar=1.0. The parameter sar MAY be expressed as a range. gives a sar=1.0. The parameter sar MAY be expressed as a range.
If this parameter is not present a default sar value of 1.0 is
assumed.
The interpretation of sar differs between the send and the receive The interpretation of sar differs between the send and the receive
directions. directions.
* In the send direction it defines a specific sample aspect * In the send direction it defines a specific sample aspect ratio
ration associated to a given x and y image size (range). associated to a given x and y image size (range).
* In the recv direction sar expresses that the receiver of the * In the recv direction sar expresses that the receiver of the
given media prefers to receive a given x and y resolution with given media prefers to receive a given x and y resolution with
a given sample aspect ratio. a given sample aspect ratio.
See Section 3.3.4 for a more detailed discussion. See Section 3.3.4 for a more detailed discussion.
o The par (width/height = x/y ratio) parameter indicates a range of o The par (width/height = x/y ratio) parameter indicates a range of
allowed ratios between x and y physical size (picture aspect allowed ratios between x and y physical size (picture aspect
ratio). This is used to limit the number of x and y image size ratio). This is used to limit the number of x and y image size
combinations, par is given as combinations, par is given as
---- ----
par=[ratio_min-ratio_max] par=[ratio_min-ratio_max]
---- ----
Where ratio_min and ratio_max are the min and max allowed picture Where ratio_min and ratio_max are the min and max allowed picture
aspect ratios. aspect ratios.
If sar and the display sample aspect ration is the same (or close) If sar and the display sample aspect ratio is the same (or close)
the relation between the x and y pixel resolution and the physical the relation between the x and y pixel resolution and the physical
size of the image is straightforward. If however sar differs from size of the image is straightforward. If however sar differs from
the sample aspect ratio of the receiver display this must be taken the sample aspect ratio of the receiver display this must be taken
into consideration when the x and y pixel resolution alternatives into consideration when the x and y pixel resolution alternatives
are sorted out. are sorted out.
o The offerer MUST be able to support the image attributes that it o The offerer MUST be able to support the image attributes that it
offers. offers.
o The answerer MAY choose to keep imageattr but is not required to o The answerer MAY choose to keep imageattr but is not required to
do so. If the attribute is kept in the SDP answer, the answerer do so. If the attribute is kept in the SDP answer:
MUST for its receive direction only include one or more valid
entries taken from the offer. The answer for the answerers send
direction MAY be modified.
o The answerer MUST for its receive direction only pick one or more * The answerer MUST for its receive direction only include one or
valid entries from the multidimensional solution space spanned by more valid entries taken from the offer. In other words, the
the offer. answerer MUST for its receive direction only pick one or more
valid entries from the multidimensional solution space spanned
by the offer.
* The answerer MAY for its send direction modify the attribute in
the sense that new entries other than those presented in the
offer are added. It must however be noted that this may lead
to an extra offer/answer exchange of the added parameters are
not supported by the offerer.
3.2.2. Syntax description 3.2.2. Syntax description
In the description of the syntax we here assume that Alice wish to In the description of the syntax we here assume that Alice wish to
setup a session with Bob and that Alice takes the first initiative. setup a session with Bob and that Alice takes the first initiative.
The syntactical white-space delimiters (1*WSP) and double-quotes are The syntactical white-space delimiters (1*WSP) and double-quotes are
removed to make reading easier. removed to make reading easier.
In the offer Alice provides with information for both the send and In the offer Alice provides with information for both the send and
receive (recv) directions using syntax version 1. For the send receive (recv) directions using syntax version 1. For the send
skipping to change at page 11, line 5 skipping to change at page 11, line 21
would need to be performed on the receiver side, something that is would need to be performed on the receiver side, something that is
contrary to the spirit of this draft. contrary to the spirit of this draft.
To avoid this problem Alice MAY specify a range of values for the sar To avoid this problem Alice MAY specify a range of values for the sar
parameter like: parameter like:
---- ----
a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] a=imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
---- ----
Meaning that Alice can encode with any of the mentioned sample aspect Meaning that Alice can encode with any of the mentioned sample aspect
ratios, leaving to Bob to decide which one he prefers. ratios, leaving to Bob to decide which one he prefers.
The response MUST not include the sar parameter if there is no The response MUST NOT include the sar parameter if there is no
acceptable value given. acceptable value given.
3.3.5. SDPCapNeg support 3.3.5. SDPCapNeg support
The image attribute can be used within the SDP Capability Negotiation The image attribute can be used within the SDP Capability Negotiation
[SDPCapNeg] framework and its use is then specified using the [SDPCapNeg] framework and its use is then specified using the
"a=acap" parameter. An example is "a=acap" parameter. An example is
---- ----
a=acap:1 imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]] a=acap:1 imageattr:97 send [x=720,y=576,sar=[0.91,1.0,1.09,1.45]]
---- ----
skipping to change at page 13, line 27 skipping to change at page 13, line 42
3.3.7. Change of display in middle of session 3.3.7. Change of display in middle of session
A very likely scenario is that a user switches to another phone A very likely scenario is that a user switches to another phone
during e.g a video telephony call or plugs the cellphone into an during e.g a video telephony call or plugs the cellphone into an
external monitor. In both cases it is very likely that a external monitor. In both cases it is very likely that a
renegotiation is initiated using e.g the SIP-REFER or SIP-UPDATE renegotiation is initiated using e.g the SIP-REFER or SIP-UPDATE
methods. It is RECOMMENDED to negotiate the image size during this methods. It is RECOMMENDED to negotiate the image size during this
renegotiation. renegotiation.
3.3.8. Addition of parameters
The image attribute opens up for the addition of parameters in the
future. To make backwards adaptation possible; an entity that
process the attribute MUST remove parameters that are not recognized
before returning the attribute in the SDP answer. Addition of future
parameters that are not understood by the receiving endpoint may lead
to ambiguities if mutual dependencies between parameters exist,
therefore addition of parameters must be done with great care.
4. Examples 4. Examples
A few examples to highlight the syntax, here is assumed where needed A few examples to highlight the syntax, here is assumed where needed
that Alice initiates a session with Bob that Alice initiates a session with Bob
4.1. Example 1 4.1. Example 1
---- ----
a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \ a=imageattr:97 send [x=800,y=640,sar=1.1,q=0.6] [x=480,y=320] \
recv [x=330,y=250] recv [x=330,y=250]
---- ----
skipping to change at page 15, line 48 skipping to change at page 16, line 22
5. Issues 5. Issues
Here is listed a few possible issues and observations connected to Here is listed a few possible issues and observations connected to
the use of the image attribute : the use of the image attribute :
o An SDP answer MAY modify the image attribute for the answerers o An SDP answer MAY modify the image attribute for the answerers
send direction. Can this cause trouble ? send direction. Can this cause trouble ?
6. IANA Considerations 6. IANA Considerations
T.B.D Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute:
o Contact name, email address and telephone number: Authors of
RFCXXXX
o Attribute-name: imageattr
o Long-form attribute name: Image attribute
o Type of attribute: media-level
o Subject to charset: no
This attribute defines the ability to negotiate various image
attributes such as image sizes. The attribute contains a number of
parameters which can be modified in and offer/answer exchange.
Note to RFC Editor: please replace "RFC XXXX" above with the RFC
number of this memo, and remove this note.
7. Security Considerations 7. Security Considerations
This draft does not add any additional security issues other than This draft does not add any additional security issues other than
those already existing with currently specified offer/answer those already existing with currently specified offer/answer
procedures. procedures.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank the people who has contributed with The authors would like to thank the people who has contributed with
objections and suggestions to this draft and provided with valuable objections and suggestions to this draft and provided with valuable
guidance in the amazing video-coding world. Special thanks go to guidance in the amazing video-coding world. Special thanks go to
Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing. Clinton Priddle, Roni Even, Randell Jesup, and Dan Wing.
9. Changes 9. Changes
The main changes are: The main changes are:
From WG -00 to WG -01
* Added info about future addition of parameters and backwards
compatibility
* Added IANA considerations
From individual -02 to WG -00 From individual -02 to WG -00
* Cleanup of syntax, ABNF form * Cleanup of syntax, ABNF form
* Additional example * Additional example
From -01 to -02 From -01 to -02
* Cleanup of the sar and par parameters to make them match the * Cleanup of the sar and par parameters to make them match the
established conventions established conventions
 End of changes. 22 change blocks. 
53 lines changed or deleted 99 lines changed or added

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