XMPP 3920 Most reliable Chinese translation documents (II.)

XMPP 3920 Most reliable Chinese translation documents (ii) 2009-10-17 19:52

XML stream 4.1 Overview Structured information that enables fast, asynchronous exchange-related small loads between presence-aware entities can have two basic elements: XML streams and XML sections. The terms are defined as follows: XML Stream definition: An XML stream is a container for exchanging XML elements between any two entities on a network. The beginning of the XML stream is represented by a starting xml<stream> tag (with the appropriate attribute and namespace declaration), and the end of the XML stream is represented by an ending xml</stream> tag. In the lifecycle of a stream, the entity that initializes it can send a very high number of XML elements, elements and XML sections (defined here, <message/&gt, <presence/>, or <iq/> The element is validated by the default namespace is used for negotiation flows (example: Negotiate the use of TLS (section 5th) or use SASL (sect. 6th)). The initial stream is negotiated from the initial entity (usually a client or server) to the receiving entity (usually a server) and is considered consistent with the session from the initial entity to the receiving entity. The initial flow can be one-way communication from the initial entity to the receiving entity, and the receiving entity must negotiate a stream in the opposite direction ("response flow") in order to exchange information from the receiving entity to the initial entity. XML Section definition: An XML section is a discontinuous structured information semantic unit that is sent from one entity to another through an XML stream. The XML section exists as a direct child of root </stream> if it matches product [43] content [XML], it can be well balanced. The beginning of any XML section is clearly represented by the start tag element of an XML stream with a depth of 1 (for example,:<presence>), and the end of the XML section is clearly represented by the corresponding closing tag with a depth of 1. To transmit the desired information, an XML section may contain the necessary child elements (with attributes, elements, XML character data). The only XML section defined here is the <message/>,<presence/>,<iq/> element, validated by the default namespace of the stream, described in the XML section (section 9th), and Transport-layer Security (tls:transport Layer security) Negotiation, SASL negotiation, or Server callback (8th section) of the XML element sent is not considered as an XML section. Consider a client-server session example. In order to connect to the server, the client must initialize an XML stream: Send a starting <stream> tag to the service, optionally before a text declaration with a specified XML version (the contents of the reference text declaration (11.4), or a character encoding (11.5)). Subject to the local policy and the services provided, the server should then revert to another XML stream to the client, again optionally before a text declaration. Once the client completes the SASL Negotiation (section 6th), the client can send a very high number of XML sections to any container on the network through streaming. When the client wants to close the stream, it simply sends a shutdown </stream> tag to the server (or the server can shut down the stream), from which the client and the server should terminate the potential connection (usually a TCP connection). People who are accustomed to thinking of XML as document-centric might want to see the client-server session as part of a two-end open (freely-answered) XML document: one from the client to the server and the other from the server to the client. From this perspective, the root <stream/> element can be considered a document entity for each "document", and two "documents" are created by the aggregation of XML sections sent through two XML streams. However, this view is only a convenience; XMPP is not documented, but is handled in XML streams or XML sections. In essence, then, an XML stream acts as an envelope for all XML sections sent through the session. A simple diagram can be used to represent the following: |--------------------| | <stream> | |--------------------| | <presence> | | <show/> | | </presence> | |--------------------| | <message to= ' foo ' > | | <body/> | | </message> | |--------------------| | <iq to= ' Bar ' > | | <query/> | | </iq> | |--------------------| | ...                       | |--------------------| | </stream> | |--------------------| 4.2 Binding to TCP Although it is not necessary to bind an XML stream to a [TCP] connection (for example, two entities can interconnect with each other, such as [HTTP] voting mechanisms), this description also defines only XMPP to TCP bindings. In the context of client to server-side communication, the server must allow the client to send a shared single TCP connection to the XML section from the client to the server to the client. In the context of server to server communication, the server must use a TCP connection for the transfer of the XML section from the server to its peer server, and another TCP connection (which is initialized by peer) to transfer the XML section of the server to the server, with a total of two TCP connections. 4.3 Flow security When negotiating an XML stream in XMPP1.0, TLS should be used as defined by the TLS application (section 5th), and SASL must be used as defined in SASL (sect. 6th). The "initial stream" (for example, the stream from the initial entity to the receiving entity) and the response flow (for example, streams from the receiving entity to the initial entity) must be protected separately, even though two-way security may have been established through mutual authentication mechanisms. An entity should not attempt to send an XML section (section 9th) through a stream before the stream is authenticated, but if so, other entities are not allowed to accept such sections, and should return a <non-authorized/> flow error and terminate both the XML stream and the potential TCP connection; note , this applies only to XML sections (for example: <message/>, <presence/>, <iq/> elements, Checked by the default namespace does not apply to flow negotiation (for example, an XML element used to negotiate the use of TLS (section 5th) or use SASL (sect. 6th)). 4.4 Flow Properties The flow element properties are as follows: 1 The to-' to ' attribute should be used only from the initial entity to the XML stream header of the receiving entity, and must be set to a host name that receives the entity service. The ' to ' attribute should not be located in the XML stream header of the receiving entity responding to the initial entity; however, if the ' to ' attribute is included, it should be silently ignored by the initial entity. 2 The from-' from ' attribute should be used only from the receiving entity to the XML stream header of the initial entity, and must be set to a host name that receives the entity service that is authorized to access the initial entity. The ' from ' attribute should not be sent to the stream header of the receiving entity by the initial entity, however, if the ' from ' attribute is included, it should be ignored by the receiving entity. 3 The id-' id ' attribute should be used only from the receiving entity to the XML stream header of the initial entity. This property is the only one created by the receiving entity that is the key to the session between the initial entity stream and the receiving entity, and is unique in the receiving application (usually a server). Note: The stream ID may be strictly secure, and must therefore be unpredictable and repeatable (refer to [RANDOM] recommendation for a random security perspective). The ' id ' attribute should not be in the header of the XML stream from the initial entity to the receiving entity, however, if the ' id ' attribute is included, it should be ignored by the receiving entity. 4 the xml:lang-' Xml:lang ' attribute (defined in [XML] 12.2) should be included in the initial flow header of the initial entity to specify the default language, which can be any human-readable XML character data sent through the stream. If the attribute is included, the receiving entity should remember this value as the default value for the initial stream and the response stream, and if this property is not included, the receiving entity should use a configurable default value for the two streams, and it must communicate in the header for the response stream. For all sections sent through the initialization stream, if the initial entity does not contain the ' Xml:lang ' attribute, the receiving entity should apply the default value, and if the initial entity contains the ' Xml:lang ' attribute, the receiving entity is not allowed to modify or delete it (reference Xml:lang (9.1.5)). The ' Xml:lang ' attribute value must be a nmtoken (defined in [XML] (2.3)) and must be consistent with the format defined in Rfc3006[langtags]. 5 The version-version attribute appears set to at least "1.0" signal value and supports the associated flow protocol (including flow characteristics) defined in the specification. The specific rules for surrogate and attribute processing are defined as follows: Can be summarized as follows: |   Initiating to receiving | Receiving to initiating ---------+---------------------------+----------------------- to |   Hostname of Receiver | Silently ignored from |   Silently ignored | Hostname of receiver ID |   Silently ignored | Session key Xml:lang |   Default language | Default language Version |   Signals XMPP 1.0 Support | Signals XMPP 1.0 Support 4.4.1 Version Support The XMPP version is specified here as "1.0", in particular, which encapsulates the flow-related protocol (TLS application (5), SASL application (6), stream error (4.7)), and three defined XML node types (&LT;MESSAGE/&GT;, <presence/> and <iq/>) semantics. The XMPP version of the numbering scheme is "<major>.<minor>". Major and minor numbers must be treated as separate integers, and each number may not increase by a single digit. So "XMPP 2.4" is a lower version than "XMPP 2.13", which is below "XMPP 12.3" in turn. Leading 0 (for example: "XMPP 6.01") must be ignored by the receiver and not sent. Major version number should be increased, as long as the flow and section format or required behavior has changed to a large extent, so that the old version if it does not understand and take the action specified in the old version of the description, simply ignore the elements and attributes can not interoperate with the new version of the entity, you need to increase the major version number. The minor version number refers to the new capability and must be ignored by an entity with a smaller minor version number, but is used for informational purposes by an entity with a larger version number. For example: the minor version number may refer to processing messages, attendance, or the IQ section of the newly defined ' type ' attribute value; an entity with a larger version number will simply notice that its communicator does not understand this ' type ' attribute value and therefore does not send it. The following rules are applied by the implementation to the ' version ' attribute generated and processed in the stream header: 1 The initial entity must set the version attribute value to its supported maximum version number in the initial stream header (for example, if the highest version number that it supports is defined in this description, the value must be set to "1.0") 2 The receiving entity must set the Version property value in the response flow header or the value provided by the initial entity, or the highest version number supported by the receiving entity, whichever is lower. The receiving entity must make a numeric comparison of the primary and minor versions, rather than a "<major>.<minor>" string match. 3 if the version number contained in the response stream header is lower than the version number contained in the initial stream header, and the new version entity cannot interoperate with the old version as described above, the initial entity should produce a <unsupported-version/> flow error. and terminates the XML stream with a potential TCP connection. 4 if each entity receives a stream header with the "No version number" attribute, the entity must consider that the supported version of the other entity will be "0.0" and should not include the ' version ' attribute when sending the response stream. 4.5 namespace declaration The flow element must have a flow namespace declaration and a default namespace declaration (the namespace declaration definition is in the XML namespace description document [Xml-names]). For more detailed information about the flow namespace and the default namespace, look at the namespace name and prefix (11.2). 4.6 Flow characteristics If the initialization entity contains a version attribute and the value is set at least to "1.0" in the initial stream header, then the receiving entity must send a <features/> child element (prefixed by the stream namespace prefix) to the initial entity. To announce any flow-level characteristics that can be negotiated (or otherwise required to be advertised). Currently, this is only used for advertising in this definition of TLS application (5), SASL application (6) and resource bindings (7), and the session is established in accordance with the definition defined in [Xmpp-im], however, the functionality of the streaming feature can be used to advertise other features that can be negotiated in the future. If the entity does not understand or support certain features, then it should be silently ignored. If one or more security features (for example, TLS and SASL) need to be negotiated successfully before the security features (e.g., resource bindings) are provided, the security-related features should not be advertised in the streaming feature before the relevant security features are negotiated. 4.7 Stream Error The root flow element may contain a <error/> child element prefixed by the stream namespace prefix. If the error child element senses a stream level error, it must be sent by a compatible entity (usually a server rather than a client). 4.7.1 Rules The following rules apply to stream-level errors: 1 The assumption that all stream level errors are unrecoverable; Therefore, if an error occurs at the stream level, the entity that detects the error must send a stream error to the other entity, send a close </stream> tag, and terminate the potential TCP connection. 2 If an error occurs during the creation of the stream, the receiving entity must always send the start <stream> tag, the <error/> element as a child element of the flow element, send a closing </stream> tag, and terminate the potential TCP connection. In this case, if the initial entity provides an unknown host in the ' to ' attribute (or does not provide the ' to ' attribute at all), the server should provide the server's authorized host name in the ' from ' attribute of the stream header and send it before terminating. 4.7.2 syntax The stream error syntax is as follows: <stream:error> <defined-condition xmlns= ' Urn:ietf:params:xml:ns:xmpp-streams '/> <text xmlns= ' Urn:ietf:params:xml:ns:xmpp-streams ' xml:lang= ' Langcode ' > OPTIONAL Descriptive text </text> [OPTIONAL application-specific condition element] </stream:error> <error/> elements: 1 must contain a child element that is consistent with one of the defined section error conditions defined below; This element must be considered qualified by the ' Urn:ietf:params:xml:ns:xmpp-streams ' namespace. 2 May contain a <text/> child element that contains the XML character data that describes the error in more detail; This element must be ' Urn:ietf:params:xml:ns: The Xmpp-streams ' namespace is considered qualified and should have a ' Xml:lang ' attribute to indicate the natural language of the XML character data. 3 may contain a child element that describes the special application error condition; This element must be authenticated by a defined application namespace, and its structure is defined by that namespace. The <text/> element is optional. If this element is included, it should be used only to provide descriptive or diagnostic information to supplement a defined condition or the meaning of a particular application condition, and it should not be described in a programmatic form by an application. It should not be presented as an error message to a user, but may otherwise display an error message that is related to the containing conditional element (or element). 4.7.3 defined criteria The flow-level error conditions are defined below: 1 <bad-format/>--entities that have sent XML cannot be processed; This error may be used in place of more specific XML-related errors, such as: <bad-namespace-prefix/>, <invalid-xml/ ", <restricted-xml/>, <unsupported-encoding/>, <xml-not-well-formed/&gt, although more special errors are preferred. 2 The <bad-namespace-prefix/>--entity has sent an unsupported namespace prefix, or has sent a prefix with no namespace in an element that requires such a prefix (reference to the XML namespace name and prefix (11.2)). 3 The <conflict/>--server is shutting down the active stream for the entity because a new stream that has already been initialized conflicts with an existing stream. 4 <connection-timeout/>--a period of time (configurable according to local Service policy) the entity does not generate any traffic through the stream. 5 6 7) <improper-addressing/>--A section sent between two servers, missing ' to ' or ' from ' attribute (or no value for this property) 8 The <internal-server-error/>--server has experienced an incorrect configuration or other undefined internal error to render the service unavailable. 9 <invalid-from/>--The Jid or host name provided in the ' from ' address does not match an authorized Jid or a valid domain negotiation, which is negotiated between a negotiation between a SASL or a callback server, or a client that is authorized to bind to a resource. The <invalid-id/>--stream ID or callback ID is invalid or does not match the previously supplied ID. <invalid-namespace/>--Stream namespace name is not just http://etherx.jabber.org/streams, or callback namespace name is not just "jabber:server:dialback" (Reference XML namespace name and prefix (11.2)) <invalid-xml/>--entity sent an invalid XML (reference validation (11.3)) through the server to which the validation was performed. The <not-authorized/>--entity attempts to send data before the stream is authenticated, or does not authorize the activity of a related flow negotiation, and the receiving entity is not allowed to process the offending section before sending a stream error. <policy-violation/>--entity violates some local policies, the server may choose to specify a policy in the <text/> element or the special-application criteria element. <remote-connection-failed/> servers are not properly connected to remote entities and require authentication or authorization. <resource-constraint/> the server lacks the necessary system resources to provide the service to the stream. <restricted-xml/> entity attempts to send restricted XML features such as commentary, processing introduction, DTD, entity reference, or reserved character (reference (11.1)). <see-other-host/> server will not provide service to the initial entity, but is being redirected to another host; the server should specify a replacement hostname or IP address (must be a valid domain identifier) as a <see-other-host/> The XML character data for the element. <system-shutdown/> the server is closed and all active streams are closed. <undefined-condition/> error condition is one of the other defined conditions in this list, and this error condition should only be used in conjunction with a special-application condition. <unsupported-encoding/> the initial entity has been encoded in a stream that is not supported by the server (11.5) <unsupported-stanza-type/> the initial entity has sent a first-level sub stream that is not supported by the server. <unsupported-version/> The Version property value provided by the initial entity in the stream header specifies a XMPP version that is not supported by the server, and the server may specify the version it supports in the <text/> element. <xml-not-well-formed/> the initial entity has sent non-standard XML, and the standard XML is defined by [XML]. 4.7.4 Special Application Conditions Note that an application may provide special application flow error information by including an appropriate namespace child element in the error element. Special application elements should supplement or further validate a defined element. So the,<error/> element will contain two to three child elements: <stream:error> <xml-not-well-formed xmlns= ' Urn:ietf:params:xml:ns:xmpp-streams '/> <text xml:lang= ' en ' xmlns= ' urn:ietf:params:xml:ns:xmpp-streams ' > Some Special Application Diagnostic information! </text> <escape-your-data xmlns= ' Application-ns '/> </stream:error> </stream:stream>

Http://hi.baidu.com/xboxsky/blog/item/d76af703b42afee609fa930e.html