Subject: Re: [xmpp] Gen-art review of draft-ietf-xmpp-3920bis-19

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Dec 2010 14:53:12 -0700

Hi Elwyn,

Thanks for your reply. Unfortunately I got impatient and submitted a
revised I-D earlier today (-20), but I can always submit another one if
needed. Version numbers are cheap. :)

Comments inline.

On 12/10/10 11:18 AM, Elwyn Davies wrote:
> 
> Hi, Peter.
> 
> Sorry I was not responsive on checking your quick reponses here.  Have
> been rather tied up with a draft I am authoring (and have the editor's
> pencil for at the moment).
> 
> A few points from reviewing the diff you pointed to - it is mostly an
> excellent update:
> 4.7.1.. use MAY about 'from' rather than SHOULD?  Does the note apply
> only to connected clients only?  There is a MUST for servers.  Section
> 4.8.3's comments on jabber-client vs jabber-server may be relevant.

Do you mean this note?

      Security Warning: Notwithstanding the recommendations in the
      remainder of this section, the initiating entity SHOULD NOT
      include a 'from' address on the initial stream header it sends
      before the confidentiality and integrity of the stream are
      protected via TLS or an equivalent security layer (such as the
      SASL GSSAPI mechanism), since doing so would expose the initiating
      entity's identity to eavesdroppers.

I think that applies to both servers and clients, if they care to
protect their identity from casual eavesdroppers on the very first
stream header (before TLS or similar protection)

> 4.9.1.1: Should the shall in the last sentence be SHALL?

I have tried to use no lowercase instances of the capitalized keywords,
but missed that one. Fixed.

> 5.2 SHOULD -> RECOMMENDED if available but not mandatory-to-negotiate.

Don't SHOULD and RECOMMENDED mean the same thing?

RFC 2119 says:

###

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

###

> 13.9.1: Base64 -> Base 64 in the section title.

I tried to make our terminology consistent with RFC 4648, but missed the
title (and one instance in Section 6.5.5). Fixed.

> 14.x: email addresses [email-masked] -> [email-masked]

Fixed.

> In line comments about changes...
> 
> On Tue, 2010-11-30 at 14:59 -0700, Peter Saint-Andre wrote:
>> Hi Elwyn, thank you for reviewing this long document on such short notice.
>> I'm cc'ing [email-masked] to keep the XMPP WG in the loop, as well as
>> [email-masked].
>>
>> On 11/29/10 6:21 PM, "Elwyn Davies" <[email-masked]> 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. :)
> 
> I think this was covered OK in the subsequent email...
> You suggested 
> 
>> How about if we add the following paragraph right after the definition
>> of
>> "XML Stanza" in Section 4.1?
>>
>>    There are three kinds of stanzas: message, presence, and IQ (short
>>    for "Info/Query").  These stanza types provide three different
>>    communication primitives: a "push" mechanism for generalized
>>    messaging, a specialized "publish-subscribe" mechanism for
>>    broadcasting information about network availability, and a
>> "request-
>>    response" mechanism for more structured exchanges of data (similar
>> to
>>    [HTTP]).  Further explanation is provided under Section 8.2.1,
>>    Section 8.2.2, and Section 8.2.3, respectively.
>>
> 
> I think this covers the situation OK.

Good.

>>> 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.
> 
> A few notes on the SHOULDS (-19 section numbers) - omitted ones seem
> fine:
> 
> s3.2.3: This SHOULD is a policy/implementation issue.  It doesn't affect
> protocol implementation SHOULD -> should or ought to.

Sure. I don't think folks are too strict about conformance terms in
relation to implementation decisions, but I suppose you're right in this
case. Changed to "is encouraged to"...

> s3.3: I'd go for MUST in both cases.. don't you get beaten up about
> congestion otherwise?

I don't think this rises to the level of an absolute commandment. It's
network-friendly, but nothing breaks absolutely if it's not followed.

> s4.6.4, last para: The first strikes me as a MUST (although there is the
> obvious get out if the receiver's default is what the initiator
> specifies).  There seems to be a not-very-subtle bug in the generated
> text bit.. If the receiver doesn't support the initiator's default
> language then putting the initiator's specified language on to a
> generated message that isn't in that language ('cos the receiver doesn't
> do it) sounds rather stupid.

