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
deployed.
* 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
stream.
* 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.
11.2.3.3. Full JID ------------------- If the JID contained in the 'to' attribute is of the form <[EMAIL PROTECTED]/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 <[EMAIL PROTECTED]>. 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 myapplication 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 <[EMAIL PROTECTED]/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! Peter
smime.p7s
Description: S/MIME Cryptographic Signature
