Hi Elwyn, thank you for reviewing this long document on such short notice. I'm cc'ing [email protected] to keep the XMPP WG in the loop, as well as [email protected].
On 11/29/10 6:21 PM, "Elwyn Davies" <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > [Apologies to the author: This document slipped through the gen-art > last call review net and so I only got to volunteer on this one 24 hours > ago.] > > Document: draft-ietf-xmpp-3920bis-19 > Reviewer: Elwyn Davies > Review Date: 29 November 2010 > IETF LC End Date: > IESG Telechat date: 2 December 2010 > > Summary: > This is a very well written document that is mostly easy to read and > follow. However I believe it is not (quite) ready for the IESG for the > following reasons: > > It has (IMO) one major issue as an EXTENSIBLE system - the three level-1 > stanzas are hard coded and it is not immediately possible to add new > types of level-1 stanza should this be thought useful in future. That has been the design of XMPP since 1999 and it has not visibly slowed the development of a wide range of XMPP extensions. From this I conclude that the existing stanza types appear to cover all of the communication primitives that have been needed in the XMPP community. Furthermore, the extensibility model was documented in RFC 3920 and this I-D merely provides updated documentation for the core XMPP protocols by obsoleting RFC 3920. It's a bit late to be changing it now. Besides, I imagine that if we want an even more flexible extensibility model, we'll develop XMPP 2.0. :) > There are several more minor issues with these two being important: > There are also a largish number of SHOULD requirements where the > alternative is not discussed or specified. This is true. When the alternatives are not security-critical, we have in general left them up to the best judgment of software developers and service operators. I'll also admit that it's a lot of work to document the alternatives to each SHOULD-level requirement, and that the XMPP WG and the spec writer might lack energy to do that in all cases. A quick grep yields 137 instances of SHOULD or RECOMMENDED, and I'd expect that well over 100 of those do not document the alternatives. That said, if you have concerns about specific instances of those conformance terms, please let me know. In the meantime, I will endeavor to look at them all, although I won't have time to do so until after the IESG telechat this Thursday at the earliest. > There seems to be a lack of clarity or definiteness about the effects of > support of SASL being mandatory. There are a number of places in the > document where the text is written as if SASL were not mandatory, and > others where the reverse is true but the surrounding text doesn't seem > to think it is mandatory.. All these places need to be looked at > critically to ensure that the wording is appropriate for SASL being > mandatory and that the whole is consistent. >From the perspective of software development, SASL authentication is mandatory-to-implement for all clients and servers. >From the perspective of service deployment, SASL authentication is mandatory-to-negotiate without qualification for all client-to-server streams. By contrast, for server-to-server streams, in practice SASL authentication is used only in the case of TLS + SASL EXTERNAL with PKIX certificates (in theory it could be used in the case of pre-shared secrets between servers, but I am not aware of any deployment of such a solution). However, many deployed XMPP services still do not have PKIX certificates and therefore fall back to weak identity verification using the Server Dialback protocol that was documented in RFC 3920 but has since been pulled out into a separate spec. While we would love to say that TLS + SASL EXTERNAL is mandatory-to-negotiate without qualification for all server-to-server streams, such a mandate would be so far out of alignment with deployed reality that people would just ignore it anyway. However, here again I'll take another look at the text to make sure that these matters are clear. In part, some of the confusion might derive from the fact that in some places we use the term "mandatory" alone, rather than "mandatory-to-implement" or "mandatory-to-negotiate". I have fixed all such instances in my working copy. > Apart form these there are a number of other minor issues and various > nits/editorial issues. > > Caveat: As usual I haven't tried to verify the XML in Appendix A, and my > scan of the examples in s9 was very cursory. > > Major issues: > s4.1, Definition of XML Stanza: Given that xmpp is supposed to be > extensible, is there a really good reason why the first-level > stanza=defining elements (message, presence, iq) are hard-coded into the > specification rather than being possibly extensible? There is already a > stream features mechanism where additional first-level items could be > signlaed. And there's been absolutely no demand for new first-level elements. I'm not saying there never will be such demand, but to date the XMPP community has been able to do everything it's wanted to do using the existing stanza types. > Minor issues: > s2.5, first bullet describing server respnsibilities: The term 'local > clients' is slightly confusing. My immediate understanding of 'local' > would be something attached to the server from the local network or > machine. In this case it is presumably intended to imply clients that > have a session connected to this server rather than via some other > server but may of course be very remote as regards physical and network > location. Maybe 'attached clients' or 'associated clients' (this term > is used elsewhere in the document) might be clearer, or maybe this just > needs a terminology definition for how 'local' is used - there is the > use of 'local entities' previously in s2.5 but this didn't jar so much. Elsewhere in this document we use the term "connected client", so I propose using that term here as well. > s2.5, last para: Does the use of 'local services' imply anything about > the disposition of the code implementing the service? This use of > 'local' may or may not conflict with the implications of 'local > mentioned in the last comment. Terminology needs to be made a little > more rigorous. Elsewhere in this document we use the term "add-on service", so I propose using that term here as well. > s4.2.2: Towards the end of this section, there are two statements > stating 'the initiating entity is cleared to send XML stanzas'. Should > this be qualified with 'unless a stream restart is required as a result > of the feature negotiation' (at least at the first appearance)? This > probably depends on whether voluntary-to-negotiate features can require > stream restarts if agreed but not otherwise. The fact that the initiating entity is cleared to send stanzas is orthogonal to whether a stream restart might be required after negotiation of a voluntary-to-negotiate feature -- even if a voluntary-to-negotiate feature required a stream restart (and so far none of them do), the initiating entity would still be cleared to send stanzas. Also note that stream restarts are something of a legacy "feature" (bug?), because back in ~2003 we thought a stream restart would be necessary to flush the security context of a stream after negotiation of TLS or negotiation of a SASL mechanism that enforced a security layer. However, in fact that really wasn't necessary and if we did it over again we might remove stream restarts entirely. But there was no appetite in the WG for making such a large change in 3920bis, so stream restarts remain as a kind of legacy feature (bug?). > s4.2.3 and s4.4: In s4.2.3, if a stream has to be restarted, the parties > are supposed to consider the the stream 'replaced'. This presumably > means that the old stream is closed. It is not absolutely clear whether > this requires that a <stream/> is exchanged or definitely not exchanged > in this case. [OK: This is cleared up for the specific TLS case at item > 3 in s5.4.3.3 and for SASL in s6.4.6 - a general note at s4.2.3 would be > appropriate since these are not necessarily the only restart cases.] Section 4.2.3 states in part: The initiating entity then MUST send a new initial stream header, which SHOULD be preceded by an XML declaration as described under Section 11.5. That seems clear to me. However, this would be even clearer: On successful negotiation of a feature that necessitates a stream restart, both parties MUST consider the previous stream to be replaced but MUST NOT send a closing </stream> tag and MUST NOT terminate the underlying TCP connection; instead, the parties MUST reuse the existing connection, which might be in a new state (e.g., encrypted as a result of TLS negotiation). The initiating entity then MUST send a new initial stream header, which SHOULD be preceded by an XML declaration as described under Section 11.5. > s4.2.6, paras 2 and 3: The first parts of these paragraphs are written > as if SASL autrhentication was mandatory (which it is) and is the only > possibility (which it might not be). Para 2 (the client-to-server case) > does not appear to allow for any other options. Para 3, OTOH, goes on > to deal with Server Dialback but the first part still reads as if SASL > was the only option. Both paras need to be rewritten to cater for other > options (and the version 0.9 case?). See above about wiggle room for weak identity verification using Server Dialback. Before SASL, we did also have another method for client authentication, but that is completely deprecated, unlike Server Dialback (which unfortunately clings to life despite our best efforts to drive a stake through its heart). > s4.6.1, para 6: > 'For initial stream headers in server-to-server communication, a > server MUST include the 'from' attribute and MUST set the value to > the domainpart of the 'from' attribute of the stanza that caused the > stream to be established...': Is it absolutely always the case that > a server-to-server connection would be established because some stanza > came in (presumably from an attached client)? Could this be indirectly > through some local service requiring a connection for any other reason? > It is clear why the server needs to specify 'from' but the constraint > on the origin seems overly restrictive. There's no reason to establish a server-to-server connection unless a server needs to send a stanza to a peer server. The triggering stanza might have been generated by a connected client, an add-on service, or even the server itself. Unlike end users, servers don't connect to each other just because they're lonely. :) > s5.3.5: 'Because it is relatively inexpensive to establish streams in XMPP, > for the first two cases it is preferable to use an XMPP stream reset > (as described under Section 4.8.3.16) instead of performing TLS > renegotiation.': > Is this always true? Probably so for simple instant messaging but if > the client is using some other services provided by the server, this may > an unwarranted generalization. I am not sufficiently expert in either > XMPP or TLS renegotiation to know what the trade-offs would be. The XMPP WG had a fair amount of discussion about the tradeoffs and came to the conclusions summarized in that section. The cost here is not really related to the application that is operated after streams are negotiated (and don't assume that IM is a simple or inexpensive application!), but to the process of establishing streams in the first place no matter what application is operated over the stream. > s5.3.5: 'However, the third case is sufficiently rare that XMPP entities > SHOULD NOT blindly attempt TLS renegotiation.' (the third case is > separating client authentication from server authentication): > I don't understand what is being said here. Is this an opinion that the > risk of client credential leakage is sufficiently low that the expense of > two stage negotiation is not really worth it? Or is this something that > should be controlled by a configurable client policy? Or is this an > implementation choice? Some clarification would help. The WG came very close to saying that XMPP entities MUST NOT use TLS renegotiation because in general the costs (e.g., code complexity) outweigh the benefits. However, as described there is one case when it might be useful. Yet that case is quite rare, because in this case essentially the client doesn't trust the server and won't send its TLS credentials to the server until after the server has authenticated to the client. So far we don't know of any client implementations or deployments that are sufficiently paranoid to behave that way and in any case end-user certificates are extremely rare at this point in the evolution of XMPP technologies. In the case of server-to-server connections, the server that acts as a TLS client uses a PKIX certificate as its credential and such certificates are public anyway, so there's no possibility of leaking private information. End-user certificates also tend to be public in that way (although the user might worry about leaking their bare JID before the stream is protected). To clarify these matters, I suggest the following modified text: The third case has improved security characteristics when the TLS client (which might be an XMPP server) presents credentials to the TLS server. If communicating such credentials to an unauthenticated TLS server might leak private information, it can be appropriate to complete TLS negotiation for the purpose of authenticating the TLS server to the TLS client and then attempt TLS renegotiation for the purpose of authenticating the TLS client to the TLS server. However, this case is extremely rare because the credentials presented by an XMPP server or XMPP client acting as a TLS client are almost always public (i.e., a PKIX certificate) and therefore providing those credentials before authenticating the XMPP server acting as a TLS server would not in general leak private information. As a result, implementers are encouraged to carefully weigh the costs and benefits of TLS renegotiation before supporting it in their software, and XMPP entities that act as TLS clients are discouraged from blindly attempting TLS renegotiation unless the certificate (or other credential information) sent during TLS negotiation is known to be private. > s5.4.3.1, rule 3: Why should the receiving entity not request a certificate? Perhaps it has no expectation that initiating entity will be able to provide a certificate. I don't think the WG had consensus to say MUST here, but I'll bring this up on the WG list. > Why would the initiating entity not send its certificate if it had one? (Is > this related to the renegotiation issue from the last comment?) Yes, it is related -- the initiating entity might not want to send its (private) credential information until after the receiving entity has itself authenticated to the initiating entity. > s5.4.3.1, rule 4: How should the receiving entity make the choice given the > 'to' attribute (presumably some field in the certificate)? Here the 'to' attribute essentially functions like a Server Name Indication in TLS. If the server has multiple certificates based on domain name (e.g., in a virtual hosting environment), it can figure out which certificate to present based on the domain name contained in 'to' address. I suggest the following text clarification: 4. The receiving entity SHOULD choose which certificate to present based on the domainpart contained in the 'to' attribute of the initial stream header (in essence, this domainpart is functionally equivalent to the Server Name Indication defined for TLS in [TLS-EXT]). > What happens if > it decides not to follow this should? The TLS negotiation might fail because the initiating entity would think it's connecting to example.com but the receiving entity would present a certificate for example.org (or whatever). However, note that this doesn't apply if the XMPP server is servicing only one domain, which is by far the most common deployment scenario. > s5.4.3.2, para 2: The comment about not sending </stream> relates to the > comment on s4.3.2 above. However, the reasoning for not sending </stream> > when the TCP connection is closed due to TLS failure differs from reasoning > given elsewhere (e.g., s5.3.5, para 8 - here the error is said to be at the > TLS layer and not the XMPP layer so that it is not appropriate to send > </stream>). > A consistemt story is needed here. The text in Section 5.3.5 is more correct, thus I propose this in 5.4.3.2: The receiving entity MUST NOT send a closing </stream> tag before terminating the TCP connection (since the failure has occurred at the TLS layer, not the XMPP layer; see Section 13.3). (The text about the stream being replaced applies to TLS success but not TLS failure.) > s5.4.3.3, item 5: Given that SASL support is mandatory, why is offering the > SASL > feature not a MUST? Is this to do with possible future alternatives? In the server-to-server case, if the peer server did not present a certificate then SASL won't be possible. See above. > s6.3.8, para 1: I suspect the two SHOULDs in this para ought to be MUSTs. > What > other options does initiating entity have if it does/does not want to act on > behalf of another entity and SASL is being used? None. So I think MUST and MUST NOT are appropriate (with the understanding that they are hypothetical imperatives anyway, not categorical imperatives). > However maybe all this > should be > qualified by 'If SASL is being used...' I think not. > s6.4.1, para 5: 'If the receiving entity supports SASL, the stream features > SHOULD include an advertisement for support of SASL negotiation,...': > s6.2 says that XMPP entities MUST support SASL. Right. The clause "If the receiving entity supports SASL" is a legacy of RFC 3920, when SASL was new. The clause can be safely removed now (all other instances have been removed, but we missed this one). > I think that this sentence > probably needs to be turned round making it something like 'Unless support for > SASL > negotiation is only allowed once STARTLS negotiation has been completed, the > stream features MUST include an advertisement for the support of SASL.' Aside > from > the STARTLS case (or equivalent cases with future secure stream mechanisms), > what > happens if the SASL advertisement is not made? I think that changing the sentence as you propose is not correct, because it closes off all other reasons for not advertising support for SASL (and, because SASL is mandatory-to-negotiate if advertised, thus forcing an attempt at SASL negotiation). For completeness, I think it would be best to adjust the text in this section as follows: ### 6.4.1. Exchange of Stream Headers and Stream Features If SASL negotiation follows successful STARTTLS negotiation (Section 5), then the SASL negotiation occurs over the encrypted stream that has already been negotiated. If not, the initiating entity resolves the hostname of the receiving entity as specified under Section 3, opens a TCP connection to the advertised port at the resolved IP address, and sends an initial stream header to the receiving entity. In either case, the receiving entity will receive an initial stream from the initiating entity. I: <stream:stream from='[email protected]' to='im.example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> When the receiving entity processes an initial stream header from the initiating entity, it MUST send a response stream header to the initiating entity (for which it MUST generate a unique stream ID; if TLS negotiation has already succeeded then this stream ID MUST be different from the stream ID sent before TLS negotiation completed). R: <stream:stream from='im.example.com' id='vgKi/bkYME8OAj4rlXMkpucAqe4=' to='[email protected]' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> The receiving entity also MUST send stream features to the initiating entity. The stream features SHOULD include an advertisement for support of SASL negotiation, i.e., a <mechanisms/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. Typically there are only three cases in which support for SASL negotiation would not be advertised here: o TLS negotiation needs to happen before SASL can be offered (i.e., TLS is required and the receiving entity is responding to the very first initial stream header it has received for this connection attempt). o SASL negotiation is impossible for a server-to-server connection (i.e., the initiating server has not provided a certificate that would enable strong authentication and therefore the receiving server is falling back to weak identity verification using the Server Dialback protocol [XEP-0220]). o SASL has already been negotiated (i.e., the receiving entity is responding to an initial stream header sent as a stream restart after successful SASL negotiation). [...] ### > s6.4.2, last para: '... the server SHOULD discard the ongoing handshake...': > What happens if the server (receiving entity) chooses not to > comply with the new proposed SASL mechanism choice? That paragraph has changed in response to IESG feedback and subsequent WG discussion. In my working copy it now reads: If the initiating entity subsequently sends another <auth/> element and the ongoing authentication handshake has not yet completed, the server MUST discard the ongoing handshake and MUST process a new handshake for the subsequently requested SASL mechanism. > s6.4.5, paras 4 and 6: 'SHOULD close the stream': What would enity do > instead? Return a stream error, but that's not very friendly because the initiating entity hasn't really violated any rules, it's just that authentication has failed. > s6.4.6, para 1: The two SHOULDs in this paragraph ought to be MUSTs. (if > there is > a 'from' address then the receiving entity MUST do the correlation - what else > could it do? If it does the match and they don't match, what would do other > than > termionate the attempt?) We don't place a great deal of trust in the 'from' address that is sent before confidentiality and integrity are in place. What if the initial 'from' was tampered with, but the SASL exchange succeeds anyway? In fact we might consider changing the second SHOULD to MAY for that very reason, although I think SHOULD is probably fine. > s8.1.2.1, item 2; also s10.5.1 and s10.5.2: s8.1.2.1, item 2 appears to > introduce > the idea that the <domainname> is the 'bare JID' of a server. This concept > does > not appear anywhere else in this document (or from a brief Google search > elsewhere). > It was not used in RFC 3920. It also doesn't match the definition of Bare JID > in > s10.5.3.2. Previously in this document this was known as the > 'hostname'. I think this is probably an error. However s10.5.1 refers to a > 'Mere Domain' as a JID and s10.5.2 to a <domain/resourcepart> as a JID. This > seems > rather inconsistent. The word "bare" is missing from section 4.2.6: For server-to-server communication, the initiating server's bare JID (<domainpart>)... Historically, we referred to bare JID as <localp...@domainpart> and full JID as <localp...@domainpart/resourcepart>, but we didn't have good terms for <domainpart> vs. <domainpart/resourcepart> (not that anyone really uses the latter form). Thus we borrowed the terms bare JID and full JID for servers, as well. You make a good point about the section names. I suggest changing them to: 10.5. Local Domain 10.5.1. domainpart 10.5.2. domainpart/resourcepart 10.5.3. localp...@domainpart 10.5.3.1. No Such User 10.5.3.2. User Exists 10.5.4. localp...@domainpart/resourcepart > s8.1.2.1, items 2 and 4: As written, both items refer to stanzas 'generated > by the > server'. I take it that the distinction is that item 2 refers to messages > from the > server that are not generated by the server as a proxy for the client account > but > are some sort of generic control message or the like, whereas item 4 refers to > server > generated messages that are generated by the server as such a proxy for the > client > account. The wording is somewhat confusing at present. Presumably the lack > of a > 'from' attribute is intended to distinguish item 1 messages from item 4 > messages - > this could be spelt out more positively if this is cotrrect. I suggest the following tweaked text: 2. When the server generates a stanza on its own behalf for delivery to the client from the server itself, the stanza MUST include a 'from' attribute whose value is the bare JID (i.e., <domainpart>) of the server as agreed upon during stream negotiation (e.g., based on the 'to' attribute of the initial stream header). and: 4. A server MUST NOT send to the client a stanza without a 'from' attribute if the stanza was not generated by the server on its own behalf (e.g., if it was generated by another client or another server and the server is merely delivering it to the client on behalf of some other entity); therefore, when a client receives a stanza that does not include a 'from' attribute, it MUST assume that the stanza is from the user's account on the server. > s13.7.1.1. Both instances of item 4: 'The signatureAlgorithm SHOULD be the > PKCS #1 version 1.5 signature algorithm with SHA-256 as defined by > [PKIX-ALGO].': The issuing entity (typically a CA) can use a stronger signature algorithm if it pleases. > What happens if it isn't? I don't see an interoperability issue here -- we're trying to provide a baseline for certificate issuers, but naturally CAs might choose stronger signature algorithms in the future. > s13.7.1.1: First item 5: 'The certificate SHOULD include an Authority > Information Access (AIA) extension that specifies the address of an Online > Certificate Status Protocol [OCSP] responder.' > What happens if it doesn't? Then entities checking the certificate might need to fall back on CRLs. > s13.9.5 and s15: The requirement for support of TLS-NEG if TLS Renegotiation > is to be allowed > should be mentioned here. We could copy the last sentence of Section 5.3.5: Support for TLS renegotiation is strictly OPTIONAL. However, implementations that support TLS renegotiation MUST implement and use the TLS Renegotiation Extension [TLS-NEG]. > This is also a conformance requirement. Section 15 does not include features that are optional. > s14: I seem to remember that giving a working group as a registrant contact > for an URI is deprecated as it is likely to go out of existence fairly > shortly. Good point, I'll change those to IESG. > Nits/editorial comments: > > > s3.2.1, bullet labeled '5': 'The initiating entity uses the IP > address(es) from the first successfully resolved hostname...': 'first' > implies that it depends on how fast the answers come back. Presumably > what is wanted is the IP address of the highest priority SRV record that > is successfully resolved, maybe subject to some local policies? Good catch. I think we can change this to: "...from the successfully resolved hostname..." Where "success" is measured in the terms of the prior steps. > s3.2.1,bullets labelled '3' and '8': Bullet 3 suggests that the s3.2.2 > fallaback process 'SHOULD' be used whereas bullet 8 has an implicit MAY > (that might be better if was explicit). Why the distinction? > [Presumably, having read on, there is little point in trying the first > possibility in the defaults if the initiating entity has already tried > the default port, but the alternatives might still work.] Section 3.2.2 > could mention that there is no point in trying the default ports if they > were already tried under s3.2.1. There's a difference here between failure in the case when there are SRV records, and no SRV records at all. If the DNS admin has configured SRV records but they're just wrong or result in failed lookups, I think the fallback is not a good idea (I've received feedback about this offlist since -19 was published as well) -- this can result in some strange cases of one-way connections in server-to-server scenarios. Thus I think this is correct: 3. If a response is received, it will contain one or more combinations of a port and hostname, each of which is weighted and prioritized as described in [DNS-SRV]. However, if the result of the SRV lookup is a single resource record with a Target of ".", i.e. the root domain, then the initiating entity MUST abort SRV processing at this point. and: 8. If the initiating entity receives a response to its SRV query but it is not able to establish an XMPP connection using the data received in the response, it SHOULD NOT attempt the fallback process described in the next section (this helps to prevent a state mismatch between inbound and outbound connections). 9. If the initiating entity does not receive a response to its SRV query, it SHOULD attempt the fallback process described in the next section. > s3.2.2: A pointer to s15.7 where the default port numbers are registered > would be useful. Agreed. Changed to: The fallback process SHOULD be a normal "A" or "AAAA" address record resolution to determine the IPv4 or IPv6 address of the origin domain, where the port used is the "xmpp-client" port of 5222 for client-to-server connections or the "xmpp-server" port of 5269 for server-to-server connections (these are the default ports as registered with the IANA; see Section 14.7). > s3.2.4: Where is the appropriate XML stanza for defining add-on services > defined? If by "defining" you mean "communicating with", the answer is that it depends on the application. For XMPP groupchat services of the kind used at IETF meetings, the protocol is defined here: http://xmpp.org/extensions/xep-0045.html There is no appropriate XML stanza for *defining* add-on services. If only developing protocol extensions were that easy... :) > s4.1, Definition of XML Stanza: The term/title 'iq'/'IQ' is not expanded > until s8.2.3 in this document where it is expanded as info/query. It > would be useful to mention this here (first occurrence) and indeed maybe > to put all three of message, presence and iq into the terminology > section. The usage of IQ stanzas would then be clearer and their use > in examples would be more transparent - currently they just appear with > no introduction (e.g, in s4.1 and then in s4.8.3.11). Good point. I have added those to the terminology section: The term "XML stream" (also "stream") is defined under Section 4.1. The term "XML stanza" (also "stanza") is defined under Section 4.1. There are three kinds of stanzas: message, presence, and IQ (short for "Info/Query"). These are defined under Section 8.2.1, Section 8.2.2, and Section 8.2.3, respectively. > s4.1, final set of bullets: Adding section references to the five topics > would be helpful. Done. > s4.2.2, first para: A pointer to s4.6.5 which is very prescriptive about > how to do the version comparison would be useful. Agreed. Changed to: If the initiating entity includes in the initial stream header the 'version' attribute set to a value of at least "1.0" (see Section 4.6.5)... > Figure 3: It would help if the figure could be made one or two lines > shorter so that the title appears on the same page. (e.g., move the > bottom line 'yes' and 'no' above the transition lines that they apply > to, remove one line below the 'process complete' box.) Done. > s4.6.1, para 8 (also s4.6.2): Although it may seem a bit pedantic, it > is probably desirable to clarify that by 'hostname' the document means a > fully qualified DNS name. The term is used ambiguously by many > operating systems. Agreed. I suggest that we use the term "FQDN" instead of "hostname" anyway, because of the many ambiguities over the years regarding the latter term. Thus: Because XML streams are sent over TCP, the initiating entity needs to determine the IPv4 or IPv6 address (and port) of the receiving entity before it can attempt to connect to the XMPP network. Typically this is done by resolving the receiving entity's fully-qualified domain name or "FDQN" (see [DNS-CONCEPTS]). and then: The preferred process for FQDN resolution is to use [DNS-SRV] records as follows: etc. And in a few places by "hostname" we really mean "domainpart", so I've modified those accordingly. > s4.6.6: The entries for to/initiating to receiving and from/receiving to > initiating are hostnames and not JIDs always. The other two to and from > entries are hostnames rather than JIDs for the server-to-server case. > [But the comments on s8.1.2.1 item 2 and ss10.5.1/2 under minor issues > may have some bearing here.] A mere <domainpart> is a JID. > s5.3.3 and s6.3.5: Does 'whitespace' mean all the 'white space' items > referred to in Section 2.10 of the current version of the XML spec > (i.e., including line separators). The term whitespace is used earlier > whan referring just to spaces used in the context of keep alives. [It > turns out much later that s11.7 clarifies this but maybe doesn't totally > resolve s2.10.] Note that the XML specification uses 'white space' > rather than 'whitespace'. Section 1.4 of 3920bis states this (including the changes resulting from Alexey Melnikov's IESG comments): The term "whitespace" is used to refer to any character or characters matching production [3] content of [XML], i.e., one or more instances of the SP, HTAB, CR, or LF rules defined in [ABNF]. > s6.4., last para: For consistency and avoiding confusion between XMPP > server and SASL server: s/server/receiving entity/ Fixed. > s8.2.1: A reference to s10.3.1, where the meaning of a message with 'to' > attribute is explained, would be clarify the first SHOULD. Adding 'if > possible' to route or deliver it to the intended recipient' would > explain the second SHOULD. Tweaked to: The <message/> stanza can be seen as a "push" mechanism whereby one entity pushes information to another entity, similar to the communications that occur in a system such as email. All message stanzas SHOULD possess a 'to' attribute that specifies the intended recipient of the message (see Section 8.1.1 and Section 10.3); upon receiving such a stanza, a server SHOULD if possible route or deliver it to the intended recipient (see Section 10 for general routing and delivery rules related to XML stanzas). > s8.2.2: The second and third SHOULDs probably need 'if possible' to > explain them. Tweaked to: The <presence/> stanza can be seen as a specialized broadcast or "publish-subscribe" mechanism, whereby multiple entities receive information (in this case, network availability information) about an entity to which they have subscribed. In general, a publishing entity (client) SHOULD send a presence stanza with no 'to' attribute, in which case the server to which the entity is connected SHOULD if possible broadcast that stanza to all subscribed entities. However, a publishing entity MAY also send a presence stanza with a 'to' attribute, in which case the server SHOULD if possible route or deliver that stanza to the intended recipient. See Section 10 for general routing and delivery rules related to XML stanzas, and [XMPP-IM] for rules specific to presence applications. > s8.3.2/s8.3.3: All the error specifications in s8.3.3 contain a SHOULD > specification of the error type recommended. A note in s8.3.2 or s8.3.3 > that the values of the error type given in s8.3.3 are the usual expected > error type, but that there are conceivably circumstances when some other > value would be more appropriate. (the only one I copuld think of so far, > apart from the remote-server-timeout case already in the draft, was > associated with payment-required where a modify or cancel error type > might be appropriate if the reason was not that the requestor wasn't > actually authorized but that it didn't have enough credit.) Done in 8.3.3: The error-type value that is RECOMMENDED for each defined condition is the usual expected type; however, in some circumstances a different type might be more appropriate. > s11.4: 'A client SHOULD NOT rely on the ability to send data that does > not conform to the schemas': This is not controllable by the protocol. > s/SHOULD NOT/should not/ Sure: Clients are advised not to rely on the ability to send data that does not conform to the schemas... > s11.4: What should the client do if it doesn't ignore non-conformant > elements? Process them. :) Some implementation violate the schemas. Tthey can do that, but we recommend that they don't because violating the schemas can have bad consequences. One old example is <presence type='invisible'/> (ick). > s8.3.3.15, Security Note: s/communicated/communicate/ Fixed. > s14. The IANA Considerations mostly duplicate those in RFC 3920. Is the > intention that IANA should update the references to RFC3920 to point at > this document? If so some statement should be made about this. The IANA knows about that because the first paragraph of Section 14 states: The following subsections update the registrations provided in [RFC3920]. > s14: Presumably 'XXXX' is to be replaced by the RFC nnnn identifier for > the eventual RFC. This isn't stated. The "XXXX" is autogenerated via the &rfc.number; predefined entity in xml2rfc and the RFC Editor team knows to search-and-replace on that. > Should the various Namespace > names refer to document sections? I see no special reason to call out the section numbers in the IANA registry. That would be more work for the IANA, with very little benefit (we assume that readers can search the spec for strings of interest). Thanks again for the detailed review. Peter _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