It's not the intended recipient that we're talking about here, it's the
routing server. If I tell my server that my preferred language is
'de-CH' but it can't send me error messages (etc.) in 'de-CH', it can
still stamp my outbound stanzas with 'de-CH' on my behalf.

> s4.6.5, item 3: .. and close the stream.  I guess the receiver might
> want to log why it didn't succeed.

A stream error is always followed by a stream close (Section 4.9.1.1),
so I don't see a reason to add those four words here.

However, I've added pointers to the specific sections for each error
condition whenever they are mentioned, and fixed up a few other places
where we followed "send a stream error" with "and close the stream".

> s4.6.5, item 4: Do typical legacy servers barf or ignore if they get a
> version attribute?  If barf, then maybe it should be MUST.

Those would be rather old legacy servers now (pre-2004), and as far as I
know they ignore the 'version' attribute (I think we would have known
about it by now if they barfed).

> s5.2: SHOULD -> HIGHLY RECOMMENDED

there is no HIGHLY RECOMMENDED in RFC 2119. :) I think "SHOULD" is fine.

> s5.4.3.3, item 5: discussed below.
> 
> s8.2.1: Isn't this a 'will contain a 'to' except if it is going to the
> connexted client's account on the server'?

Sure.  Changed to:

   The <message/> stanza is 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 will possess a
   'to' attribute that specifies the intended recipient of the message
   (see Section 8.1.1 and Section 10.3), unless the message is being
   sent to the bare JID of a connected client's account.  Upon receiving
   a message stanza with a 'to' address, a server SHOULD attempt to
   route or deliver it to the intended recipient (see Section 10 for
   general routing and delivery rules related to XML stanzas).

>>> 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.
> 
> I think the changes in if candaidate -20 cover the situation well.
>>
>>> 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.
> 
> OK.. we negotiated on this already.
>>
>>> 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.
> 
> Fine.
> 
>>
>>> 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.
> 
> OK.
> 
>>
>>> 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?).
> 
> OK.. happy to accept as is.
>>
>>> 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.
>>
> All cleared up in -20
> 
>>> 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).
> 
> I understand what is going on here.  I think the (minor) problem here is
> the word 'typically'.  It would not hurt to remind people again that
> SASL is (currently) the only client-to-server auth mechanism and so the
> determination is all in terms of SASL.  If somebody came up with another
> mechanism that could be an alternative (but one or other MUST be used)
> then the words would be different. How about (starting the second para):
> 
> For client-to server communication use of SASL is mandatory-to-negotiate
> and no alternative mechanisms are currently specified. Hence the
> clients's bare... 

Makes sense. I now have:

   After the parties to an XML stream have completed the appropriate
   aspects of stream negotiation, the receiving entity for a stream MUST
   determine the initiating entity's JID.

   For client-to-server communication, both SASL negotiation (Section 6)
   and resource binding (Section 7) MUST be completed before the server
   can determine the client's address.  The client's bare JID....

>>> 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. :)
> 
> Fair enough.
> 
>>
>>> 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.
>>
> I am happy with the text in -20.
> 
>>> 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.
> 
> I think it might be worth pointing out the potential privacy issue here.

I now have:

   3.  So that mutual certificate authentication will be possible, the
       receiving entity SHOULD send a certificate request to the
       initiating entity and the initiating entity SHOULD send a
       certificate to the receiving entity (but for privacy reasons
       might opt not to send a certificate until after the receiving
       entity has 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]).
> OK.. but ...
>>
>>> 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).
> 
> .. so isn't this a lower case 'should':  the validation will fail if it
> makes a wrong choice but it isn't a protocol requirement

Leading to unnecessary reconnection attempts and round trips. Seems to
me that SHOULD is still appropriate here.

>> 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.
> Indeed.
> 
>>
>>> 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.)
> 
> All clear now.
> 
>>
>>> 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.
>>
> You have added excellent text in s6.4.1 to explain when the SHOULD
> applies.. a pointer would help.

Done.

>>> 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).
>>
> OK
> 
>>> However maybe all this
>>> should be
>>> qualified by 'If SASL is being used...'
>>
>> I think not.
>>
> OK
> 
>>> 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).
>>
> Fine.
> 
>>> 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-masked]'
>>         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-masked]'
>>         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).
>>
>> [...]
>>
>> ###
>>
> Great.
> 
> 
>>> 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.
>>
> Fine.
> 
> 
>>> 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.

