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? 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 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. 5.3.3. id ---------- I had no time to read everything, where is that id needed later? 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. 8.6.2. Binding an Additional Resource -------------------------------------- I see that multiple resource bindings are now included. 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> 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 my application crashes. Does the result go to a different entity? 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). 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 Dirk -- Wake up and smell the coffee. -- Ann Landers