Subject: [xmpp] WGLC Comments on draft-ietf-xmpp-3920bis-08

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Jun 2010 17:33:31 -0500

Hi,

Here are some WGLC comments on draft-ietf-xmpp-3920bis-08. 

I realize this is a "bis" draft, and some of my comments may really apply to 3920 text that we elected not to fix. When that's the case with specific comments, I do not object in general. If I were more productive, I would have checked all this against a diff, but I'm running out of time and don't feel right extending the WGLC just for myself :-)

Also, please forgive the weird format. I experimented with using a PDF annotation tool on my iPad, and this is roughly based on its output. The page numbers are relative to the PDF version available at http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-08 . I added the section numbers in to hopefully make things easier to find.

Thanks!

Ben.

-------------------------------

Substantive Comments:

Page 19 (Section 3.4, 2nd bullet) :
 Content: "The time that expires before an entity first seeks to reconnect MUST be randomized"
 Comment: Can we offer guidance on a reasonable range of randomness?

Page 29 (4.3.3, 2nd paragraph):
 Content: "a TCP 
connection from going idle or for detecting an idle TCP connection is 
to send a space character (U+0020) over the TCP connection between"
 Comment: What does it mean for a tcp stream to go idle? Are we talking around the idea of nat bindings expiring?

Page 29 (4.3.3, 2nd paragraph):
 Content: "however, it is RECOMMENDED that any such test be performed 
not more than once every 60 seconds."
 Comment: Does it make sense to recommend the same for all types of keepalives? Every 60 seconds could be quite a lot for a heavier weight transaction response mechanism. Also, do any of the referenced docs offer guidance on selecting the mechanisms?

Page 37 (4.5.1, 2nd paragraph) :
 Content: "SHOULD be <invalid-namespace/> but 
MAY be <bad-format/>."
 Comment: Why the choice? When would you want to use the second?

Page 67 (6.2.1) :
 Content: "SASL as mandatory-to-negotiate."
 Comment: Does this conflict with the SHOULD include the SASL stream feature in the previous section?

Page 74 (6.3.5, last para) :
 Content: "SHOULD be <policy-violation/> but MAY be <not-authorized/>)."
 Comment: Why the choice?

Page 88 (8.1.2.1, list item 4) :
 Content: "4. When the server generates a stanza from the server itself for 
delivery to the client, the stanza MUST include a ’from’ 
attribute whose value is the bare JID (i.e., <domain>) of the 
server."
 Comment: Any guidance for what domain to use if the server supports multiple domains?

Page 110 (8.4) :
 Content: "Extended Content"
 Comment: What are the expectations about how one specifies an extension? For example, does it require an RFC, a XEP, etc?

Page 112 (8.5) :
 Content: "If an entity receives a stanza that exceeds its maximum stanza size, 
it MUST return a <not-acceptable/> stanza error."
 Comment: Is there a way to indicate the size limit in the error, so the sender can correct its behavior?

Page 127 (11.1, last para) :
 Content: "SHOULD be <restricted-xml/> but MAY be <bad-format/>."
 Comment: Why the choice?

Page 137 (13.7.2.1.1, sub-case 2) :
 Content: "give the user the choice of 
terminating the connecting or accepting the certificate 
temporarily (i.e., for this connection attempt only) or 
permanently (i.e., for all future connection attempts) and then"
 Comment: I read this to say that, if you give the user any choice at all, you MUST offer the option of shooting oneself in the foot. Is that the intent?

Page 137 (13.7.2.1.1, sub-case 2):
 Content: "client MUST cache the certificate"
 Comment: Should we require a mechanism to allow users to revoke trust for such caches certs?

Page 138 (13.7.2.1.1, sub-case 3) :
 Content: "The server’s certificate includes no presented identity 
that matches the reference identity to which the entity attempted 
to connect but a human user has permanently accepted the"
 Comment: This needs to be associated with the identity the use was trying to reach when she accepted the cert in the first place, right? That is, if some other server offers the same cert, it's not automatically accepted, right?

Page 138(13.7.2.1.1, sub-case 3) :
 Content: "MUST notify 
the user if the certificate has changed."
 Comment: Does cert expiration count as change in this context?

Page 148 (15) :
 Content: "15. Conformance Requirements"
 Comment: This. Is impressive. You're setting a high bar for everyone else :-)

Page 174 (Appendix E):
 Content: "Appendix E. Copying Conditions"
 Comment: How does this section interact with the bcp 78 boilerplate? Which wins in case of a perceived conflict?

Editorial Comments:

Page 11 (1.4, para 4) :
 Content: "With regard to XML stanzas or parts thereof, the term "silently 
ignore" means (1) for a routing entity (typically a server) to route 
the data unmodified to another server or to deliver the data 
unmodified to a client, or (2) for a client to discard the data 
without presenting it a human user or associated application."
 Comment: I'm not sure the average implementor would take "forward unchanged" as the common meaning for "silently ignore" for servers. We can redefine this, but that won't make readers check the glossary for terms that they think they already understand.

Page 12 (Section 1.6) :
 Content: "1.6. Discussion Venue"
 Comment: Will this stay in in the RFC version?

Page 13 (2.1, last sentence) :
 Content: "Because the formal 
specification of the XMPP address format depends on 
internationalization technologies that are in flux at the time of 
writing, the format is defined in [XMPP-ADDR] instead of this 
document."
 Comment: Do we want this statement to live for all time? It will hopefully become dated before too long.

Page 19 (3.4, 3rd bullet):
 Content: "exponential backoff 
principle."
 Comment: Can you offer a reference for this principle?

Page 26 (4.2.7, para 1) :
 Content: "non-normative state
chart"
 Comment: Looks more like a flow chart than a state diagram to me. (Just saying… :-) )

Page 68 (6.2.3) :
 Content: "try SASL mechanisms in the order of
try SASL mechanisms in the order of their perceived strength."
 Comment: Is "perceived strength" a fancy way of saying local policy? Otherwise I'm not sure how implementations go about perceiving strength.

Page 102 (8.3.3.13, para 1):
 Content: "the servive);"
 Comment: Spelling

Page 131 (13.6, para 2) :
 Content: "Service provisioning 
SHOULD use strong security, subject to local security policies."
 Comment:  I'm not sure how to interpret this. Doesn't the first clause suggest that local policy should use  strong security? Adding the local policy disclaimer seems to render something to the effect of "local policy SHOULD require strong security unless it doesn't."

Page 133 (13.7.1.2.1) :
 Content: "A server’s domainpart SHOULD be represented as an SRVName, i.e., as 
an otherName field of type "id-on-dnsSRV" as specified in [X509-SRV]."
 Comment: Should subjectAltName be mentioned here?

---

From: Paul Aurich <[email-masked]>
Date: Tue, 08 Jun 2010 16:34:38 -0700

>  Comment: What does it mean for a tcp stream to go idle? Are we talking around the idea of nat bindings expiring?

NAT and/or stateful firewalls, but it's also useful (IMHO) for detecting
connections that have dropped for other reasons, like peering disputes
between ISPs or someone tripping over my cable modem's power cord.

Should this text also make reference to security layers (i.e. TLS)?  I
know of at least one person who was trying to send U+0020 characters via
a socket that was actually associated with a TLS channel and was
confused as to why the other end was generating a TLS Fatal Alert. :)

~Paul

---

From: Dave Cridland <[email-masked]>
Date: Wed, 09 Jun 2010 12:08:27 +0100

On Wed Jun  9 00:34:38 2010, Paul Aurich wrote:
>  someone tripping over my cable modem's power cord.

Seems to be a lot of this going on...

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade