draft-ietf-cuss-sip-uui-isdn-03.txt   draft-ietf-cuss-sip-uui-isdn-04.txt 
Network Working Group K. Drage, Ed. Network Working Group K. Drage, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track A. Johnston Intended status: Standards Track A. Johnston
Expires: September 14, 2012 Avaya Expires: November 5, 2012 Avaya
March 13, 2012 May 4, 2012
Interworking ISDN Call Control User Information with SIP Interworking ISDN Call Control User Information with SIP
draft-ietf-cuss-sip-uui-isdn-03 draft-ietf-cuss-sip-uui-isdn-04
Abstract Abstract
The motivation and use cases for interworking and transporting ITU-T The motivation and use cases for interworking and transporting ITU-T
DSS1 User-user information element data in SIP are described in the DSS1 User-user information element data in SIP are described in the
"Problem Statement and Requirements for Transporting User to User "Problem Statement and Requirements for Transporting User to User
Call Control Information in SIP" document. As networks move to SIP Call Control Information in SIP" document. As networks move to SIP
it is important that applications requiring this data can continue to it is important that applications requiring this data can continue to
function in SIP networks as well as the ability to interwork with function in SIP networks as well as the ability to interwork with
this ISDN service for end-to- end transparency. This document this ISDN service for end-to- end transparency. This document
defines a usage of the User-to-User header field to enable defines a usage (a new package) of the User-to-User header field to
interworking with this ISDN service. enable interworking with this ISDN service.
This document covers the interworking with both public ISDN and This document covers the interworking with both public ISDN and
private ISDN capabilities, so the potential interworking with QSIG private ISDN capabilities, so the potential interworking with QSIG
will also be addressed. will also be addressed.
The package is identified by a new value "isdn-uui" of the "purpose"
header field parameter.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2012. This Internet-Draft will expire on November 5, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 37 skipping to change at page 2, line 39
9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. UUI contents . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Considerations for ISDN interworking gateways . . . . . . . . 11 10. Considerations for ISDN interworking gateways . . . . . . . . 11
11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11 11. Coding requirements . . . . . . . . . . . . . . . . . . . . . 11
12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12 12. Media Feature Tag . . . . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
16. Changes since previous versions . . . . . . . . . . . . . . . 14 16. Changes since previous versions . . . . . . . . . . . . . . . 14
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
17.1. Normative References . . . . . . . . . . . . . . . . . . . 17 17.1. Normative References . . . . . . . . . . . . . . . . . . . 17
17.2. Informative References . . . . . . . . . . . . . . . . . . 17 17.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Terminology 1. Terminology
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 BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2. Overview 2. Overview
skipping to change at page 7, line 31 skipping to change at page 7, line 31
transferred, although the SIP request will otherwise be interworked. transferred, although the SIP request will otherwise be interworked.
As a result there is also only one encoding value specified. As a result there is also only one encoding value specified.
The general principals of this package of the UUI mechanism are The general principals of this package of the UUI mechanism are
therefore as follows: therefore as follows:
That the sending application is expected to limit their sending That the sending application is expected to limit their sending
requirements to the subset provided by the ISDN UUI service. requirements to the subset provided by the ISDN UUI service.
That the SIP UA will not allow the reception of more that one That the SIP UA will not allow the reception of more that one
User-to-User header field of the "isdn-uui" package in the same User-to-User header field relating to the "isdn-uui" package in
SIP request or response, and will only allow it in a request or the same SIP request or response, and will only allow it in a
response of the appropriate method (INVITE or BYE). What happens request or response of the appropriate method (INVITE or BYE).
to User-to-User header fields relating to different packages is What happens to User-to-User header fields relating to different
outside the scope of this document. packages is outside the scope of this document.
That an interworking point trying to interwork UUI data that is That an interworking point trying to interwork UUI data that is
too long will discard the UUI data, but proceed with the too long will discard the UUI data, but proceed with the
interworking. There is no notification of such discard back to interworking. There is no notification of such discard back to
the sending user. If the SIP user knows that it is interworking the sending user. If the SIP user knows that it is interworking
with the ISDN, then the UUI application at the SIP endpoint should with the ISDN, then the UUI application at the SIP endpoint should
limit its communication to 128 octet packets plus the protocol limit its communication to 128 octet packets plus the protocol
discriminator, in the knowledge that discard will occur if it does discriminator, in the knowledge that discard will occur if it does
not. The UUI application at the SIP endpoint has complete control not. The UUI application at the SIP endpoint has complete control
over what occurs. It should be noted that this was exactly the over what occurs. It should be noted that this was exactly the
skipping to change at page 8, line 21 skipping to change at page 8, line 21
The UAC MUST only use this package of the UUI mechanism extension in The UAC MUST only use this package of the UUI mechanism extension in
association with the initial INVITE method and the BYE method association with the initial INVITE method and the BYE method
relating to an INVITE dialog. Usage on transactions associated with relating to an INVITE dialog. Usage on transactions associated with
any other type of dialog, or on methods not associated with a dialog any other type of dialog, or on methods not associated with a dialog
is precluded. Usage on other methods within the INVITE dialog, and is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded. on re-INVITE transactions with the INVITE dialog, is also precluded.
If the UAC wishes to use or permit the sending of UUI data at any If the UAC wishes to use or permit the sending of UUI data at any
point in the dialog, the UAC MUST include in the INVITE request for point in the dialog, the UAC MUST include in the INVITE request for
that dialog a User-to-User header field. The UAC SHOULD set the that dialog a User-to-User header field. The UAC SHOULD set the
"package" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter to "isdn-uui". Non-inclusion of the
"package" header field parameter is permitted, but this is primarily "purpose" header field parameter is permitted, but this is primarily
to allow earlier implementations to support this package. This to allow earlier implementations to support this package. This
initial header field constitutes the implicit request to use the UUI initial header field constitutes the implicit request to use the UUI
service, and is therefore included even when there is no data except service, and is therefore included even when there is no data except
the protocol discriminator octet to send at that point in time. the protocol discriminator octet to send at that point in time.
The UAC MUST NOT include the User-to-User header field with a The UAC MUST NOT include the User-to-User header field with a
"package" header field parameter set to "isdn-uui", or with no "purpose" header field parameter set to "isdn-uui", or with no
"package" header field parameter", in any message of an INVITE dialog "purpose" header field parameter", in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User if the original INVITE request did not include the User-to-User
header field, either with a "package" header field parameter set to header field, either with a "purpose" header field parameter set to
"isdn-uui", or with no "package" header field parameter included. "isdn-uui", or with no "purpose" header field parameter included.
When sending UUI for the ISDN package, if the "package" header field When sending UUI for the ISDN package, if the "purpose" header field
is included, the UAC MUST set the User-to-User "package" header field is included, the UAC MUST set the User-to-User "purpose" header field
parameter to "isdn-uui". The UAC MUST NOT include more than one parameter to "isdn-uui". The UAC MUST NOT include more than one
User-to-User header field for this package in any SIP request or User-to-User header field for this package in any SIP request or
response. response.
When receiving UUI, when multiple User-to-User header fields are When receiving UUI, when multiple User-to-User header fields are
received in the same response with the "package" header field received in the same response with the "purpose" header field
parameter to "isdn-uui", or with no "package" header field parameter, parameter to "isdn-uui", or with no "purpose" header field parameter,
or with some combination of these, the UAS MUST discard all these or with some combination of these, the UAS MUST discard all these
header fields. There are no mechanisms for determining which was the header fields. There are no mechanisms for determining which was the
intended data packet so all are discarded. intended data packet so all are discarded.
The application designer will need to take into account the ISDN The application designer will need to take into account the ISDN
service restrictions; failure to do so can result in information service restrictions; failure to do so can result in information
being discarded at any interworking point with the ISDN. This being discarded at any interworking point with the ISDN. This
document makes no further normative requirements based on those document makes no further normative requirements based on those
constraints, because those constraints may vary from one ISDN to constraints, because those constraints may vary from one ISDN to
another. It is reasonable to expect that a limitation of 128 octets another. It is reasonable to expect that a limitation of 128 octets
skipping to change at page 9, line 19 skipping to change at page 9, line 19
if such interworking occurs. Note that the 128 octet limit (plus a if such interworking occurs. Note that the 128 octet limit (plus a
protocol discriminator) applies before the encoding (or after the protocol discriminator) applies before the encoding (or after the
decoding) using the "hex" encoding. The "hex" encoding is defined in decoding) using the "hex" encoding. The "hex" encoding is defined in
[I-D.ietf-cuss-sip-uui]. [I-D.ietf-cuss-sip-uui].
[I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
UUI mechanism extension. Because for the ISDN UUI service, the UUI mechanism extension. Because for the ISDN UUI service, the
service is service 1 implicit, the inclusion of the "uui" option tag service is service 1 implicit, the inclusion of the "uui" option tag
in a Supported header field conveys no additional information over in a Supported header field conveys no additional information over
and above the presence of the User-to-User header field with the and above the presence of the User-to-User header field with the
"package" header field parameter to "isdn-uui" in the INVITE request. "purpose" header field parameter to "isdn-uui" in the INVITE request.
While there is no harm in including the "uui" option tag, and While there is no harm in including the "uui" option tag, and
strictly it should be included if the extension is supported, it strictly it should be included if the extension is supported, it
performs no function. The presence of the "uui" option tag in the performs no function. The presence of the "uui" option tag in the
Require header field of an INVITE request will cause the request to Require header field of an INVITE request will cause the request to
fail if it reaches a UAS or ISDN interworking gateway that does not fail if it reaches a UAS or ISDN interworking gateway that does not
support this extension; such a usage is not precluded although it support this extension; such a usage is not precluded although it
does not form part of the package. does not form part of the package.
8. UAS requirements 8. UAS requirements
skipping to change at page 9, line 41 skipping to change at page 9, line 41
addition to the requirements defined in this document. addition to the requirements defined in this document.
The UAS MUST only use this package of the UUI mechanism extension in The UAS MUST only use this package of the UUI mechanism extension in
association with the initial INVITE method and the BYE method association with the initial INVITE method and the BYE method
relating to an INVITE dialog. Usage on transactions associated with relating to an INVITE dialog. Usage on transactions associated with
any other type of dialog, or on methods not associated with a dialog any other type of dialog, or on methods not associated with a dialog
is precluded. Usage on other methods within the INVITE dialog, and is precluded. Usage on other methods within the INVITE dialog, and
on re-INVITE transactions with the INVITE dialog, is also precluded. on re-INVITE transactions with the INVITE dialog, is also precluded.
The UAS MUST NOT include the User-to-User header field with a The UAS MUST NOT include the User-to-User header field with a
"package" header field parameter set to "isdn-uui", or with no "purpose" header field parameter set to "isdn-uui", or with no
"package" header field parameter", in any message of an INVITE dialog "purpose" header field parameter", in any message of an INVITE dialog
if the original INVITE request did not include the User-to-User if the original INVITE request did not include the User-to-User
header field, either with a "package" header field parameter set to header field, either with a "purpose" header field parameter set to
"isdn-uui", or with no "package" header field parameter included. "isdn-uui", or with no "purpose" header field parameter included.
The UAS MAY include the User-to-User header field in responses to the The UAS MAY include the User-to-User header field in responses to the
initial INVITE request, or the BYE requests or responses for the initial INVITE request, or the BYE requests or responses for the
dialog, only where the original INVITE request included a User-to- dialog, only where the original INVITE request included a User-to-
User header field with the "package" header field parameter to "isdn- User header field with the "purpose" header field parameter to "isdn-
uui", or where no "package" header field parameter was included. uui", or where no "purpose" header field parameter was included.
When sending UUI for the ISDN package, the UAS SHOULD set the User- When sending UUI for the ISDN package, the UAS SHOULD set the User-
to-User "package" header field parameter to "isdn-uui". Non- to-User "purpose" header field parameter to "isdn-uui". Non-
inclusion of the "package" header field parameter is permitted, but inclusion of the "purpose" header field parameter is permitted, but
this is primarily to allow earlier implementations to support this this is primarily to allow earlier implementations to support this
package. The UAS MUST NOT include more than one User-to-User header package. The UAS MUST NOT include more than one User-to-User header
field for this package in any SIP request or response. field for this package in any SIP request or response.
Where the UAS is acting as a redirect server, the UAS MUST NOT Where the UAS is acting as a redirect server, the UAS MUST NOT
include the User-to-User header field in the header URI parameter in include the User-to-User header field in the header URI parameter in
a 3xx response to an incoming request. a 3xx response to an incoming request.
When receiving UUI, when a User-to-User header field is received in a When receiving UUI, when a User-to-User header field is received in a
request that is not from the originating user with the "package" request that is not from the originating user with the "purpose"
header field parameter to "isdn-uui", or with no "package" header header field parameter to "isdn-uui", or with no "purpose" header
field parameter, the UAC MUST discard this header field. field parameter, the UAC MUST discard this header field.
When receiving UUI, when multiple User-to-User header fields are When receiving UUI, when multiple User-to-User header fields are
received from the originating user in the same request with the received from the originating user in the same request with the
"package" header field parameter to "isdn-uui", or with no "package" "purpose" header field parameter to "isdn-uui", or with no "purpose"
header field parameter, or with some combination of these, the UAC header field parameter, or with some combination of these, the UAC
MUST discard all these header fields. There are no mechanisms for MUST discard all these header fields. There are no mechanisms for
determining which was the intended data packet so all are discarded. determining which was the intended data packet so all are discarded.
9. UUI contents 9. UUI contents
These requirements apply when the "package" header field parameter is These requirements apply when the "purpose" header field parameter is
set to "isdn-uui", or with no "package" header field parameter. set to "isdn-uui", or with no "purpose" header field parameter.
Processing for User-to-User header fields sent or received with Processing for User-to-User header fields sent or received with
values other than this value are outside the scope of this document, values other than this value are outside the scope of this document,
and the appropriate package document for that value applies. and the appropriate package document for that value applies.
The default and only content defined for this package is "isdn-uui". The default and only content defined for this package is "isdn-uui".
When sending UUI, the sending SIP entity MAY, but need not, include a When sending UUI, the sending SIP entity MAY, but need not, include a
"content" header field with a value set to "isdn-uui". A receiving "content" header field with a value set to "isdn-uui". A receiving
SIP entity MUST ignore a received User-to-User header field if the SIP entity MUST ignore a received User-to-User header field if the
"content" header field parameter is present and the value is some "content" header field parameter is present and the value is some
other value that "isdn-uui". other value that "isdn-uui".
skipping to change at page 12, line 4 skipping to change at page 12, line 4
[I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the [I-D.ietf-cuss-sip-uui] defines a "uui" option tag for use with the
UUI mechanism extension. The option tag is not interworked at an UUI mechanism extension. The option tag is not interworked at an
ISDN interworking gateway. The ISDN interworking gateways MUST NOT ISDN interworking gateway. The ISDN interworking gateways MUST NOT
take the omission of the "uui" option tag in a received INVITE take the omission of the "uui" option tag in a received INVITE
request to indicate that interworking of a received header field is request to indicate that interworking of a received header field is
not to be performed. not to be performed.
11. Coding requirements 11. Coding requirements
This document defines "isdn-uui" as a new value of the User-to-User This document defines "isdn-uui" as a new value of the User-to-User
"package" header field parameter. "purpose" header field parameter.
This document defines "isdn-uui" as a new value of the User-to-User This document defines "isdn-uui" as a new value of the User-to-User
"content" header field parameter. A content value of "isdn-uui" "content" header field parameter. A content value of "isdn-uui"
indicates that the contents have a first octet that is a protocol indicates that the contents have a first octet that is a protocol
discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931] discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931]
followed by uui-data that can be subject to a length limitation followed by uui-data that can be subject to a length limitation
(before encoding or after decoding) that is generally 128 octets. (before encoding or after decoding) that is generally 128 octets.
12. Media Feature Tag 12. Media Feature Tag
skipping to change at page 12, line 43 skipping to change at page 12, line 43
Contact: Contact:
This document adds the following row to the "UUI content" subregistry This document adds the following row to the "UUI content" subregistry
of the SIP parameter registry: of the SIP parameter registry:
Value: isdn-uui Value: isdn-uui
Description: The associated contents conforms to the content Description: The associated contents conforms to the content
associated with the ISDN user-to-user service. In the presence of associated with the ISDN user-to-user service. In the presence of
the "package" header field parameter set to "isdn-uui" this is the the "purpose" header field parameter set to "isdn-uui" (or the
absence of any "purpose" header field parameter) this is the
default meaning and therefore need not be included in this case. default meaning and therefore need not be included in this case.
Reference: RFCXXXX Reference: RFCXXXX
Contact: Contact:
This document defines the following media feature tag which is added This document defines the following media feature tag which is added
to the features.sip-tree of the Media Feature tags registry: to the features.sip-tree of the Media Feature tags registry:
Media feature-tag name: sip.uui-isdn Media feature-tag name: sip.uui-isdn
ASN.1 Identifier: 1.3.6.1.8.4.x ASN.1 Identifier: 1.3.6.1.8.4.x
Summary of the media feature indicated by this tag: This media Summary of the media feature indicated by this tag: This media
skipping to change at page 14, line 28 skipping to change at page 14, line 30
thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen thank Francois Audet, Denis Alexeitsev, Paul Kyzivat, Cullen
Jennings, Mahalingam Mani and Celine Serrut-Valette for their Jennings, Mahalingam Mani and Celine Serrut-Valette for their
comments. comments.
16. Changes since previous versions 16. Changes since previous versions
Note to RFC editor: This section is to be deleted before final Note to RFC editor: This section is to be deleted before final
publication. publication.
Changes since made in the creation of the Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-04 version from the
draft-ietf-cuss-sip-uui-isdn-03 version.
Change of the "package" header field parameter back to the
"purpose" header field parameter in alignment with change in
draft-ietf-cuss-sip-uui.
Identification of the package name in the abstract.
Minor change to IANA registration of "content" header field
parameter value to align with main text such that absence of
"package" header field parameter and absence of "content" header
field parameter implies this package and therefore this content,
as a default.
Changes since made in the creation of the
draft-ietf-cuss-sip-uui-isdn-03 version from the draft-ietf-cuss-sip-uui-isdn-03 version from the
draft-ietf-cuss-sip-uui-isdn-02 version. draft-ietf-cuss-sip-uui-isdn-02 version.
Clarification added that the default content is "isdn-uui". Clarification added that the default content is "isdn-uui".
Clarification added that the default encoding is "hex". Clarification added that the default encoding is "hex".
Changeout of "payload" terminology to "UUI data". Changeout of "payload" terminology to "UUI data".
Changes since made in the creation of the Changes since made in the creation of the
skipping to change at page 17, line 38 skipping to change at page 18, line 6
for Telephones (SIP-T): Context and Architectures", for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002. BCP 63, RFC 3372, September 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[I-D.ietf-cuss-sip-uui] [I-D.ietf-cuss-sip-uui]
Johnston, A. and J. Rafferty, "A Mechanism for Johnston, A. and J. Rafferty, "A Mechanism for
Transporting User to User Call Control Information in Transporting User to User Call Control Information in
SIP", draft-ietf-cuss-sip-uui-05 (work in progress), SIP", draft-ietf-cuss-sip-uui-06 (work in progress),
March 2012. May 2012.
[Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling [Q931] "ITU-T Recommendation Q.931: Digital subscriber Signalling
System No. 1 - Network layer; ISDN user-network interface System No. 1 - Network layer; ISDN user-network interface
layer 3 specification for basic call control", layer 3 specification for basic call control",
http://www.itu.int/rec/T-REC-Q.931-199805-I/en . http://www.itu.int/rec/T-REC-Q.931-199805-I/en .
17.2. Informative References 17.2. Informative References
[I-D.ietf-cuss-sip-uui-reqs] [I-D.ietf-cuss-sip-uui-reqs]
Johnston, A. and L. Liess, "Problem Statement and Johnston, A. and L. Liess, "Problem Statement and
 End of changes. 26 change blocks. 
42 lines changed or deleted 60 lines changed or added

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