[Standards] rfc3920bis -06

Dirk Meyer dmeyer at tzi.de
Fri Jul 4 09:28:44 CDT 2008


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
  <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? 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
  <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


Dirk

-- 
Wake up and smell the coffee.
		-- Ann Landers


More information about the Standards mailing list