Subject: [xmpp] Followup Review of 3920bis-12

From: Ben Campbell <[email-masked]>
Date: Tue, 17 Aug 2010 16:52:57 -0500

[as individual]

Here's the result of a quick re-review on 3920bis-12. I blazed through this as quickly as I could for a 183 page doc, so there were plenty of opportunities to miss things. Hopefully we will make up for that with the "many eyes" effect.

Thanks!

Ben.

Substantive Comments:

-- 4.8.3.18

Does see-other-hosts have security implications? In particular, does it matter if the server has been authenticated prior to its sending of this? I assume that an originator that chose to follow the redirect would authenticate the new server against the JID in the see-other-host element, right? 

Also, is name resolution for a JID received in a see-other-host element any different than the name resolution for the original server? If not, then why not just reference that section, rather than restate a subset of it? 

-- Appendix E

This seems to conflict with the trust boilerplate at the beginning of the document. In particular, the standard legal provisions have restrictions that are not reflected here.

Editorial and Nit comments:

-- section 1.3, implementation note, "...most deployed server will use the older server dialback protocol to provide weak identity verification instead of using SASL..."

I suggest "... most deployed servers use ... instead of SASL ..."  Both fixing a singular/plural mismatch on "server", and hopefully avoiding future looking statements implying implementations will continue to do this in the future.

-- section 1.4:

IDNits is confused by the 2119 boilerplate. Is there any reason not to use the standard 2119 boilerplate language? I realize this says the same thing, but we might at least avoid repeated "IDNit complaint" feedback during IETF last call.

-- Figures in general

Any chance of getting figure numbers and captions? I realize it would be a pain, but it's helpful for people using the document to be able to refer to a figure by number. (I'm okay if we don't want to bother.)

-- 4.2.5, last paragraph, "However, if it does attempt..."

Extraneous "However,", since this sentence does not in any way conflict with the prior one.

-- 4.8.3.18

Does see-other-hosts have security implications? In particular, does it matter if the server has been authenticated prior to its sending of this? I assume that an originator that chose to follow the redirect would authenticate the new server against the JID in the see-other-host element, right? 

Also, is name resolution for a JID received in a see-other-host element any different than the name resolution for the original server? If not, then why not just reference that section, rather than restate a subset of it? 

-- 10

Why the all-caps for ROUTE, DELIVER, and HANDLE? They are neither acronyms or 2119 normative terms.

-- 15

Have the conformance requirements been kept up to date through all the recent revisions?

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Aug 2010 17:07:02 -0600

On 8/17/10 3:52 PM, Ben Campbell wrote:
> [as individual]
> 
> Here's the result of a quick re-review on 3920bis-12. I blazed
> through this as quickly as I could for a 183 page doc, so there were
> plenty of opportunities to miss things. Hopefully we will make up for
> that with the "many eyes" effect.
> 
> Thanks!

No, thank you! :)

> Substantive Comments:
> 
> -- 4.8.3.18
> 
> Does see-other-hosts have security implications? In particular, does
> it matter if the server has been authenticated prior to its sending
> of this? I assume that an originator that chose to follow the
> redirect would authenticate the new server against the JID in the
> see-other-host element, right?
> 
> Also, is name resolution for a JID received in a see-other-host
> element any different than the name resolution for the original
> server? If not, then why not just reference that section, rather than
> restate a subset of it?

Those are very good points. I suggest changing the text as follows:

   4.8.3.18.  see-other-host

   The server will not provide service to the initiating entity but is
   redirecting traffic to another host; the XML character data of the
   <see-other-host/> element returned by the server MUST specify the
   alternate hostname or IP address at which to connect, which MUST be a
   valid domainpart or a domainpart plus port number (separated by the
   ':' character in the form "domainpart:port").  If the domainpart is
   the same as the source domain, target domain, or resolved IP address
   to which the initiating entity originally connected (differing only
   by the port number), then the initiating entity SHOULD simply attempt
   to reconnect at that address.  Otherwise, the initiating entity MUST
   resolve the hostname specified in the <see-other-host/> element as
   described under Section 3.2.

Where "source domain" and "target domain" are as defined in
draft-saintandre-tls-server-id-check (I've added a paragraph about that
to the Terminology section).

> -- Appendix E
> 
> This seems to conflict with the trust boilerplate at the beginning of
> the document. In particular, the standard legal provisions have
> restrictions that are not reflected here.

Other RFCs have been published with this text, including several
authored by Simon Josefsson. I'll check with him and others regarding
the interactions between this text and the trust boilerplate.

> -- section 1.3, implementation note, "...most deployed server will
> use the older server dialback protocol to provide weak identity
> verification instead of using SASL..."
> 
> I suggest "... most deployed servers use ... instead of SASL ..."
> Both fixing a singular/plural mismatch on "server", and hopefully
> avoiding future looking statements implying implementations will
> continue to do this in the future.

Fixed.

> -- section 1.4:
> 
> IDNits is confused by the 2119 boilerplate. Is there any reason not
> to use the standard 2119 boilerplate language? I realize this says
> the same thing, but we might at least avoid repeated "IDNit
> complaint" feedback during IETF last call.

I think it doesn't like [KEYWORDS] instead of [RFC2119]. That raises a
general point about human-friendly references like [TLS] vs. RFC-number
references such as [RFC5246]. Do folks have a preference? At one time,
the IESG preferred the human-friendly references, but I've had some
feedback that protocol geeks prefer the RFC-number references.

> -- Figures in general
> 
> Any chance of getting figure numbers and captions? I realize it would
> be a pain, but it's helpful for people using the document to be able
> to refer to a figure by number. (I'm okay if we don't want to
> bother.)

I can do that. It's not *that* painful, and it is more reader-friendly.

> conflict with the prior one.

How about "Even if the initiating entity does attempt to do so..."

> -- 4.8.3.18
> 
> Does see-other-hosts have security implications? In particular, does
> it matter if the server has been authenticated prior to its sending
> of this? I assume that an originator that chose to follow the
> redirect would authenticate the new server against the JID in the
> see-other-host element, right?
> 
> Also, is name resolution for a JID received in a see-other-host
> element any different than the name resolution for the original
> server? If not, then why not just reference that section, rather than
> restate a subset of it?

Dup? See above.

> acronyms or 2119 normative terms.

Some terms are in all-caps when they are first defined, but I think
you're right that this is confusing. If you find other instances, please
let me know and I'll lower-case them.

> Have the conformance requirements been kept up to date through all

As far as I know, yes. I don't think the recent revisions have had
conformance implications, but I'll double-check.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Aug 2010 17:19:37 -0600

> let me know and I'll lower-case them.

Never mind, I found them all -- they were the terms formerly in the
index (which I removed several versions ago).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/