draft-ietf-dccp-rtp-05.txt   draft-ietf-dccp-rtp-06.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track March 26, 2007 Intended status: Standards Track May 21, 2007
Expires: September 27, 2007 Expires: November 22, 2007
RTP and the Datagram Congestion Control Protocol (DCCP) RTP and the Datagram Congestion Control Protocol (DCCP)
draft-ietf-dccp-rtp-05.txt draft-ietf-dccp-rtp-06.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.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 September 27, 2007. This Internet-Draft will expire on November 22, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Real-time Transport Protocol (RTP) is a widely used transport for The Real-time Transport Protocol (RTP) is a widely used transport for
real-time multimedia on IP networks. The Datagram Congestion Control real-time multimedia on IP networks. The Datagram Congestion Control
Protocol (DCCP) is a newly defined transport protocol that provides Protocol (DCCP) is a newly defined transport protocol that provides
skipping to change at page 4, line 17 skipping to change at page 4, line 17
transport protocols. An example of the first approach can be found transport protocols. An example of the first approach can be found
in [16], extending RTP to incorporate feedback information such that in [16], extending RTP to incorporate feedback information such that
TFRC congestion control [17] can be implemented at the application TFRC congestion control [17] can be implemented at the application
level. This will allow congestion control to be added to existing level. This will allow congestion control to be added to existing
applications without operating system or network support, and it applications without operating system or network support, and it
offers the flexibility to experiment with new congestion control offers the flexibility to experiment with new congestion control
algorithms as they are developed. Unfortunately, it also passes the algorithms as they are developed. Unfortunately, it also passes the
complexity of implementing congestion control onto application complexity of implementing congestion control onto application
authors, a burden which many would prefer to avoid. authors, a burden which many would prefer to avoid.
The other approach is to run RTP on a lower-layer transport protocol The second approach is to run RTP on a lower-layer transport protocol
that provides congestion control. One possibility is to run RTP over that provides congestion control. One possibility is to run RTP over
TCP, as defined in [5], but the reliable nature of TCP and the TCP, as defined in [5], but the reliable nature of TCP and the
dynamics of its congestion control algorithm make this inappropriate dynamics of its congestion control algorithm make this inappropriate
for most interactive real time applications (the Stream Control for most interactive real time applications (the Stream Control
Transmission Protocol (SCTP) is inappropriate for similar reasons). Transmission Protocol (SCTP) is inappropriate for similar reasons).
A better fit for such applications may be to run RTP over DCCP, since A better fit for such applications may be to run RTP over DCCP, since
DCCP offers unreliable packet delivery and a choice of congestion DCCP offers unreliable packet delivery and a choice of congestion
control. This gives applications the ability to tailor the transport control. This gives applications the ability to tailor the transport
to their needs, taking advantage of better congestion control to their needs, taking advantage of better congestion control
algorithms as they come available, while passing complexity of algorithms as they come available, while passing complexity of
skipping to change at page 5, line 20 skipping to change at page 5, line 20
bindings are kept open, an end system SHOULD send a zero length DCCP- bindings are kept open, an end system SHOULD send a zero length DCCP-
Data packet once every 15 seconds during periods when it has no other Data packet once every 15 seconds during periods when it has no other
data to send. This removes the need for RTP no-op packets [18], and data to send. This removes the need for RTP no-op packets [18], and
similar application level keep-alives, when using RTP over DCCP. similar application level keep-alives, when using RTP over DCCP.
This application level keepalive does not need to be sent if it is This application level keepalive does not need to be sent if it is
known that the DCCP CCID in use provides a transport level keepalive. known that the DCCP CCID in use provides a transport level keepalive.
RTP data packets MUST obey the dictates of DCCP congestion control. RTP data packets MUST obey the dictates of DCCP congestion control.
In some cases, the congestion control will require a sender to send In some cases, the congestion control will require a sender to send
at a rate below that which the payload format would otherwise use. at a rate below that which the payload format would otherwise use.
To support this, an application should use either a rate adaptive To support this, an application could use either a rate adaptive
payload format, or a range of payload formats (allowing it to switch payload format, or a range of payload formats (allowing it to switch
to a lower rate format if necessary). Details of the rate adaptation to a lower rate format if necessary). Details of the rate adaptation
policy for particular payload formats are outside the scope of this policy for particular payload formats are outside the scope of this
memo (but see [19] and [20] for guidance). memo (but see [19] and [20] for guidance).
RTP extensions that provide application-level congestion control RTP extensions that provide application-level congestion control
(e.g. [16]) will conflict with DCCP congestion control, and MUST (e.g. [16]) will conflict with DCCP congestion control, and MUST NOT
NOT be used. be used.
DCCP allows an application to choose the checksum coverage, using a DCCP allows an application to choose the checksum coverage, using a
partial checksum to allow an application to receive packets with partial checksum to allow an application to receive packets with
corrupt payloads. Some RTP Payload Formats (e.g. [21]) can make use corrupt payloads. Some RTP Payload Formats (e.g. [21]) can make use
of this feature in conjunction with payload-specific mechanisms to of this feature in conjunction with payload-specific mechanisms to
improve performance when operating in environments with frequent non- improve performance when operating in environments with frequent non-
congestive packet corruption. If such a payload format is used, an congestive packet corruption. If such a payload format is used, an
RTP end system MAY enable partial checksums at the DCCP layer, in RTP end system MAY enable partial checksums at the DCCP layer, in
which case the checksum MUST cover at least the DCCP and RTP headers which case the checksum MUST cover at least the DCCP and RTP headers
to ensure packets are correctly delivered. Partial checksums MUST to ensure packets are correctly delivered. Partial checksums MUST
skipping to change at page 6, line 23 skipping to change at page 6, line 23
the configured nominal "session bandwidth" (see Section 6.2 of [1]) the configured nominal "session bandwidth" (see Section 6.2 of [1])
is in line with the bandwidth achievable on the DCCP connection. If, is in line with the bandwidth achievable on the DCCP connection. If,
however, the capacity of the DCCP connection is significantly below however, the capacity of the DCCP connection is significantly below
the nominal session bandwidth, RTCP packets may be delayed enough for the nominal session bandwidth, RTCP packets may be delayed enough for
participants to time out due to apparent inactivity. In such cases, participants to time out due to apparent inactivity. In such cases,
the session parameters SHOULD be re-negotiated to more closely match the session parameters SHOULD be re-negotiated to more closely match
the available capacity, for example by performing a re-invite with an the available capacity, for example by performing a re-invite with an
updated "b=" line when using the Session Initiation Protocol [22] for updated "b=" line when using the Session Initiation Protocol [22] for
signalling. signalling.
Since the nominal session bandwidth is chosen based on media codec Note: Since the nominal session bandwidth is chosen based on media
capabilities, a session where the nominal bandwidth is much larger codec capabilities, a session where the nominal bandwidth is much
than the available bandwidth will likely become unusable due to larger than the available bandwidth will likely become unusable
constraints on the media channel, and so require negotiation of a due to constraints on the media channel, and so require
lower bandwidth codec, before it becomes unusable due to negotiation of a lower bandwidth codec, before it becomes unusable
constraints on the RTCP channel. due to constraints on the RTCP channel.
As noted in Section 17.1 of [2], there is the potential for overlap As noted in Section 17.1 of [2], there is the potential for overlap
between information conveyed in RTCP packets and that conveyed in between information conveyed in RTCP packets and that conveyed in
DCCP acknowledgement options. In general this is not an issue since DCCP acknowledgement options. In general this is not an issue since
RTCP packets contain media-specific data that is not present in DCCP RTCP packets contain media-specific data that is not present in DCCP
acknowledgement options, and DCCP options contain network-level data acknowledgement options, and DCCP options contain network-level data
that is not present in RTCP. Indeed, there is no overlap between the that is not present in RTCP. Indeed, there is no overlap between the
five RTCP packet types defined in the RTP specification [1] and the five RTCP packet types defined in the RTP specification [1] and the
standard DCCP options [2]. There are, however, cases where overlap standard DCCP options [2]. There are, however, cases where overlap
does occur: most clearly between the optional RTCP Extended Reports does occur: most clearly between the optional RTCP Extended Reports
Loss RLE Blocks [23] and the DCCP Ack Vector option. If there is Loss RLE Blocks [23] and the DCCP Ack Vector option. If there is
overlap between RTCP report packets and DCCP acknowledgements, an overlap between RTCP report packets and DCCP acknowledgements, an
application should use either RTCP feedback or DCCP acknowledgements, application SHOULD use either RTCP feedback or DCCP acknowledgements,
but not both (use of both types of feedback will waste available but not both (use of both types of feedback will waste available
network capacity, but is not otherwise harmful). network capacity, but is not otherwise harmful).
4.3. Multiplexing Data and Control 4.3. Multiplexing Data and Control
The obvious mapping of RTP onto DCCP creates two DCCP connections for The obvious mapping of RTP onto DCCP creates two DCCP connections for
each RTP flow: one for RTP data packets, one for RTP control packets. each RTP flow: one for RTP data packets, one for RTP control packets.
A frequent criticism of RTP relates to the number of ports it uses, A frequent criticism of RTP relates to the number of ports it uses,
since large telephony gateways can support more than 32768 RTP flows since large telephony gateways can support more than 32768 RTP flows
between pairs of gateways, and so run out of UDP ports. In addition, between pairs of gateways, and so run out of UDP ports. In addition,
use of multiple ports complicates NAT traversal. For these reasons, use of multiple ports complicates NAT traversal. For these reasons,
it is RECOMMENDED that the RTP and RTCP traffic for a single RTP it is RECOMMENDED that the RTP and RTCP traffic for a single RTP
session is multiplexed onto a single DCCP connection following the session is multiplexed onto a single DCCP connection following the
guidelines in [7], where possible (it may not be possible in all guidelines in [7], where possible (it may not be possible in all
circumstances, for example when translating from an RTP stream over a circumstances, for example when translating from an RTP stream over a
non-DCCP transport that uses conflicting RTP payload types and RTCP non-DCCP transport that uses conflicting RTP payload types and RTCP
packet types). packet types).
4.4. RTP Sessions and DCCP Connections 4.4. RTP Sessions and DCCP Connections
An end system should not assume that it will observe only a single An end system SHOULD NOT assume that it will observe only a single
RTP synchronisation source (SSRC) because it is using DCCP framing. RTP synchronisation source (SSRC) because it is using DCCP framing.
An RTP session can span any number of transport connections, and can An RTP session can span any number of transport connections, and can
include RTP mixers or translators bringing other participants into include RTP mixers or translators bringing other participants into
the session. The use of a unicast DCCP connection does not imply the session. The use of a unicast DCCP connection does not imply
that the RTP session will have only two participants, and RTP end that the RTP session will have only two participants, and RTP end
systems SHOULD assume that multiple synchronisation sources may be systems SHOULD assume that multiple synchronisation sources may be
observed when using RTP over DCCP, unless otherwise signalled. observed when using RTP over DCCP, unless otherwise signalled.
An RTP translator bridging multiple DCCP connections to form a single An RTP translator bridging multiple DCCP connections to form a single
RTP session needs to be aware of the congestion state of each DCCP RTP session needs to be aware of the congestion state of each DCCP
connection, and must adapt the media to the available capacity of connection, and must adapt the media to the available capacity of
each. In general, transcoding is required to perform adaptation: each. The Codec Control Messages defined in [24] may be used to
this is computationally expensive, induces delay, and generally gives signal congestion state to the media senders, allowing them to adapt
poor quality results. Depending on the payload, it might be possible their transmission. Alternatively, media transcoding may be used to
to use some form of scalable coding. Scalable media coding formats perform adaptation: this is computationally expensive, induces delay,
are an active research area, and are not in widespread use at the and generally gives poor quality results. Depending on the payload,
time of this writing. it might be possible to use some form of scalable coding. Scalable
media coding formats are an active research area, and are not in
widespread use at the time of this writing.
A single RTP session may also span a DCCP connection and some other A single RTP session may also span a DCCP connection and some other
type of transport connection. An example might be an RTP over DCCP type of transport connection. An example might be an RTP over DCCP
connection from an RTP end system to an RTP translator, with an RTP connection from an RTP end system to an RTP translator, with an RTP
over UDP/IP multicast group on the other side of the translator. A over UDP/IP multicast group on the other side of the translator. A
second example might be an RTP over DCCP connection that links PSTN second example might be an RTP over DCCP connection that links PSTN
gateways. The issues for such an RTP translator are similar to those gateways. The issues for such an RTP translator are similar to those
when linking two DCCP connections, except that the congestion control when linking two DCCP connections, except that the congestion control
algorithms on either side of the translator may not be compatible. algorithms on either side of the translator may not be compatible.
Implementation of effective translators for such an environment is Implementation of effective translators for such an environment is
skipping to change at page 9, line 46 skipping to change at page 9, line 48
other sessions. If RTCP is to be sent on a separate DCCP connection other sessions. If RTCP is to be sent on a separate DCCP connection
to RTP, the RTCP connection SHOULD use the next higher destination to RTP, the RTCP connection SHOULD use the next higher destination
port number, unless an alternative DCCP port is signalled using the port number, unless an alternative DCCP port is signalled using the
"a=rtcp:" attribute [13]. "a=rtcp:" attribute [13].
5.2. Service Codes 5.2. Service Codes
In addition to the port number, specified on the SDP "m=" line, a In addition to the port number, specified on the SDP "m=" line, a
DCCP connection has an associated service code. A single new SDP DCCP connection has an associated service code. A single new SDP
attribute ("dccp-service-code") is defined to signal the DCCP service attribute ("dccp-service-code") is defined to signal the DCCP service
code: code according to the following ABNF [14]:
dccp-service-attr = %x61 "=dccp-service-code:" service-code dccp-service-attr = %x61 "=dccp-service-code:" service-code
service-code = hex-sc / decimal-sc / ascii-sc service-code = hex-sc / decimal-sc / ascii-sc
hex-sc = %x53 %x43 "=" %x78 *HEXDIG hex-sc = %x53 %x43 "=" %x78 *HEXDIG
decimal-sc = %x53 %x43 "=" *DIGIT decimal-sc = %x53 %x43 "=" *DIGIT
ascii-sc = %x53 %x43 ":" *sc-char ascii-sc = %x53 %x43 ":" *sc-char
sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122 sc-char = %d42-43 / %d45-47 / %d63-90 / %d95 / %d97-122
where DIGIT and HEXDIG are as defined in [14]. The service code where DIGIT and HEXDIG are as defined in [14]. The service code is
should be interpreted as defined in Section 8.1.2 of [2]. The interpreted as defined in Section 8.1.2 of [2]. The following DCCP
following DCCP service codes are registered for use with RTP: service codes are registered for use with RTP:
o SC:RTPA an RTP session conveying audio data (and associated RTCP) o SC:RTPA an RTP session conveying audio data (and associated RTCP)
o SC:RTPV an RTP session conveying video data (and associated RTCP) o SC:RTPV an RTP session conveying video data (and associated RTCP)
o SC:RTPT an RTP session conveying text media (and associated RTCP) o SC:RTPT an RTP session conveying text media (and associated RTCP)
o SC:RTPO an RTP session conveying other media (and associated RTCP) o SC:RTPO an RTP session conveying other media (and associated RTCP)
o SC:RTCP an RTCP connection, separate from the corresponding RTP o SC:RTCP an RTCP connection, separate from the corresponding RTP
skipping to change at page 13, line 11 skipping to change at page 13, line 11
DCCP ports 5004 ("DCCP RTP") and 5005 ("DCCP RTCP") are registered DCCP ports 5004 ("DCCP RTP") and 5005 ("DCCP RTCP") are registered
for use as default RTP/RTCP ports (see Section 5.1 of this memo). for use as default RTP/RTCP ports (see Section 5.1 of this memo).
The four services codes listed above are to be associated with these The four services codes listed above are to be associated with these
ports. ports.
8. Acknowledgements 8. Acknowledgements
This work was supported in part by the UK Engineering and Physical This work was supported in part by the UK Engineering and Physical
Sciences Research Council. Thanks are due to to Philippe Gentric, Sciences Research Council. Thanks are due to to Philippe Gentric,
Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane Magnus Westerlund, Sally Floyd, Dan Wing, Gorry Fairhurst, Stephane
Bortzmeyer, Arjuna Sathiaseelan, and the other members of the DCCP Bortzmeyer, Arjuna Sathiaseelan, Tom Phelan, Lars Eggert, and the
working group for their comments. other members of the DCCP working group for their comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion [2] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
skipping to change at page 13, line 39 skipping to change at page 13, line 39
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- [5] Lazzaro, J., "Framing RTP and RTCP Packets over Connection-
Oriented Transport", RFC 4571, June 2006. Oriented Transport", RFC 4571, June 2006.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [7] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-04 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress),
March 2007. May 2007.
[8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [8] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[9] Ott, J., Wenger, S., Sato, N., and C. Burmeister, "Extended RTP [9] Ott, J., Wenger, S., Sato, N., and C. Burmeister, "Extended RTP
Profile for RTCP-based Feedback(RTP/AVPF)", RFC 4585, Profile for RTCP-based Feedback(RTP/AVPF)", RFC 4585,
June 2006. June 2006.
[10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP- [10] Ott, J. and E. Carrara, "Extended Secure RTP Profile for RTCP-
skipping to change at page 14, line 34 skipping to change at page 14, line 34
Control for Voice Traffic in the Internet", RFC 3714, Control for Voice Traffic in the Internet", RFC 3714,
March 2004. March 2004.
[16] Gharai, L., "RTP with TCP Friendly Rate Control", [16] Gharai, L., "RTP with TCP Friendly Rate Control",
draft-ietf-avt-tfrc-profile-07 (work in progress), March 2007. draft-ietf-avt-tfrc-profile-07 (work in progress), March 2007.
[17] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP [17] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003. RFC 3448, January 2003.
[18] Andreasen, F., "A No-Op Payload Format for RTP", [18] Andreasen, F., Oran, D., and D. Wing, "A No-Op Payload Format
draft-wing-avt-rtp-noop-03 (work in progress), May 2005. for RTP", draft-ietf-avt-rtp-no-op-03 (work in progress),
April 2007.
[19] Phelan, T., "Strategies for Streaming Media Applications Using [19] Phelan, T., "Strategies for Streaming Media Applications Using
TCP-Friendly Rate Control", draft-ietf-dccp-tfrc-media-01 TCP-Friendly Rate Control", draft-ietf-dccp-tfrc-media-01
(work in progress), October 2005. (work in progress), October 2005.
[20] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User [20] Phelan, T., "Datagram Congestion Control Protocol (DCCP) User
Guide", draft-ietf-dccp-user-guide-03 (work in progress), Guide", draft-ietf-dccp-user-guide-03 (work in progress),
April 2005. April 2005.
[21] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real- [21] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP
Time Transport Protocol (RTP) Payload Format and File Storage Payload Format and File Storage Format for the Adaptive Multi-
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi- Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio
Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. Codecs", RFC 4867, April 2007.
[22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol [23] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003. Extended Reports (RTCP XR)", RFC 3611, November 2003.
[24] Wenger, S., "Codec Control Messages in the RTP Audio-Visual
Profile with Feedback (AVPF)", draft-ietf-avt-avpf-ccm-05
(work in progress), May 2007.
Author's Address Author's Address
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
17 Lilybank Gardens 17 Lilybank Gardens
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 18 change blocks. 
36 lines changed or deleted 44 lines changed or added

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