draft-ietf-sipping-sip-offeranswer-02.txt   draft-ietf-sipping-sip-offeranswer-03.txt 
SIPPING Working Group T. Sawada SIPPING Working Group T. Sawada
Internet Draft KDDI Corporation Internet Draft KDDI Corporation
Expires: January 2008 P. Kyzivat Expires: February 2008 P. Kyzivat
Cisco Systems, Inc. Cisco Systems, Inc.
July 9, 2007 August 28, 2007
SIP (Session Initiation Protocol) Usage of Offer/Answer Model SIP (Session Initiation Protocol) Usage of Offer/Answer Model
draft-ietf-sipping-sip-offeranswer-02.txt draft-ietf-sipping-sip-offeranswer-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 November 9, 2007. This Internet-Draft will expire on November 28, 2007.
Abstract Abstract
SIP utilizes offer/answer model to establish and update multimedia SIP utilizes offer/answer model to establish and update multimedia
sessions. The descriptions on how to use offer/answer in SIP are sessions. The descriptions on how to use offer/answer in SIP are
dispersed in the multiple RFCs. This document summarizes all the dispersed in the multiple RFCs. This document summarizes all the
current usage of offer/answer model in SIP communication. current usage of offer/answer model in SIP communication.
Table of Contents Table of Contents
1. Summary of SIP usage of Offer/Answer Model................2 1. Summary of SIP usage of Offer/Answer Model...................2
1.1. Offer/Answer Exchange Pairs in SIP Messages...........3 1.1. Offer/Answer Exchange Pairs in SIP Messages.............3
1.2. Rejection against an Offer.........................4 1.2. Rejection against an Offer..............................4
1.3. Session Description which is not Offer nor Answer.......5 1.3. Session Description which is not Offer nor Answer.......5
2. Detailed Discussion on Offer/Answer Model for SIP...........5 2. Detailed Discussion on Offer/Answer Model for SIP............5
2.1. Offer/Answer for INVITE method with 100rel extension....5 2.1. Offer/Answer for INVITE method with 100rel extension....5
2.1.1. INVITE Request with SDP.......................6 2.1.1. INVITE Request with SDP............................6
2.1.2. INVITE request without SDP.....................8 2.1.2. INVITE request without SDP.........................8
2.2. Offer/Answer Exchange in Early Dialog................9 2.2. Offer/Answer Exchange in Early Dialog...................9
2.3. Offer/Answer Exchange in Established Dialog...........9 2.3. Offer/Answer Exchange in Established Dialog.............9
3. Exceptional Case Handling.............................10 3. Exceptional Case Handling...................................10
3.1. Message Crossing Case Handling.....................10 3.1. Message Crossing Case Handling.........................10
3.2. Glare Case Handling..............................11 3.2. Glare Case Handling....................................11
4. Content of Offers and Answers..........................12 4. Content of Offers and Answers...............................12
4.1. General Principle for Constructing Offers and Answers..12 4.1. General Principle for Constructing Offers and Answers..12
4.2. Choice of Media Types and Formats to Include and Exclude13 4.2. Choice of Media Types and Formats to Include and Exclude13
4.2.1. Sending Initial INVITE with Offer..............13 4.2.1. Sending Initial INVITE with Offer.................13
4.2.2. Responding with Offer when Initial INVITE has no Offer13 4.2.2. Responding with Offer when Initial INVITE has no
4.2.3. Answering Initial INVITE with Offer.............14 Offer....................................................13
4.2.4. Answering when Initial INVITE had no Offer.......14 4.2.3. Answering Initial INVITE with Offer...............14
4.2.5. Subsequent Offers and Answers..................14 4.2.4. Answering when Initial INVITE had no Offer........14
4.3. Hold and Resume of media..........................15 4.2.5. Subsequent Offers and Answers.....................14
5. Remaining Issues or Best Practices on Offer/Answer.........16 4.3. Hold and Resume of media...............................15
5.1. Rejecting PRACK Offer............................16 5. Remaining Issues or Best Practices on Offer/Answer..........16
5.1. Rejecting PRACK Offer..................................17
5.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 5.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction........................................17 Transaction.................................................17
6. Add New Offer/Answer Usage in SIP......................18 5.3. Offer in a Reliable Response...........................19
6.1. Explicit Usage..................................18 6. Add New Offer/Answer Usage in SIP...........................19
6.2. Rejection of an Offer............................19 6.1. Explicit Usage.........................................19
6.3. Backward Compatibility...........................19 6.2. Rejection of an Offer..................................19
6.4. Exceptional Case Handling.........................19 6.3. Backward Compatibility.................................20
7. Security Considerations..............................19 6.4. Exceptional Case Handling..............................20
8. References.........................................19 7. Security Considerations.....................................20
8.1. Normative References.............................19 8. References..................................................20
8.2. Informative References...........................19 8.1. Normative References...................................20
Author's Addresses.....................................20 8.2. Informative References.................................20
Full Copyright Statement................................20 Author's Addresses.............................................21
Intellectual Property Statement..........................20 Full Copyright Statement.......................................21
Acknowledgment........................................21 Intellectual Property Statement................................21
Acknowledgment.................................................22
1. Summary of SIP usage of Offer/Answer Model 1. Summary of SIP usage of Offer/Answer Model
The offer/answer model itself is independent from the higher layer The offer/answer model itself is independent from the higher layer
application protocols which utilize it. SIP is one of the application protocols which utilize it. SIP is one of the
applications using offer/answer model. RFC 3264 [3] defines the applications using offer/answer model. RFC 3264 [3] defines the
offer/answer model, but does not specify which SIP message should offer/answer model, but does not specify which SIP message should
convey an offer or an answer. This should be defined in the SIP core convey an offer or an answer. This should be defined in the SIP core
and extensions RFCs. and extensions RFCs.
skipping to change at page 3, line 39 skipping to change at page 3, line 39
not include an offer. 'The first reliable non-failure message' must not include an offer. 'The first reliable non-failure message' must
have an offer if there is no offer in the INVITE request. This means have an offer if there is no offer in the INVITE request. This means
that UA which receives the INVITE request without an offer must that UA which receives the INVITE request without an offer must
include an offer in the first reliable response with 100rel extension. include an offer in the first reliable response with 100rel extension.
If no reliable provisional response has been sent, the UAS must If no reliable provisional response has been sent, the UAS must
include an offer when sending 2xx response. include an offer when sending 2xx response.
In pattern 3, the first reliable provisional response may or may not In pattern 3, the first reliable provisional response may or may not
have an answer. When a reliable provisional response contains a have an answer. When a reliable provisional response contains a
session description, and is the first to do so, then that session session description, and is the first to do so, then that session
description is the answer to the offer in the INVITE request. description is the answer to the offer in the INVITE request. The
answer can not be updated, and a new offer can not be sent, in a
subsequent reliable response for the same INVITE transaction.
In pattern 5, a PRACK request can contain an offer only if the In pattern 5, a PRACK request can contain an offer only if the
reliable response which it acknowledges contains an answer in the reliable response which it acknowledges contains an answer in the
previous offer/answer exchange. previous offer/answer exchange.
Offer Answer RFC Ini Est Early Offer Answer RFC Ini Est Early
------------------------------------------------------------------- -------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 O O X 1. INVITE Req. 2xx INVITE Resp. RFC 3261 O O X
2. 2xx INVITE Resp. ACK Req. RFC 3261 O O X 2. 2xx INVITE Resp. ACK Req. RFC 3261 O O X
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 O O X 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 O O X
skipping to change at page 4, line 40 skipping to change at page 4, line 40
1.2. Rejection against an Offer 1.2. Rejection against an Offer
How to reject an offer when it can not be accepted is not so clear How to reject an offer when it can not be accepted is not so clear
and some methods can not allow explicit rejection against an offer. and some methods can not allow explicit rejection against an offer.
Corresponding to the patterns in Table 1, how to reject an offer is Corresponding to the patterns in Table 1, how to reject an offer is
shown in Table 2. shown in Table 2.
When a UA receives an INVITE request with an unacceptable offer, it When a UA receives an INVITE request with an unacceptable offer, it
should respond with a 488 response, preferably with Warning header should respond with a 488 response, preferably with Warning header
field indicating the reason of the rejection unless another response field indicating the reason of the rejection, unless another response
code is more appropriate to reject it. (Pattern 1 and Pattern 3) code is more appropriate to reject it. (Pattern 1 and Pattern 3)
When a UA receives an UPDATE request with an offer which it can not When a UA receives an UPDATE request with an offer which it can not
accept, it should respond with a 488 response preferably with Warning accept, it should respond with a 488 response preferably with Warning
header field indicating the reason of the rejection, unless another header field indicating the reason of the rejection, unless another
response code is more appropriate to reject it. (Pattern 6) response code is more appropriate to reject it. (Pattern 6)
When a UA receives a PRACK request with an offer which it can not When a UA receives a PRACK request with an offer which it can not
accept, it may respond with a 200 response with a syntactically accept, it may respond with a 200 response with a syntactically
correct session description followed by an UPDATE request possibly to correct session description followed by an UPDATE request possibly to
rearrange the session parameters if both ends support UPDATE method. rearrange the session parameters if both ends support UPDATE method,
or alternatively terminate the dialog and send an error response to
A UA may simply give up continuing the dialog and send an error the INVITE request. (Pattern 5)
response to the INVITE request. (Pattern 5)
When a UA receives a response with an offer which it can not accept, When a UA receives a response with an offer which it can not accept,
a UA does not have a way to reject it explicitly. Therefore, a UA a UA does not have a way to reject it explicitly. Therefore, a UA
should respond to the offer with the correct session description and should respond to the offer with the correct session description and
rearrange the session parameters by initiating a new offer/answer rearrange the session parameters by initiating a new offer/answer
exchange, or just terminate the session. (Pattern 2 and Pattern 4) exchange, or alternatively terminate the session. (Pattern 2 and
When initiating a new offer/answer, a UA should take care not to Pattern 4) When initiating a new offer/answer, a UA should take care
cause a never-ending offer/answer loop. not to cause a never-ending offer/answer loop.
Offer Rejection Offer Rejection
----------------------------------------------------- -----------------------------------------------------
1. INVITE Req. 488 INVITE Response 1. INVITE Req. 488 INVITE Response
2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer
OR termination of dialog
3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 3. INVITE Req. 488 INVITE Response (same as Pattern 1.)
4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer
5. PRACK Req. (*) 200 PRACK Resp. followed by new offer 5. PRACK Req. (*) 200 PRACK Resp. followed by new offer
OR termination of dialog
6. UPDATE Req. 488 UPDATE Response 6. UPDATE Req. 488 UPDATE Response
Table 2. Rejection against an Offer Table 2. Rejection against an Offer
(*) UA should only use PRACK to send an offer when it has strong (*) UA should only use PRACK to send an offer when it has strong
reasons to assume the receiver will accept. reasons to assume the receiver will accept.
1.3. Session Description which is not Offer nor Answer 1.3. Session Description which is not Offer nor Answer
As previously stated, a session description in a SIP message is not As previously stated, a session description in a SIP message is not
skipping to change at page 12, line 45 skipping to change at page 12, line 45
- the negotiation of secure media streams - the negotiation of secure media streams
- grouping of media streams - grouping of media streams
- preconditions - preconditions
4.1. General Principle for Constructing Offers and Answers 4.1. General Principle for Constructing Offers and Answers
A UA should send an offer that indicates what it, and its user, are A UA should send an offer that indicates what it, and its user, are
interested in using/doing at that time, without regard for what the interested in using/doing at that time, without regard for what the
other party in the call may have indicated previously. other party in the call may have indicated previously. This is the
case even when the offer is sent in response to an INVITE or re-
INVITE that contains no offer. (However in the case of re-INVITE the
constraints of RFCs 3261 and 3264 must be observed.)
A UA should send an answer that includes as close an approximation to A UA should send an answer that includes as close an approximation to
what the UA and its user are interested in doing at that time, while what the UA and its user are interested in doing at that time, while
remaining consistent with the offer/answer rules of RFC 3264[3] and remaining consistent with the offer/answer rules of RFC 3264[3] and
other RFCs. other RFCs.
NOTE: "at that time" is important. The device may permit the NOTE: "at that time" is important. The device may permit the
user to configure which supported media are to be used by user to configure which supported media are to be used by
default. default.
skipping to change at page 14, line 41 skipping to change at page 14, line 44
corresponding media line, by setting the port number to zero. corresponding media line, by setting the port number to zero.
4.2.4. Answering when Initial INVITE had no Offer 4.2.4. Answering when Initial INVITE had no Offer
When a UAC has sent an initial INVITE without an offer, and then When a UAC has sent an initial INVITE without an offer, and then
receives a response with the first offer, it should answer in the receives a response with the first offer, it should answer in the
same way as a UAS receiving an initial INVITE with an offer. same way as a UAS receiving an initial INVITE with an offer.
4.2.5. Subsequent Offers and Answers 4.2.5. Subsequent Offers and Answers
The guidelines above (sections 4.1. and 4.2.1. through 4.2.5. ) apply, The guidelines above (sections 4.1. and 4.2.1. through 4.2.4. ) apply,
but constraints in RFC 3264 [3] must also be followed. The following but constraints in RFC 3264 [3] must also be followed. The following
are of particular note because they have proven troublesome: are of particular note because they have proven troublesome:
o The number of m-lines may not be reduced in a subsequent offer. o The number of m-lines may not be reduced in a subsequent offer.
Previously rejected media streams must remain, or be reused to Previously rejected media streams must remain, or be reused to
offer the same or a different stream. offer the same or a different stream.
o In the o-line, only the version number may change, and if it o In the o-line, only the version number may change, and if it
changes it must increment by one from the one previously sent as changes it must increment by one from the one previously sent as
an offer or answer. If it doesn't change then the entire SDP body an offer or answer. If it doesn't change then the entire SDP body
must be identical to what was previously sent as an offer or must be identical to what was previously sent as an offer or
answer. answer. Changing the o-line, except version number value, during
the session is an error case. The behavior when receiving such a
non-compliant offer/answer SDP is implementation dependent. If a
UA needs to negotiate a 'new' SDP session, it should use the
INVITE/Replaces method.
o In the case of RTP, the mapping from a particular dynamic payload o In the case of RTP, the mapping from a particular dynamic payload
type number to a particular codec within that media stream (m- type number to a particular codec within that media stream (m-
line) MUST NOT change for the duration of the session. line) MUST NOT change for the duration of the session.
NOTE: This may be impossible for a B2BUA to follow in some cases NOTE: This may be impossible for a B2BUA to follow in some cases
(e.g. 3pcc transfer) if it does not terminate media. (e.g. 3pcc transfer) if it does not terminate media.
4.3. Hold and Resume of media 4.3. Hold and Resume of media
skipping to change at page 16, line 23 skipping to change at page 16, line 28
"a=sendrecv". In this case, because UA1 has the same desire it will "a=sendrecv". In this case, because UA1 has the same desire it will
respond "a=sendrecv". respond "a=sendrecv".
If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive",
and subsequently wants to initiate its own hold, also using and subsequently wants to initiate its own hold, also using
"a=inactive", it need not send a new offer, since the only valid "a=inactive", it need not send a new offer, since the only valid
response is "a=inactive" and that is already in effect. However, its response is "a=inactive" and that is already in effect. However, its
local desired state will now be either "inactive". This affects what local desired state will now be either "inactive". This affects what
it will send in future offers and answers. it will send in future offers and answers.
If a UA has occasion to send another offer in the session, without
any desire to change the hold status (e.g. in response to a re-INVITE
without an offer, or when sending a re-INVITE to refresh the session
timer) it should follow the General Principle for Constructing Offers
and Answers (section 4.1. ) If it previously initiated a "hold" by
sending "a=sendonly" or "a=inactive" then it should offer that again.
If it had not previously initiated "hold" then it should offer
"a=sendrecv", even if it had previously been forced to answer
something else. Without this behavior it is possible to get "stuck on
hold" in some cases, especially when a third-party call controller is
involved.
5. Remaining Issues or Best Practices on Offer/Answer 5. Remaining Issues or Best Practices on Offer/Answer
This document clarifies the offer/answer usage in SIP and summarizes This document clarifies the offer/answer usage in SIP and summarizes
the correct or recommended behaviors along with the existing RFCs. To the correct or recommended behaviors along with the existing RFCs. To
create any new normative behaviors beyond these RFCs is not the create any new normative behaviors beyond these RFCs is not the
intent of this document. intent of this document.
However, through the scrutiny of the offer/answer model in SIP, some However, through the scrutiny of the offer/answer model in SIP, some
issues are found to be unresolved within the current set of RFCs. issues are found to be unresolved within the current set of RFCs.
Those remaining issues are described in this section mainly for Those remaining issues are described in this section mainly for
skipping to change at page 16, line 44 skipping to change at page 17, line 14
5.1. Rejecting PRACK Offer 5.1. Rejecting PRACK Offer
As stated in section 1.2. and 2.2. , it is recommended not to send an As stated in section 1.2. and 2.2. , it is recommended not to send an
offer in a PRACK request unless UAC has strong reasons to assume the offer in a PRACK request unless UAC has strong reasons to assume the
receiver will accept it. Even so, there may be the cases when the UAS receiver will accept it. Even so, there may be the cases when the UAS
has to reject the offer for some reason. The current RFCs do not has to reject the offer for some reason. The current RFCs do not
provide the way to reject the offer and at the same time to provide the way to reject the offer and at the same time to
acknowledge the reliable response. acknowledge the reliable response.
Several candidates were proposed to resolve this issue, such as Several ideas were presented to resolve this issue, such as sending
sending 2xx PRACK response without SDP to reject the offer. Some of 2xx PRACK response without SDP to reject the offer, or sending an SDP
the candidates may also be adapted as a way to reject an unacceptable with decreased o-line version value. Some of the candidates may also
offer in a response. Anyway, those candidates violate the current be adapted as a way to reject an unacceptable offer in a response.
rules and lose backward compatibility to some extent. It is beyond Anyway, those candidates violate the current rules and lose backward
the scope of this document and remains for further study. compatibility to some extent (e.g. section 5 of RFC 3262). It is
beyond the scope of this document and remains for further study.
NOTE: Deprecation of the usage of offer in PRACK may be another
solution. As the precondition mechanism specification [2]
explicitly shows a usage of sending offer in PRACK, its
deprecation could cause backward compatibility issues.
5.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 5.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction Transaction
When a re-INVITE transaction fails, often the dialog remains with the When a re-INVITE transaction fails, often the dialog remains with the
session bound to it. The issue here is what the session status is if session bound to it. The issue here is what the session status is if
offer/answer exchange has been completed before the re-INVITE offer/answer exchange has been completed (if a session description
transaction fails with the final failure response (Figure 5). One has been sent in a reliable provisional response to the re-INVITE
request), or if subsequent offer/answer exchanges have taken place
(using UPDATE or PRACK transactions), before the re-INVITE
transaction is terminated with a final error response (Figure 5). One
option is to take those offer/answer exchanges not committed yet and option is to take those offer/answer exchanges not committed yet and
to make the session status rollback to the one before re-INVITE to make the session status rollback to the one before re-INVITE
transaction was initiated. Another option is to take those exchanges transaction was initiated. Another option is to take those exchanges
committed and to keep the session status as it is even after re- committed and to keep the session status as it is even after re-
INVITE fails. There is no clear consensus on which one is the correct INVITE fails. There is no clear consensus on which one is the correct
behavior. behavior.
There are some cases where it is useful to exchange There are some cases where it is useful to exchange
offer(s)/answer(s) even before re-INVITE completes. The case of offer(s)/answer(s) even before re-INVITE completes. The case of
adding a new media (like adding video to audio only session) which adding a new media (like adding video to audio only session) which
skipping to change at page 18, line 13 skipping to change at page 18, line 41
the failure response is sent hop-by-hop basis, therefore even after the failure response is sent hop-by-hop basis, therefore even after
receiving the ACK request, UAS can not make sure that UPDATE request receiving the ACK request, UAS can not make sure that UPDATE request
was sent after the final response had been reached to the other end. was sent after the final response had been reached to the other end.
Sending a new UPDATE request from UAC to synchronize the status Sending a new UPDATE request from UAC to synchronize the status
anytime after the re-INVITE fails may be a good option. This solution, anytime after the re-INVITE fails may be a good option. This solution,
however, requires that the UPDATE method be supported by both ends however, requires that the UPDATE method be supported by both ends
and needs care to avoid flapping when each end tries to advertise and needs care to avoid flapping when each end tries to advertise
their different views of the session status. their different views of the session status.
To resolve this issue may be beyond the scope of this document and The proper handling of this issue is undefined by existing standards.
require another normative document which is for further study. Resolution is beyond the scope of this document, and will require a
new normative document. Such a document is the responsibility of the
SIP working group, and is for further study.
UAC UAS UAC UAS
| session established | | session established |
|<===================>| |<===================>|
| | | |
| F1 re-INVITE (SDP) | | F1 re-INVITE (SDP) |
|-------------------->| |-------------------->|
| F2 1xx-rel (SDP) | | F2 1xx-rel (SDP) |
|<--------------------| |<--------------------|
| F3 PRACK | | F3 PRACK |
skipping to change at page 18, line 38 skipping to change at page 19, line 27
| | | |
|UPDATE(SDP) 4xx INV | |UPDATE(SDP) 4xx INV |
|---------\ /--------| |---------\ /--------|
| \/ | | \/ |
| /\ | | /\ |
|<--------/ \------->| |<--------/ \------->|
| | | |
Figure 6 Commit/Rollback Issue with Race Condition Figure 6 Commit/Rollback Issue with Race Condition
5.3. Offer in a Reliable Response
In RFC 3261, it is stated that when an INVITE is sent without an
offer, the first reliable response MUST contain an offer. There was
discussion on whether this rule can be loosened up. There is no clear
explanation why this restriction is defined. However, this rule will
be left as it is, unless the strong necessity to loose it up will
come up in the future.
6. Add New Offer/Answer Usage in SIP 6. Add New Offer/Answer Usage in SIP
It is not recommended to add new SIP methods for the offer/answer It is not recommended to add new SIP methods for the offer/answer
exchange beyond the ways described in this document. However, it may exchange beyond the ways described in this document. However, it may
be requested to have new offer/answer exchange methods as SIP be requested to have new offer/answer exchange methods as SIP
extensions evolve. In this clause, what should be taken into extensions evolve. In this clause, what should be taken into
considerations is noted. considerations is noted.
6.1. Explicit Usage 6.1. Explicit Usage
 End of changes. 23 change blocks. 
60 lines changed or deleted 104 lines changed or added

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