I looked at this a bit more yesterday and realized that my reply was
wrong. You raised a point about two paragraphs. The first one applies to
the initiating entity, the second to the receiving entity. I think the
proper handling is different in those two cases. My working copy now has:

   If the initiating entity attempts a reasonable number of retries with
   the same SASL mechanism and all attempts fail, it MAY fall back to
   the next mechanism in its ordered list by sending a new <auth/>
   request to the receiving entity, thus starting a new handshake for
   that authentication mechanism.  If all handshakes fail and there are
   no remaining mechanisms in the initiating entity's list of supported
   and acceptable mechanisms, the initiating entity SHOULD simply close
   the stream as described under Section 4.4 (instead of waiting for the
   stream to time out).

and:

      Implementation Note: For server-to-server streams, if the
      receiving entity cannot offer the SASL EXTERNAL mechanism or any
      other SASL mechanism based on the security context established
      during TLS negotiation, the receiving entity MAY attempt to
      complete weak identity verification using the Server Dialback
      protocol [XEP-0220]; however, if according to local service
      policies weak identity verification is insufficient then the
      receiving entity SHOULD instead close the stream with a <policy-
      violation/> stream error (Section 4.9.3.14) instead of waiting for
      the stream to time out.

> Thinking a bit more about what you have written about stream closing and
> about SErver Dialback elsewhere, two points come to mind:
> 1) If this is a server-to-server connection, is fallback to Server
> Dialback allowed at this point?

Probably. However, I think that the more usual case is that the
receiving server would not offer SASL at all after the post-TLS restart,
insteading offering only dialback. The behavior here is to some extent
still being worked out through experimentation in the developer
community. I expect that we will be able to make a more definitive
recommendation in the next revision (3920ter) after another year or two
of implementation and deployment experience, interop testing, etc.

> 2) Presumably this ought to be a tidy close down, sending </stream> and
> doing proper TLS shutdown rather than a peremptory termination of the
> TCP - a pointer to s4.4 would help.

For the second scenario (receiving entity), yes. See corrected text above.

>>> 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.
> 
> So this is really a matter of policy:  On that basis I think both
> SHOULDs ought to be RECOMMENDED.

See above regarding RFC 2119 keywords.

>>> 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 <localpart@domainpart> and full JID
>> as <localpart@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.  localpart@domainpart
>>          10.5.3.1. No Such User
>>          10.5.3.2. User Exists
>>        10.5.4.  localpart@domainpart/resourcepart
>>
> All sorted now!
> 
>>> 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.
>>
> Agreed.
> 
>>> 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.
> 
> How about 'It is RECOMMENDED that the signatureAlgorithm is (what you
> have) or a stronger algorithm.' 

Changed to:

   4.  The signatureAlgorithm SHOULD be the PKCS #1 version 1.5
       signature algorithm with SHA-256 as defined by [PKIX-ALGO], or a
       strong algorithm if available.

>>> 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.
> 
> Would someone skilled in the art know this? Probably?

Yesterday I had changed it to:

   5.  The certificate SHOULD include an Authority Information Access
       (AIA) extension that specifies the address of an Online
       Certificate Status Protocol [OCSP] responder (if not, a relying
       party would need to fall back on the use of Certificate
       Revocation Lists (CRLs) as described in [PKIX]).

>>> 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].
>>
> Agreed (and done).
> 
>>> This is also a conformance requirement.
>>
>> Section 15 does not include features that are optional.
>>
> OK
> 
>>> 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.
>>
> Need to fix the email addresses as well.

Yep, done.

>>> 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.
> 
> -20 is fine.
> 
>>
>>> 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).
>>
> New version in -20 looks fine.
> 
>>> 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... :)
> 
> I think I was reading more into what was said here than I think is
> actually said.  I presume that what is implied by 'appropriate' is that
> the 'to' attribute points to the the domain name used for the server for
> the add-on service. My mind was running on extra first level stanza
> types 'appropriate' for the add-on service.
> 
> 
> The rest are all fine.

Excellent.

Peter

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

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 10 Dec 2010 18:18:37 +0000

Hi, Peter.

Fine.

OK.

