[Standards] rfc3920bis -06

Peter Saint-Andre stpeter at stpeter.im
Mon Jul 7 15:24:45 UTC 2008

Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> I've just submitted version -06 of draft-saintandre-rfc3920bis to the
>> IETF. This version incorporates feedback from Joe Hildebrand, as well
>> as my own near-final review and consistency check.
>> Read it here:
>> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html
>> I'm starting to get serious about pushing this forward at the IETF, so
>> I'd really appreciate reviews from folks on this list.
> Is there a list of new features compared to RFC 3920? 

There is a changelog in Appendix F. I paste it here for convenience:


     * Corrected the ABNF syntax for JIDs to prevent zero-length node 
identifiers, domain identifiers, and resource identifiers.
     * Corrected the nameprep processing rules to require use of the 
UseSTD3ASCIIRules flag.
     * Recommended or mandated use of the 'from' and 'to' attributes on 
stream headers.
     * More fully specified stream closing handshake.
     * Specified recommended stream reconnection algorithm.
     * Specified return of <restricted-xml/> stream error in response to 
receipt of prohibited XML features.
     * Specified that SASL mechanisms must be sent both before and after 
negotiation of SASL security layers.
     * Specified that TLS plus SASL PLAIN is a mandatory-to-implement 
technology for client-to-server connections, since implementation of 
SASL EXTERNAL is uncommon in XMPP clients, in part because underlying 
security features such as end-user X.509 certificates are not yet widely 
     * Added the <account-disabled/>, <credentials-expired/>, 
<encryption-required/>, <malformed-request/>, and <transition-needed/> 
SASL error conditions to handle error flows mistakenly left out of RFC 
3920 or discussed in RFC 4422 but not in RFC 2222.
     * More fully specified binding of multiple resources to the same 
     * Added the <unknown-sender/> stanza error condition to provide 
appropriate handling of stanzas when multiple resources are bound to the 
same stream.
     * Added the <not-modified/> stanza error condition to enable 
potential ETags usage.
     * Removed unnecessary requirement for escaping of characters that 
map to certain predefined entities, which do not need to be escaped in XML.
     * More clearly specified well-formedness requirements.
     * Moved historical documentation of the server dialback protocol 
from this specification to a separate specification maintained by the 
XMPP Standards Foundation.


So you can see that the modifications are more along the line of 
corrections and amplifications, not new features.

> Here some
> feedbacks whithout re-reading everything:
> Basic Question
> --------------
> I always wondered why starttls and sasl are stanzas and bind uses the
> iq stanza. Is there a reason why starttls is no iq stanza?
> | C -> <iq type='set'>
> |          <starttls/>
> |      </iq>
> | S -> <iq type='result'/>

The reasons are lost in the mists of time, but go back as far as 
XEP-0034 and XEP-0035 in June 2002 (before the XMPP WG was formed).

> The same is true for presence (in RFC 39210. I found the presence
> handling much too complicate to implement. It took me longer than
> adding PubSub and XTLS support.

Yes, presence is complex. Sorry about that. Did you implement it in a 
server or a client?

> 5.3.3.  id
> ----------
> I had no time to read everything, where is that id needed later?

The id is used in server dialback. In the future it may also be used in 
other stream-related technologies as well.

> 5.7.3.  Handling of Idle Streams
> --------------------------------
> I did not following the discussion, but should this in an RFC?
> XEP-0199 looks like a much cleaner way and even if many client use the
> whitespace ping, it is more like a bad hack, there isn't even a ping
> responce.

You are right that the "whitespace ping" is not a true ping. Because 
this specification defines the TCP binding, I thought it was appropriate 
to mention whitespace pings here. Note that the spec says only that 
whitespace pings are the typical method for determining whether the 
stream is idle. The spec does not say that an implementation MUST, 
SHOULD, or MAY implement whitespace pings.

> 8.6.2.  Binding an Additional Resource
> --------------------------------------
> I see that multiple resource bindings are now included. 

They were "implicit" before but not well specified.

> But IMHO it
> could be done simpler. If I understand it correctly when I want to
> bind three resources I have to send three bind-iq and wait for the
> answer. Why not use:
> | C: <iq id='bind_2' type='set'>
> |      <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
> |        <resource>balcony</resource>
> |        <resource>home</resource>
> |      </bind>
> |    </iq>

That operation is not atomic. What if one of the resources can be bound 
but others fail? Does the server bind the ones that succeed but not bind 
the ones that fail? What error condition is returned? Also, including 
multiple <resource/> children is not backwards compatible with current 
handling and schema for the <bind/> element.

>  Full JID
> -------------------
>   If the JID contained in the 'to' attribute is of the form
>   <node at domain/resource> and there is no connected resource that exactly
>   matches the full JID, the stanza shall be processed as if the JID were
>   of the form <node at domain>.
> Is this also true for IQ stanzas? That would be very confusing if I
> query one entity for services and send something to it, it is gone and
> some other entity gets it. What happens if I send a get-IQ and my
> application crashes. Does the result go to a different entity? 

No, it doesn't, because IQs to the bare JID are handled by the server 
itself on behalf of the bare JID, not delivered to another resource.

> If my
> application uses the full JID it has a reason to do so. I also would
> prefer the same for messages (which I can get with XEP-0079).

What is "the same" here?

>   If the JID contained in the 'to' attribute is of the form
>   <node at domain/resource> and there is a connected resource that
>   exactly matches the full JID, the server SHOULD deliver the stanza
>   to that connected resource.
> I would prefer MUST

It needs to be a conditional MUST, because the server MUST NOT deliver a 
message stanza to you if:

1. According to XEP-0016 you are blocking messages from the sender.

2. According to RFC 3920 your resource has negative presence priority.

Those are outside the scope of RFC 3920, but we'd need to word the MUST 
so that such uses are allowed.

I think the stanza handling rules need to be clarified a bit more and I 
will do that in version -07 of rfc3920bis.

Thanks for the review!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080707/358e6440/attachment.bin>

More information about the Standards mailing list