A Common Schema for Internet Registry Information Service Transfer Protocols
Extracted elements (18)
The XML Schema approach was chosen over simple bit fields and length-specified octet sequences because the status information exchanged during IRIS protocol negotiation (version, extensions, security mechanisms) is too complex for simpler encodings.
Both LWZ (RFC 4993) and XPC (RFC 4992) IRIS transfer protocols use this common XML Schema for their negotiation mechanisms, ensuring consistent capability exchange across both transports.
Application transfer protocols using this XML Schema MUST define which additional character encodings beyond UTF-8 and UTF-16 are allowed, as XML processors are obliged to recognize both UTF-8 and UTF-16.
During capabilities negotiation, if neither side can recognize the 'protocolId' of <transferProtocol> and at least one <application> and <dataModel>, an error SHOULD be given and communication ended.
Each <description> element in <authenticationSuccess>, <authenticationFailure>, and <other> MUST have a 'language' attribute, and servers MUST NOT provide multiple <description> elements with the same language descriptor.
Specifications making use of this XML Schema MUST define the identifiers for the 'type' attribute of the <other> element so clients can take differentiated actions.
Specifications using this XML Schema MUST define the identifiers for use with the <versions> element and its children, as this document defines none.
Specifications using this XML Schema MUST describe how octet counts are calculated, since different transfer protocols count octets differently (data-only vs. including framing overhead).
Unrecognized 'extensionIds' values MUST be ignored; implementations are not required to recognize extension identifiers during negotiation.
Updates or changes to the XML Schema defined in Section 3 require a document that UPDATES or OBSOLETES RFC 4991; the schema cannot be modified by lesser documents.
The <authenticationFailure> element indicates failed client authentication and may contain multilingual <description> child elements to convey failure information to users.
The <authenticationSuccess> element indicates successful client authentication. It may contain multilingual <description> child elements and an optional <data> element of type base64Binary for additional security data.
The <other> element conveys status information requiring human interpretation. It has a required 'type' attribute (an identifier for the nature of the information) and optional <description> children. Specifications MUST define the identifiers used.
The <size> element communicates to a client that a request exceeded a negotiated size (<request>) or that a response will exceed a negotiated size (<response>). It uses either an <exceedsMaximum> child (bare indication) or an <octets> child (exact count).
The <transferProtocol> element carries optional 'authenticationIds', 'responseSizeOctets', and 'requestSizeOctets' attributes identifying supported authentication mechanisms and size constraints for the associated transfer protocol.
The <versions> element describes version information about the transfer protocol, application protocol, and data models. It contains one or more <transferProtocol> child elements, each with optional <application> and <dataModel> children, identified by 'protocolId' and optional 'extensionIds' attributes.
IANA registered the XML Namespace URN 'urn:ietf:params:xml:ns:iris-transport' and the XML Schema URN 'urn:ietf:params:xml:schema:iris-transport' in the IETF XML Registry (RFC 3688).
Transfer protocols offering authentication and confidentiality SHOULD send an initial <versions> message from server to client containing all relevant authentication identifiers in 'authenticationId' to help thwart downgrade attacks.