draft-ietf-rohc-rtp-impl-guide-16.txt   draft-ietf-rohc-rtp-impl-guide-17.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT K. Sandlund INTERNET-DRAFT K. Sandlund
Expires: May 2006 G. Pelletier Expires: July 2006 G. Pelletier
P. Kremer P. Kremer
Ericsson Ericsson
November 23, 2005 January 23, 2006
The RFC 3095 Implementer's Guide The RFC 3095 Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-16.txt> <draft-ietf-rohc-rtp-impl-guide-17.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, each author accepts the provisions By submitting this Internet-Draft, each author accepts the provisions
of Section 3 of BCP 78. of Section 3 of BCP 78.
skipping to change at page 2, line 55 skipping to change at page 2, line 55
8. Other protocol clarifications...................................15 8. Other protocol clarifications...................................15
8.1. Meaning of NBO.............................................15 8.1. Meaning of NBO.............................................15
8.2. IP-ID......................................................15 8.2. IP-ID......................................................15
8.3. Extension-3 in UO-1-ID packets.............................16 8.3. Extension-3 in UO-1-ID packets.............................16
8.4. Extension-3 in UOR-2* packets..............................16 8.4. Extension-3 in UOR-2* packets..............................16
8.5. Multiple SN options in one feedback packet.................16 8.5. Multiple SN options in one feedback packet.................16
8.6. Multiple CRC options in one feedback packet................17 8.6. Multiple CRC options in one feedback packet................17
8.7. Packet decoding during mode transition.....................17 8.7. Packet decoding during mode transition.....................17
8.8. How to respond to lost feedback links?.....................17 8.8. How to respond to lost feedback links?.....................17
8.9. What does "presumed zero if absent" mean on page 88?.......18 8.9. What does "presumed zero if absent" mean on page 88?.......18
8.10. UOR-2 in profile 2 (UDP)..................................18 8.10. UOR-2 in profile 2 (UDP) and profile 3 (ESP)..............18
8.11. Sequence number LSB's in IP extension headers.............18 8.11. Sequence number LSB's in IP extension headers.............18
8.12. Expecting UOR-2 ACKs in O-mode............................18 8.12. Expecting UOR-2 ACKs in O-mode............................18
8.13. Compression of SN in AH and GRE extension headers.........19 8.13. Compression of SN in AH and GRE extension headers.........19
9. ROHC negotiation clarifications.................................19 9. ROHC negotiation clarifications.................................19
10. PROFILES suboption in ROHC-over-PPP............................20 10. PROFILES suboption in ROHC-over-PPP............................20
11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20
12. Security considerations........................................20 12. Security considerations........................................20
13. IANA considerations............................................20 13. IANA considerations............................................20
14. Acknowledgment.................................................20 14. Acknowledgment.................................................20
15. References.....................................................21 15. References.....................................................21
skipping to change at page 4, line 6 skipping to change at page 4, line 6
bit errors. CRC is used in the segmentation protocol and in the bit errors. CRC is used in the segmentation protocol and in the
compressed packets, as well. compressed packets, as well.
Section 5.2.5.2 describes the segmentation protocol and refers to Section 5.2.5.2 describes the segmentation protocol and refers to
[3], which describes a well-defined CRC algorithm for 32 bit [3], which describes a well-defined CRC algorithm for 32 bit
checksums. Although, Section 5.9 only defines the polynomials for 3, checksums. Although, Section 5.9 only defines the polynomials for 3,
7 and 8-bit long checksum, the same algorithm can be used in these 7 and 8-bit long checksum, the same algorithm can be used in these
cases as well. cases as well.
A PERL implementation of the algorithm (written by Carsten Bormann) A PERL implementation of the algorithm (written by Carsten Bormann)
can be found in Appendix A. can be found in Appendix A of this document.
2.2. Padding octet in CRC 2.2. Padding octet in CRC
According to Section 5.9.1, in case of IR and IR-DYN packets the CRC According to Section 5.9.1, in case of IR and IR-DYN packets the CRC
"is calculated over the entire IR or IR-DYN packet, excluding Payload "is calculated over the entire IR or IR-DYN packet, excluding Payload
and including CID or Add-CID octet". Padding isn't meant to be and including CID or Add-CID octet". Padding isn't meant to be
meaningful part of a packet and not included in CRC calculation. As meaningful part of a packet and not included in CRC calculation. As
a result, CRC doesn't cover the Add-CID octet for CID 0, either. a result, CRC doesn't cover the Add-CID octet for CID 0, either.
2.3. CRC coverage in CRC feedback options 2.3. CRC coverage in CRC feedback options
skipping to change at page 4, line 45 skipping to change at page 4, line 45
3. Enhanced mode transition procedures 3. Enhanced mode transition procedures
To reduce transmission overhead and computational complexity To reduce transmission overhead and computational complexity
(including CRC calculation) associated with feedback packets sent for (including CRC calculation) associated with feedback packets sent for
each decompressed packet during mode transition, a decompressor can each decompressed packet during mode transition, a decompressor can
be implemented with slightly modified mode transition procedures, be implemented with slightly modified mode transition procedures,
compared to those defined in [1]. compared to those defined in [1].
These modifications affect transitions to Optimistic and These modifications affect transitions to Optimistic and
Unidirectional modes of operation, i.e. the transitions described in Unidirectional modes of operation, i.e. the transitions described in
sections 5.6.5 and 5.6.6 of [1], and make those transition diagrams sections 5.6.5 and 5.6.6, and make those transition diagrams more
more consistent with the diagram describing the transition to R-mode. consistent with the diagram describing the transition to R-mode.
However, the differences between the original diagrams of [1] were However, the differences between the original diagrams of [1] were
motivated by robustness concerns for mode transitions to Optimistic motivated by robustness concerns for mode transitions to Optimistic
and Unidirectional modes. To avoid deadlock situations in mode and Unidirectional modes. To avoid deadlock situations in mode
transitions, these aspects must be addressed also when a decompressor transitions, these aspects must be addressed also when a decompressor
implements the enhanced transition procedures, and that is done by implements the enhanced transition procedures, and that is done by
following a slightly modified definition of the decompressor following a slightly modified definition of the decompressor
transition states. All aspects related to implementation of the transition states. All aspects related to implementation of the
enhanced transition procedures are described in subsequent chapters. enhanced transition procedures are described in subsequent chapters.
Note that these modified operations should be seen only as an Note that these modified operations should be seen only as an
skipping to change at page 5, line 26 skipping to change at page 5, line 26
decompressed during the second half of the transition procedure, i.e. decompressed during the second half of the transition procedure, i.e.
after an appropriate IR/IR-DYN/UOR-2 packet has been received from after an appropriate IR/IR-DYN/UOR-2 packet has been received from
the compressor. In the transition diagrams, sections 3.2 and 3.3 the compressor. In the transition diagrams, sections 3.2 and 3.3
below, this is realized by allowing the decompressor transition below, this is realized by allowing the decompressor transition
parameter (D_TRANS) to be set to P (Pending) at that stage. However, parameter (D_TRANS) to be set to P (Pending) at that stage. However,
as mentioned above, there are robustness concerns related to this as mentioned above, there are robustness concerns related to this
optimization, and to avoid deadlock situations with never completed optimization, and to avoid deadlock situations with never completed
transitions as a result of feedback losses, the decompressor must transitions as a result of feedback losses, the decompressor must
continue to send feedback at least periodically, also when in Pending continue to send feedback at least periodically, also when in Pending
transition state. That would be the equivalence of enhancing the transition state. That would be the equivalence of enhancing the
D_TRANS parameter definition in section 5.6.1 of [1], to include a D_TRANS parameter definition in section 5.6.1, to include a
definition of Pending state operation. definition of Pending state operation.
- D_TRANS: - D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED, Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode
transition can be initiated only when D_TRANS is D. While D_TRANS transition can be initiated only when D_TRANS is D. While D_TRANS
is I, the decompressor sends a NACK or ACK carrying a CRC option is I, the decompressor sends a NACK or ACK carrying a CRC option
for each packet received. When D_TRANS is set to P, the for each packet received. When D_TRANS is set to P, the
decompressor do not have to send a NACK or ACK for each packet decompressor do not have to send a NACK or ACK for each packet
received, but it MUST continue to send feedback on a regular received, but it MUST continue to send feedback on a regular
skipping to change at page 14, line 5 skipping to change at page 13, line 53
or IP-ID fields, do not update the context." or IP-ID fields, do not update the context."
However, also sequence number fields of extension headers must be However, also sequence number fields of extension headers must be
updated, which means the updating properties should be rephrased as: updated, which means the updating properties should be rephrased as:
"The only values provided in extensions that update the context are "The only values provided in extensions that update the context are
the additional bits for the SN, TS, or IP-ID fields. Other values the additional bits for the SN, TS, or IP-ID fields. Other values
provided in extensions do not update the context. Note that provided in extensions do not update the context. Note that
sequence number fields of extension headers are also updated." sequence number fields of extension headers are also updated."
See also section 5.4 of this document.
7. Context management and CID/context re-use 7. Context management and CID/context re-use
7.1. The decompressor MUST keep MAX_CID contexts 7.1. The decompressor MUST keep MAX_CID contexts
As part of the negotiated channel parameters, compressor and As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the highest decompressor have through the MAX_CID parameter agreed on the highest
context identification (CID) number to be used. By agreeing on context identification (CID) number to be used. By agreeing on
MAX_CID, the decompressor also agrees to provide memory resources to MAX_CID, the decompressor also agrees to provide memory resources to
host at least MAX_CID+1 contexts, and an established context with a host at least MAX_CID+1 contexts, and an established context with a
CID within this negotiated space MUST be kept by the decompressor CID within this negotiated space MUST be kept by the decompressor
skipping to change at page 15, line 6 skipping to change at page 15, line 6
7.2.1. Re-using a CID/context with the same profile 7.2.1. Re-using a CID/context with the same profile
For multi-mode profiles, such as those defined in RFC 3095 [1], when For multi-mode profiles, such as those defined in RFC 3095 [1], when
a CID/context is re-used for a new context based on the same profile a CID/context is re-used for a new context based on the same profile
as the old context, the current mode of operation MUST be inherited as the old context, the current mode of operation MUST be inherited
from the old to the new context. The reason for this is that there is from the old to the new context. The reason for this is that there is
no reliable way for the compressor to inform the decompressor that a no reliable way for the compressor to inform the decompressor that a
CID/context re-use is happening. The decompressor can thus not be CID/context re-use is happening. The decompressor can thus not be
expected to flush the context memory for the CID, and there is no way expected to flush the context memory for the CID, and there is no way
to trigger a safe mode switching, which requires a decompressor- to trigger a safe mode switching, which requires a decompressor-
initiated handshake procedure, as defined in section 5.6 of [1]. initiated handshake procedure, as defined in section 5.6.
It should be noted that the rule of mode inheritance applies also It should be noted that the rule of mode inheritance applies also
when the CONTEXT_REINITIALIZATION signal is used to reinitiate an when the CONTEXT_REINITIALIZATION signal is used to reinitiate an
entire context. entire context.
7.2.2. Re-using a CID/context with a different profile 7.2.2. Re-using a CID/context with a different profile
When a CID is re-used for a new context based on a different profile When a CID is re-used for a new context based on a different profile
than the old context, operation with that context MUST start in the than the old context, operation with that context MUST start in the
initial mode of the profile (if it is a multi-mode profile). This initial mode of the profile (if it is a multi-mode profile). This
skipping to change at page 16, line 36 skipping to change at page 16, line 36
8.3. Extension-3 in UO-1-ID packets 8.3. Extension-3 in UO-1-ID packets
Extension-3 is applied to give values and indicate changes to fields Extension-3 is applied to give values and indicate changes to fields
other than SN, TS and IP-ID in IP header(s) and RTP header. In case other than SN, TS and IP-ID in IP header(s) and RTP header. In case
of UO-1-ID packets, it should be noted that values provided in of UO-1-ID packets, it should be noted that values provided in
extensions do not update the context, with an exception for SN, TS extensions do not update the context, with an exception for SN, TS
and IP-ID fields, which always update the context (Section 5.7.3.). and IP-ID fields, which always update the context (Section 5.7.3.).
It should also be noted that a UO-1-ID packet with Extension 3 must It should also be noted that a UO-1-ID packet with Extension 3 must
never be sent with RND flags that changes the packet interpretation, never be sent with RND flags that changes the packet interpretation,
i.e. that would violate the base condition for UO-1-ID (at least one i.e. that would violate the base condition for UO-1-ID (at least one
RND value must be 0). RND value must be 0). See also section 5.4 of this document.
Besides, usage of Extension-3 in UO-1-ID can be useful to compress a Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
transient change in a packet stream. For example, if a field's value transient change in a packet stream. For example, if a field's value
changes in the current packet but in the next packet it returns to changes in the current packet but in the next packet it returns to
its regular behavior. E.g. changes in TTL. its regular behavior, e.g. changes in TTL.
8.4. Extension-3 in UOR-2* packets 8.4. Extension-3 in UOR-2* packets
If Extension-3 is used in a UOR-2* packet then the information of the If Extension-3 is used in a UOR-2* packet then the information of the
extension updates the context (Section 5.7.4). Some flags of the IP extension updates the context (Section 5.7.4). Some flags of the IP
header in the extension (e.g. NBO or RND) changes the interpretation header in the extension (e.g. NBO or RND) changes the interpretation
of fields in UOR-2* packets. In these cases, when a flag changes in of fields in UOR-2* packets. In these cases, when a flag changes in
Extension-3, a decompressor should re-parse the UOR-2* packet. Extension-3, a decompressor should re-parse the UOR-2* packet.
8.5. Multiple SN options in one feedback packet 8.5. Multiple SN options in one feedback packet
skipping to change at page 17, line 31 skipping to change at page 17, line 31
Each ROHC profile defines its own set of packet formats, and also its Each ROHC profile defines its own set of packet formats, and also its
own feedback packets. The use of various operational modes is also own feedback packets. The use of various operational modes is also
defined by each specific profile. A decompressor can therefore not defined by each specific profile. A decompressor can therefore not
initiate a mode transfer request before at least one packet of a new initiate a mode transfer request before at least one packet of a new
context has been correctly decompressed, establishing the context context has been correctly decompressed, establishing the context
based on one specific profile (as specified in IR packets). First based on one specific profile (as specified in IR packets). First
then the context has been established, the decompressor knows the then the context has been established, the decompressor knows the
profile used, which modes are defined by that profile, and the profile used, which modes are defined by that profile, and the
feedback packet formats available. feedback packet formats available.
If the transition procedures in sections 5.6.5 and 5.6.6 of [1] are If the original transition procedures in sections 5.6.5 and 5.6.6 are
followed (and not the enhanced procedures described in section 3 of followed (and not the enhanced procedures described in section 3 of
this document), it is important to note that type 0 or type 1 packets this document), it is important to note that type 0 or type 1 packets
may be received by the decompressor during the first half of the may be received by the decompressor during the first half of the
transition procedure, and these packets must not mistakenly be transition procedure, and these packets must not mistakenly be
interpreted as the packets sent by the compressor to indicate interpreted as the packets sent by the compressor to indicate
completed transition. The decompressor side must therefore keep track completed transition. The decompressor side must therefore keep track
of the transition status, e.g. with an additional parameter. If the of the transition status, e.g. with an additional parameter. If the
enhanced transition procedures described in section 3 of this enhanced transition procedures described in section 3 of this
document are used, the D_TRANS parameter can serve this purpose since document are used, the D_TRANS parameter can serve this purpose since
its definition and usage is slightly modified. its definition and usage is slightly modified.
skipping to change at page 18, line 19 skipping to change at page 18, line 19
certain link technologies. certain link technologies.
8.9. What does "presumed zero if absent" mean on page 88? 8.9. What does "presumed zero if absent" mean on page 88?
On page 88, RFC 3095 says that R-P contains the absolute value of RTP On page 88, RFC 3095 says that R-P contains the absolute value of RTP
Padding bit and it's presumed zero if absent. It could be absent Padding bit and it's presumed zero if absent. It could be absent
from RTP header flags and fields, from the extension type 3 or from from RTP header flags and fields, from the extension type 3 or from
the ROHC packet. It's been agreed that the RTP padding bit is the ROHC packet. It's been agreed that the RTP padding bit is
presumed zero if absent from the RTP header flags. presumed zero if absent from the RTP header flags.
8.10. UOR-2 in profile 2 (UDP) 8.10. UOR-2 in profile 2 (UDP) and profile 3 (ESP)
One single new format is defined for UOR-2 in profile 2, which One single new format is defined for UOR-2 in profile 2 and profile
replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile 3, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from
1. The same UOR-2 format is thus used independent of if there are IP profile 1. The same UOR-2 format is thus used independent of if there
headers with a corresponding RND=1 or not. are IP headers with a corresponding RND=1 or not.
8.11. Sequence number LSB's in IP extension headers 8.11. Sequence number LSB's in IP extension headers
In section 5.8.5, formats are defined for compression of IP extension In section 5.8.5, formats are defined for compression of IP extension
header fields. These include compressed sequence number fields, and header fields. These include compressed sequence number fields, and
it is said that these fields contain "LSB of sequence number". This it is said that these fields contain "LSB of sequence number". This
means these sequence numbers are not "LSB-encoded" as e.g. the RTP means these sequence numbers are not "LSB-encoded" as e.g. the RTP
sequence number with an interpretation interval, but are actually sequence number with an interpretation interval, but are actually
just the LSB's of the uncompressed fields. just the LSB's of the uncompressed fields.
skipping to change at page 19, line 21 skipping to change at page 19, line 21
UOR-2 packet, e.g. to send feedback data such as clock resolution, or UOR-2 packet, e.g. to send feedback data such as clock resolution, or
to initiate a mode transfer. Before adapting a compressor to the to initiate a mode transfer. Before adapting a compressor to the
potential use of UOR-2 ACKs, the implementer must ensure all aspects potential use of UOR-2 ACKs, the implementer must ensure all aspects
are considered by the confidence algorithm. are considered by the confidence algorithm.
8.13. Compression of SN in AH and GRE extension headers 8.13. Compression of SN in AH and GRE extension headers
The AH and GRE sequence numbers are compressed exactly as the ESP The AH and GRE sequence numbers are compressed exactly as the ESP
sequence number. Specifically, the principle for when to include or sequence number. Specifically, the principle for when to include or
exclude the AH and GRE sequence numbers is the same as for ESP, i.e. exclude the AH and GRE sequence numbers is the same as for ESP, i.e.
the following rule applies to all these sequence numbers: the following rule from section 5.8.4.3 applies to all these sequence
numbers:
Sequence Number: Not sent when the offset from the sequence number "Sequence Number: Not sent when the offset from the sequence number
of the compressed header is constant. When the of the compressed header is constant. When the
offset is not constant, the sequence number is offset is not constant, the sequence number is
compressed by sending LSBs. See 5.8.4. compressed by sending LSBs. See 5.8.4."
9. ROHC negotiation clarifications 9. ROHC negotiation clarifications
According to section 4.1, the link layer must provide means to According to section 4.1, the link layer must provide means to
negotiate e.g. the channel parameters listed in section 5.1.1. One negotiate e.g. the channel parameters listed in section 5.1.1. One
of these parameters is the PROFILES parameter, which is said to be a of these parameters is the PROFILES parameter, which is said to be a
set of non-negative integers where each integer indicates a profile set of non-negative integers where each integer indicates a profile
supported by the decompressor. This can be interpreted as if it is supported by the decompressor. This can be interpreted as if it is
sufficient to have a mechanism to announce profile support from sufficient to have a mechanism to announce profile support from
decompressor to compressor. However, things are a little bit more decompressor to compressor. However, things are a little bit more
skipping to change at page 20, line 40 skipping to change at page 20, line 40
13. IANA considerations 13. IANA considerations
This document does not require any IANA actions. This document does not require any IANA actions.
14. Acknowledgment 14. Acknowledgment
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy
Lundemo, Alan Kennington and Remi Pelland for their contributions and Lundemo, Alan Kennington and Remi Pelland for their contributions and
comments. comments. Thanks also to the committed document reviewers, Carl
Knutsson and Biplab Sarkar, who reviewed the document during working
group last-call.
15. References 15. References
15.1. Normative References 15.1. Normative References
[1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework [1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework
and four profiles: RTP, UDP, ESP, and uncompressed", and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[2] C. Bormann, "Robust Header Compression (ROHC) over PPP", [2] C. Bormann, "Robust Header Compression (ROHC) over PPP",
skipping to change at page 24, line 31 skipping to change at page 24, line 31
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires May 23, 2006. This Internet-Draft expires July 23, 2006.
 End of changes. 20 change blocks. 
22 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/