All cleared up in -20

Fair enough.

OK.. but ...

Indeed.

All clear now.

OK

OK

Fine.

Great.

Fine.

All sorted now!

Agreed.

Agreed (and done).

OK

-20 is fine.

The rest are all fine.

/Elwyn
> 
> > 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.
>    for "Info/Query").  These are defined under Section 8.2.1,
Fine.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Dec 2010 13:46:42 -0700

Thanks, Elwyn. Replies inline, areas of agreement elided.

[ cc'ing [email-masked] ]

On 12/14/10 6:56 AM, Elwyn Davies wrote:
> 
> On Tue, 2010-12-14 at 05:49 -0700, Peter Saint-Andre wrote:
>>
>> On 12/10/10 2:53 PM, Peter Saint-Andre wrote:
>>>
> The wording in this section is still slightly confusing because of the
> apparently conflicting SHOULD NOTs in the note and the later
> SHOULD/MUST.  I was running on the lines that the SHOULD NOT only
> affected the client-server case, but that is clearly not what is
> intended.  Perhaps the thing to do is to add an additional sentence to
> the Note: 'The requirements for inclusion of 'from' addresses in the
> rest of this section apply to cases where a security layer is not used
> and to the stream headers used when restarting the stream after the
> security layer has been negotiated.' 

In response to IESG feedback from Robert Sparks, I have changed this to:

###

4.7.1.  from

   The 'from' attribute specifies an XMPP identity of the entity sending
   the stream element.

   For initial stream headers in client-to-server communication, the
   'from' attribute is the XMPP identity of the principal controlling
   the client, i.e., a JID of the form <localpart@domainpart>.  The
   client might not know the XMPP identity, e.g., because the XMPP
   identity is assigned at a level other than the XMPP application layer
   (as in the General Security Service Application Program Interface
   [GSS-API]) or is derived by the server from information provided by
   the client (as in some deployments of end-user certificates with the
   SASL EXTERNAL mechanism).  Furthermore, if the client considers the
   XMPP identity to be private information then it is advised not to
   include a 'from' attribute before the confidentiality and integrity
   of the stream are protected via TLS or an equivalent security layer.
   However, if the client knows the XMPP identity then it SHOULD include
   the 'from' attribute after the confidentiality and integrity of the
   stream are protected via TLS or an equivalent security layer.

   [...]

   For initial stream headers in server-to-server communication, the
   'from' attribute is one of the configured FQDNs of the server, i.e.,
   a JID of the form <domainpart>.  The initiating server might have
   more than one XMPP identity, e.g., in the case of a server that
   provides virtual hosting, so it will need to choose an identity that
   is associated with this output stream (e.g., based on the 'to'
   attribute of the stanza that triggered the stream negotiation
   attempt).  Because a server is a "public entity" on the XMPP network,
   it MUST include the 'from' attribute after the confidentiality and
   integrity of the stream are protected via TLS or an equivalent
   security layer.

   [...]

###

Robert said that works for him, so hopefully it clarifies things for
you, too.

> It's a long time since I read RFC 2119 :-(
> 
> I was thinking of the subtle distinction in common usage between should,
> which in my book implies a degree of obligation greater than
> recommended. Given 2119 I guess it makes no difference which one you
> use.

I think that's right. The capitalized keywords from RFC 2119 are not
normal English. :)

> The transport area tend to get riled about things that might cause
> congestion.. but if they aren't complaining I suppose its OK.

It's worth considering, and I'll ask the Transport ADs for advice. But
in my experience the real impact in on the server (big CPU hit on
restart), not the network.

> That case is clear.  After careful reading I got the impression that if
> the server itself sent messages (such as relating to the account) that
> were locally generated by the server and sent them back to the client
> then it was obliged to mark them with the client's preferred language
> even if this made no sense 'cos the server couldn't handle the preferred
> language.  Maybe this is a non-existent case.

I think it a non-existent issue, but I'll look at the text again to make
sure it's clear.

> OK - leave it as it is.

Ack.

> OK. Same point as before on SHOULD/RECOMMENDED.

Yep. Same point about the non-English character of RFC 2119 terms. :)

>>>    general routing and delivery rules related to XML stanzas).

OK, thanks.

I'm going to push out a revised I-D (version -21) now...

Peter

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