mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
RFC 4648
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@615 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
08284aaada
commit
cfe969efd8
@ -164,7 +164,7 @@
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>The data to send is included as XML character data of the <data/> element after being encoded as Base64 as specified in Section 3 of &rfc3548;. The 'seq' attribute is a 16-bit unsigned integer counter starting at 0, and MUST be incremented for each packet sent. Thus, the next packet sent should have a 'seq' of 1, the one after that with a 'seq' of 2, and so on. The counter loops at maximum, so after value 65535, 'seq' MUST start again at 0.</p>
|
||||
<p>The data to send is included as XML character data of the <data/> element after being encoded as Base64 as specified in Section 4 of &rfc4648;. The 'seq' attribute is a 16-bit unsigned integer counter starting at 0, and MUST be incremented for each packet sent. Thus, the next packet sent should have a 'seq' of 1, the one after that with a 'seq' of 2, and so on. The counter loops at maximum, so after value 65535, 'seq' MUST start again at 0.</p>
|
||||
|
||||
<p>Note that in the case of iq stanzas, the recipient must reply with an iq of type 'result'.</p>
|
||||
<example caption='Acknowledging data using iq'><![CDATA[
|
||||
@ -251,7 +251,7 @@
|
||||
|
||||
<section1 topic='Security Considerations'>
|
||||
<p>In-Band Bytestreams is as secure as the underlying Jabber transport. The bytestream application could have its own security layer, but this is outside of the scope of IBB.</p>
|
||||
<p>An entity MUST verify any Base64 data received. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the Base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of Base64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g. "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. Base64 encoding MUST follow the definition in Section 3 of RFC 3548.</p>
|
||||
<p>An entity MUST verify any Base64 data received. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the Base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of Base64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g. "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. Base64 encoding MUST follow the definition in Section 4 of RFC 4648.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations'>
|
||||
|
||||
@ -185,7 +185,7 @@ WWW-Authenticate: Digest realm="xmpp",
|
||||
</ol>
|
||||
<p>The Authorization Request process is described in the following subsections.</p>
|
||||
<section3 topic='Basic Access Authentication Scheme' anchor='http-authz-basic'>
|
||||
<p>The Basic Access Authentication scheme is defined in <cite>RFC 2617</cite>. This scheme specifies that the authorization information shall consist of a userid and password, separated by a ':' character and then encoded using Base64. When the realm is "xmpp", the profile defined herein further specifies that the userid MUST be a valid JID as described above, that the password entity MUST be a transaction identifier as described above, that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of &rfc3986; prior to Base64 encoding, and that Base64 encoding MUST adhere to Section 3 of &rfc3548;.</p>
|
||||
<p>The Basic Access Authentication scheme is defined in <cite>RFC 2617</cite>. This scheme specifies that the authorization information shall consist of a userid and password, separated by a ':' character and then encoded using Base64. When the realm is "xmpp", the profile defined herein further specifies that the userid MUST be a valid JID as described above, that the password entity MUST be a transaction identifier as described above, that any character in the JID or transaction identifier that is outside the range of the US-ASCII coded character set MUST be transformed into a percent-encoded octet as specified in Section 2.1 of &rfc3986; prior to Base64 encoding, and that Base64 encoding MUST adhere to Section 4 of &rfc4648;.</p>
|
||||
<p>(Refer to <cite>RFC 2617</cite> for specification of the syntax of the Basic Access Authentication scheme; that information is not duplicated here.)</p>
|
||||
<example caption='HTTP Client Makes Basic Authorization Request'><![CDATA[
|
||||
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
||||
|
||||
@ -259,7 +259,7 @@
|
||||
IMAGE DATA
|
||||
</data>
|
||||
]]></code>
|
||||
<p>The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 3 of &rfc3548;. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)</p>
|
||||
<p>The XML character data MUST represent the image data for the avatar with a content-type of "image/png", Base64-encoded in accordance with Section 4 of &rfc4648;. (Note: Line feeds SHOULD NOT be added but MUST be accepted.)</p>
|
||||
<p>Support for the <data/> element is REQUIRED.</p>
|
||||
</section2>
|
||||
<section2 topic='Metadata Element' anchor='proto-meta'>
|
||||
|
||||
@ -237,7 +237,7 @@
|
||||
<li><p>Calculate: He = SHA256(e) (see &nistfips180-2;)</p></li>
|
||||
</ol>
|
||||
<p>Note: The last step is not necessary for 3-message negotiations.</p>
|
||||
<p>Alice MUST send all her calculated values of 'He' (for 4-message negotiations) or 'e' (for 3-message negotiations) to Bob (in the same order as the associated MODP groups are being sent). She MUST also specify randomly generated Base64 encoded (in accordance with Section 3 of &rfc3548;) value of &NsubA; (her ESession ID).</p>
|
||||
<p>Alice MUST send all her calculated values of 'He' (for 4-message negotiations) or 'e' (for 3-message negotiations) to Bob (in the same order as the associated MODP groups are being sent). She MUST also specify randomly generated Base64 encoded (in accordance with Section 4 of &rfc4648;) value of &NsubA; (her ESession ID).</p>
|
||||
<example caption='Initiates a 4-message ESession Negotiation'><![CDATA[
|
||||
<message from='alice@example.org/pda' to='bob@example.com'>
|
||||
<thread>ffd7076498744578d10edabfe7f4a866</thread>
|
||||
|
||||
@ -81,7 +81,7 @@
|
||||
<p>This protocol requires multimedia to be included within &xep0004;. This section defines a new namespace ('urn:xmpp:media') for that purpose. The root element for the namespace is <media/>. It MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.</p>
|
||||
<p>If the media is an image or video then the <media/> element SHOULD include 'width' and 'height' attributes specifying the recommended display size of the media in pixels.</p>
|
||||
<p>The <media/> element SHOULD contain at least one <uri/> element to specify the out-of-band location of the media data. <note>Constrained execution environments prevent some clients rendering media unless it has been received out-of-band (e.g., Web clients).</note> The <uri/> element MUST contain a URI that indicates the location.</p>
|
||||
<p>The <media/> element MAY also contain one or more <data/> elements for distributing the media in-band. The <data/> element MUST contain the Base64 encoded (in accordance with Section 3 of &rfc3548;) media data. The <em>encoded</em> data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one <data/> element then the sending entity MUST take care not to trigger karma limits.</p>
|
||||
<p>The <media/> element MAY also contain one or more <data/> elements for distributing the media in-band. The <data/> element MUST contain the Base64 encoded (in accordance with Section 4 of &rfc4648;) media data. The <em>encoded</em> data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one <data/> element then the sending entity MUST take care not to trigger karma limits.</p>
|
||||
<p>Each <uri/> or <data/> element MUST include a 'type' atribute that specifies the MIME type (see &rfc2045;) of the media.</p>
|
||||
<example caption='Audio Media Element'><![CDATA[
|
||||
<media xmlns='xmlns='urn:xmpp:media'>
|
||||
|
||||
@ -247,7 +247,7 @@
|
||||
</li>
|
||||
<li>
|
||||
<p>Generate the whole serialized <em>content</em> of the <c/> element:</p>
|
||||
<p>If there is encrypted XML content, the XML MUST include the Base64 encoded (even if the block cipher algorithm 'none' was agreed <note>The content is encoded even if no encryption is used to avoid triggering namespace errors when entities parse the XML.</note>, in accordance with Section 3 of &rfc3548;) value of m_final wrapped in a <data/> element.</p>
|
||||
<p>If there is encrypted XML content, the XML MUST include the Base64 encoded (even if the block cipher algorithm 'none' was agreed <note>The content is encoded even if no encryption is used to avoid triggering namespace errors when entities parse the XML.</note>, in accordance with Section 4 of &rfc4648;) value of m_final wrapped in a <data/> element.</p>
|
||||
<p>Only if Alice has received stanzas containing a <key/> element (see <link url='#rekey'>Re-Key Exchange</link>) from Bob since she sent her last stanza then the XML MUST include the (positive, non-zero) number of such stanzas she has received (since she sent her last stanza) wrapped in a <new/> element.</p>
|
||||
<p>The content may also contain one <key/> element (see <link url='#rekey'>Re-Key Exchange</link>) and one or more <old/> elements (see <link url='#publish'>Publishing Old MAC Values</link>).</p>
|
||||
<p>Alice MUST normalize the content by removing any whitespace from the serialized content (i.e. remove all character data from <em>between</em> all elements). Note: <c/> elements are so simple that there should <em>never</em> be a need to convert the XML to canonical form.</p>
|
||||
|
||||
1
xep.ent
1
xep.ent
@ -399,6 +399,7 @@
|
||||
<!ENTITY rfc4566 "<span class='ref'>RFC 4566</span> <note>RFC 4566: SDP: Session Description Protocol <<link url='http://tools.ietf.org/html/rfc4566'>http://tools.ietf.org/html/rfc4566</link>>.</note>" >
|
||||
<!ENTITY rfc4622 "<span class='ref'>RFC 4622</span> <note>RFC 4622: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <<link url='http://tools.ietf.org/html/rfc4622'>http://tools.ietf.org/html/rfc4622</link>>.</note>" >
|
||||
<!ENTITY rfc4646 "<span class='ref'>RFC 4646</span> <note>RFC 4646: Tags for Identifying Languages <<link url='http://tools.ietf.org/html/rfc4646'>http://tools.ietf.org/html/rfc4646</link>>.</note>" >
|
||||
<!ENTITY rfc4648 "<span class='ref'>RFC 4648</span> <note>RFC 4648: The Base16, Base32, and Base64 Data Encodings <<link url='http://tools.ietf.org/html/rfc4648'>http://tools.ietf.org/html/rfc4648</link>>.</note>" >
|
||||
<!ENTITY rfc4732 "<span class='ref'>RFC 4732</span> <note>RFC 4732: Internet Denial-of-Service Considerations <<link url='http://tools.ietf.org/html/rfc4732'>http://tools.ietf.org/html/rfc4732</link>>.</note>" >
|
||||
<!ENTITY rfc4733 "<span class='ref'>RFC 4733</span> <note>RFC 4733: RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals <<link url='http://tools.ietf.org/html/rfc4733'>http://tools.ietf.org/html/rfc4733</link>>.</note>" >
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user