draft-ietf-crisp-iris-common-transport-00.txt   draft-ietf-crisp-iris-common-transport-01.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: October 31, 2005 April 29, 2005 Expires: December 9, 2005 June 7, 2005
A Common Schema for Internet Registry Information Service Transfer A Common Schema for Internet Registry Information Service Transfer
Protocols Protocols
draft-ietf-crisp-iris-common-transport-00 draft-ietf-crisp-iris-common-transport-01
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 October 31, 2005. This Internet-Draft will expire on December 9, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes an XML Schema for use by Internet Registry This document describes an XML Schema for use by Internet Registry
Information Service (IRIS) application transfer protocols that share Information Service (IRIS) application transfer protocols that share
common characteristics. common characteristics.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
7. Authentication Failure Information . . . . . . . . . . . . . 11 7. Authentication Failure Information . . . . . . . . . . . . . 11
8. Other Information . . . . . . . . . . . . . . . . . . . . . 12 8. Other Information . . . . . . . . . . . . . . . . . . . . . 12
9. Internationalization Considerations . . . . . . . . . . . . 13 9. Internationalization Considerations . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10.1 XML Namespace URN Registration . . . . . . . . . . . . . 14 10.1 XML Namespace URN Registration . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1 Normative References . . . . . . . . . . . . . . . . . . 16 12.1 Normative References . . . . . . . . . . . . . . . . . . 16
12.2 Informative References . . . . . . . . . . . . . . . . . 16 12.2 Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 18 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . 19
1. Introduction 1. Introduction
IRIS [8] has two transfer protocols, LWZ [9] and XPC [10], that share IRIS [8] has two transfer protocols, LWZ [9] and XPC [10], that share
common negotiation mechanisms. Both transfer protocols have a need common negotiation mechanisms. Both transfer protocols have a need
for the server to provide rich status information to clients during for the server to provide rich status information to clients during
protocol negotiation. In many cases, this status information would protocol negotiation. In many cases, this status information would
be too complex to describe using simple bit fields and length- be too complex to describe using simple bit fields and length-
specifed octet sequences. This document defines an XML Schema for specifed octet sequences. This document defines an XML Schema for
this rich status information and describes the usage of comforant XML this rich status information and describes the usage of comforant XML
skipping to change at page 6, line 7 skipping to change at page 6, line 7
<attribute name="extensionIds" <attribute name="extensionIds"
type="normalizedString" /> type="normalizedString" />
</complexType> </complexType>
</element> </element>
</sequence> </sequence>
<attribute name="protocolId" type="token" use="required" <attribute name="protocolId" type="token" use="required"
/> />
<attribute name="extensionIds" type="normalizedString" /> <attribute name="extensionIds" type="normalizedString" />
<attribute name="authenticationIds" <attribute name="authenticationIds"
type="normalizedString" /> type="normalizedString" />
<attribute name="responseSizeOctets"
type="positiveInteger" />
<attribute name="requestSizeOctets"
type="positiveInteger" />
</complexType> </complexType>
</element> </element>
</sequence> </sequence>
</complexType> </complexType>
</element> </element>
<element name="responseSize"> <element name="size">
<complexType> <complexType>
<sequence>
<element name="request"
minOccurs="0"
type="iristrans:octetsType" />
<element name="response"
minOccurs="0"
type="iristrans:octetsType" />
</sequence>
</complexType>
</element>
<complexType name="octetsType">
<choice> <choice>
<element name="exceedsMaximum"> <element name="exceedsMaximum">
<complexType/> <complexType/>
</element> </element>
<element name="octets" type="positiveInteger" /> <element name="octets" type="positiveInteger" />
</choice> </choice>
</complexType> </complexType>
</element>
<element name="authenticationSuccess"> <element name="authenticationSuccess">
<complexType> <complexType>
<sequence> <sequence>
<element name="description" minOccurs="0" <element name="description" minOccurs="0"
maxOccurs="unbounded"> maxOccurs="unbounded">
<complexType> <complexType>
<simpleContent> <simpleContent>
<extension base="string"> <extension base="string">
<attribute name="language" type="language" <attribute name="language" type="language"
skipping to change at page 8, line 17 skipping to change at page 8, line 17
The <versions> element is used to describe version information about The <versions> element is used to describe version information about
the transfer protocol, the application protocol, and data models used the transfer protocol, the application protocol, and data models used
by the application protocol. by the application protocol.
The <versions> element has one or more <transferProtocol> child The <versions> element has one or more <transferProtocol> child
elements. <transferProtocol> elements have zero or more <application> elements. <transferProtocol> elements have zero or more <application>
child elements. And <application> elements have zero or more child elements. And <application> elements have zero or more
<dataModel> elements. Each of these element types has a 'protocolId' <dataModel> elements. Each of these element types has a 'protocolId'
attribute identifying the protocol they represent and an optional attribute identifying the protocol they represent and an optional
'extensionIds' attribute identifying the protocol extensions they 'extensionIds' attribute identifying the protocol extensions they
support. Additionally, the <transferProtocol> element has an support.
optional 'authenticationIds' attribute identifying authentication
mechanisms supported by the associated transfer protocol.
The protocol, extension, and authentication mechanim identifiers are Additionally, the <transferProtocol> element has optionalal
'authenticationIds', 'responseSizeOctets', and 'requestSizeOctets'
attributes. The 'authenticationIds' attribute identifies
authentication mechanisms supported by the associated transfer
protocol. The 'responseSizeOctets' attribute describes the maximum
response size in octets the server will give. The
'requestSizeOctets' attribute describes the maximum request size in
octets the server will accept.
The protocol, extension, and authentication mechanism identifiers are
of no specific type, and this document defines none. Specifications of no specific type, and this document defines none. Specifications
using this XML Schema MUST define the identifers for use with the using this XML Schema MUST define the identifers for use with the
<verions> element and its children. <versions> element and its children.
The meaning of octets for the transfer of data is counted in
different ways for different transfer protocols. Some transfer
protocols need only to specify the octets of the data being
transfered while other transfer protocols need to account for
additional octets used to transfer the data. Specifications using
this XML Schema MUST describe how these octet counts are calculated.
The following is example XML describing version information. The following is example XML describing version information.
<versions xmlns="urn:ietf:params:xml:ns:iris-transport"> <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
<transferProtocol protocolId="iris.lwz" <transferProtocol protocolId="iris.lwz"
authenticationIds="SASL/PLAIN SASL/EXTERNAL"> authenticationIds="SASL/PLAIN SASL/EXTERNAL">
<application protocolId="urn:ietf:params:xml:ns:iris1" <application protocolId="urn:ietf:params:xml:ns:iris1"
extensionIds="http://example.com/SIMPLEBAG"> extensionIds="http://example.com/SIMPLEBAG">
<dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/> <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
<dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/> <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
</application> </application>
</transferProtocol> </transferProtocol>
</versions> </versions>
5. Size Information 5. Size Information
The <responseSize> element provides a means for a server to The <size> element provides a means for a server to communicate to a
communicate to a client that a given request will exceed a negotiated client that a given request has exceeded a negotiated size
size. (<request>) or that a response to a given request will exceed a
negotiated size (<response>).
A server may indicate one of two response size conditions by A server may indicate one of two size conditions by specifying the
specifying the following child elements: following child elements:
<exceedsMaximum> - this child element simply indicates that the <exceedsMaximum> - this child element simply indicates that the
response size exceeded the negotiated response size. size exceeded the negotiated size.
<octets> - this child element indicates that the response size <octets> - this child element indicates that the size exceeded the
exceeded the negotiated response size and conveys the number of negotiated size and conveys the number of octets that is the
octets needed to provide the response. maximum for a request if the parent element is a <request> element
or the number of octets needed to provide the response if the
parent element is a <response> element.
The meaning of octets for the transfer of data is counted in
different ways for different transfer protocols. Some transfer
protocols need only to specify the octets of the data being
transfered while other transfer protocols need to account for
additional octets used to transfer the data. Specifications using
this XML Schema MUST describe how these octet counts are calculated.
The following is example XML describing size information. The following is example XML describing size information.
<responseSize xmlns="urn:ietf:params:xml:ns:iris-transport"> <size xmlns="urn:ietf:params:xml:ns:iris-transport">
<response>
<octets>1211</octets> <octets>1211</octets>
</responseSize> </response>
</size>
6. Authentication Success Information 6. Authentication Success Information
The <authenticationSuccess> element indicates that a client has The <authenticationSuccess> element indicates that a client has
successfully authenticated to a server. Along with this indication, successfully authenticated to a server. Along with this indication,
it can provide text that may be presented to a user with regard to it can provide text that may be presented to a user with regard to
this successful authentication using child <description> elements. this successful authentication using child <description> elements.
Each <description> element MUST have a 'language' attribute Each <description> element MUST have a 'language' attribute
describing the language of the content of the <description> element. describing the language of the content of the <description> element.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
Andrew L. Newton Andrew L. Newton
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Sterling, VA 20166 Sterling, VA 20166
USA USA
Phone: +1 703 948 3382 Phone: +1 703 948 3382
Email: anewton@verisignlabs.com; andy@hxr.us Email: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
Appendix A. Contributors
Substantive contributions to this document have been provided by the
members of the IETF's CRISP Working Group, especially Robert Martin-
Legene and David Blacka.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

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