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
