From stpeter@stpeter.im Fri Oct 2 17:49:18 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D83F3A67EA for ; Fri, 2 Oct 2009 17:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlK8CTZyLOfI for ; Fri, 2 Oct 2009 17:49:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0E5383A67E2 for ; Fri, 2 Oct 2009 17:49:16 -0700 (PDT) Received: from squire.local (dsl-140-71.dynamic-dsl.frii.net [216.17.140.71]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26338400E8 for ; Fri, 2 Oct 2009 18:50:45 -0600 (MDT) Message-ID: <4AC69FE3.30408@stpeter.im> Date: Fri, 02 Oct 2009 18:50:43 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 00:49:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Earlier today I rewrote the section of 3920bis on stream features, expanding it to cover the stream negotiation process in general. Thanks to Jehan Pagès for pointing out to me in private conversation that this topic was underspecified. My provisional text follows. I will review this again next, but as always feedback is welcome. ###### 5.2. Stream Negotiation 5.2.1. Overview Because the receiving entity for a stream acts as a gatekeeper to the domains it services, it imposes certain conditions for connecting as a client or as a peer server. At a minimum, the initiating entity needs to authenticate with the receiving entity before it is allowed to send stanzas to the receiving entity, typically using SASL as described under Section 7. However, the receiving entity can require other conditions in addition to authentication, such as encryption using TLS as described under Section 6. The receiving entity informs the initiating entity about such conditions by communicating STREAM FEATURES: the set of particular protocol interactions that are mandatory for the initiating entity to complete before the receiving entity will accept XML stanzas from the initiating entity (e.g., authentication), as well as any protocol interactions that are voluntary but that might improve the handling of an XML stream (e.g., establishment of application-layer compression). The existence of such conditions implies that streams need to be negotiated, and the order of layers (TCP, then TLS, then SASL, then XMPP; see Section 14.5) implies that stream negotiation is a well- defined process. Furthermore, stream features can be either mandatory or voluntary; this imposes further structure on the negotiation process. Finally, for security reasons, the parties to a stream need to discard knowledge that they gained during the negotiation process after successfully completing the protocol interactions defined for certain features (e.g., TLS and SASL); this is done by flushing the old stream context and exchanging new stream headers over the existing TCP connection. 5.2.2. Stream Features Format If the initiating entity includes the 'version' attribute set to a value of at least "1.0" in the initial stream header, after sending the response stream header the receiving entity MUST send a child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any conditions for continuation of the stream negotiation process. Each condition takes the form of a child element of the element, qualified by a namespace that is different from the streams namespace and the default namespace. If negotiation of a particular stream feature is mandatory, the stream feature advertisement MUST include an empty child element. If negotiation of a particular stream feature is voluntary, the stream feature advertisement MAY include an empty child element. However, because every stream feature defaults to voluntary, the inclusion of an empty child element is not necessary to indicate that a stream feature is voluntary. For security reasons, certain stream features necessitate the initiating entity to send a new initial stream header upon successful negotiation of the feature (e.g., TLS and SASL). If a stream restart is necessary for any given feature, the or child element MUST include a boolean 'restart' attribute with a value of "true" or "1" (this optional attribute defaults to false). Although it is expected that stream restarts will be necessary only for mandatory features, voluntary features are also allowed to necessitate restarts. Aside from the child element, child element, and 'restart' attribute, the syntax and semantics of each particular feature are defined by an appropriate specification of that feature; several such features are defined in this document but stream features can be defined by other documents, as well. A element that contains at least one mandatory feature indicates that the stream negotiation is not complete and that the initiating entity MUST negotiate further features. R: A element MAY contain more than one mandatory feature. This means that the initiating entity can choose among the mandatory features. For example, perhaps a future technology will perform roughly the same function as TLS, so the receiving entity might advertise support for both TLS and the future technology. A element that contains only voluntary features indicates that the stream negotiation is complete and that the initiating entity is cleared to send XML stanzas, but that the initiating entity MAY negotiate further features if desired. R: zlib lzw A element that contains both mandatory and voluntary features indicates that the negotiation is not complete but but that the initiating entity MAY complete the voluntary feature(s) before it attempts to negotiate the mandatory feature(s). R: zlib lzw An empty element indicates that the stream negotiation is complete and that the initiating entity is cleared to send XML stanzas. R: Note: The order of child elements contained in any given element is not significant. If the initiating entity does not understand or support a feature that has been advertised, it MUST still inspect the feature advertisement to determine if negotiation of the feature is mandatory. If negotiation of an unsupported feature is mandatory and the receiving entity has offered no other mandatory features at that stage of the negotiation process, then the initiating entity MUST abort the stream negotiation process and SHOULD return an stream error to the receiving entity. If negotiation of an unsupported feature is voluntary, the entity MUST silently ignore the associated feature advertisement and proceed with the stream negotiation process. Note: Implementations based on an earlier revision of this specification do not include the child element and they include the child element only in the case of the STARTTLS feature. Entities MUST accept stream feature advertisements without the child elements, and MUST consider negotiation of such features to be voluntary. 5.2.3. Restarts On successful negotiation of a feature that requires a stream restart, both parties MUST consider the previous stream to be replaced but 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 12.5. When the receiving entity receives the new initial stream header, it MUST generate a new stream ID (instead of re-using the old stream ID) before sending a new response stream header (which SHOULD be preceded by an XML declaration as described under Section 12.5). 5.2.4. Resending Features After completing negotiation of any stream feature (even stream features that do not require a stream restart), the receiving entity MUST send an updated list of stream features to the initiating entity, where the list MAY be empty if there are no further features to be advertised. At any time after stream establishment and before closing of the stream, the receiving entity MAY send additional or modified stream feature advertisements to the initiating entity (e.g., because a new feature has been enabled). 5.2.5. Completion of Stream Negotiation The receiving entity indicates completion of the stream negotiation process by sending to the initiating entity either an empty element or a element that contains only voluntary features. Once stream negotiation is complete, the initiating entity is cleared to send XML stanzas over the stream for as long as the stream is maintained by both parties. The initiating entity MUST NOT attempt to send XML stanzas (Section 9) over the stream until stream negotiation has been completed. However, if it does attempt to do so, the receiving entity MUST NOT accept such stanzas and MUST return a stream error. This rule applies to XML stanzas only (i.e., , , and elements qualified by the default namespace) and not to XML elements used for stream negotiation (e.g., elements used to complete TLS negotiation (Section 6) or SASL negotiation (Section 7)). 5.2.6. State Chart We summarize the foregoing rules in the following non-normative state chart, presented from the perspective of the initiating entity. +------------+ | open TCP | | connection | +------------+ | +---------------+ | send initial |<-------------------------------------------+ | stream header | | +---------------+ | | | +------------------+ | | receive response | | | stream header | | +------------------+ | | | +----------------+ | | receive stream | | | features | | +----------------+ | | | {empty?} ---> {all voluntary?} ---> {some mandatory?} | | no | no | | | yes | yes | | | | | | | +---------------+ +----------------+ | | | MAY negotiate | | MUST negotiate | | | | any feature | | one feature | | | +---------------+ +----------------+ | | | | | | +--->-------+---<------+ | | | | | [restart required?] ------------>+ | | yes | no | | | | +-------------+ | | negotiation | +-------------------->| complete | +-------------+ ###### -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrGn+MACgkQNL8k5A2w/vzDUQCg45C5e2YNky1nzmaa3+C72N9f 0PIAoOzrVqmXXgh1QPbFRyOsv7qyLJe3 =ZwmO -----END PGP SIGNATURE----- From waqas20@gmail.com Sat Oct 3 05:24:21 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505573A686A for ; Sat, 3 Oct 2009 05:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9j-v+nU1Nm9 for ; Sat, 3 Oct 2009 05:24:20 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id E59AD3A66B4 for ; Sat, 3 Oct 2009 05:24:19 -0700 (PDT) Received: by ywh13 with SMTP id 13so1574035ywh.31 for ; Sat, 03 Oct 2009 05:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qqH7NqvWM/Pa6RFu51A56aYkWp0RxIKoeOg3s6VqcE8=; b=dWG1XhGBfhrsAk/FQae+rktYqoVAF6M9EWM/rLOZb/qoOna7fjsonnDrA8iEN5vIh3 UEyqdO3zN7Vf2JwdYxA7SjyetubUTe0iWHe+6kuu5vGX9PfHi82ghN6hQST5Bt4DXnsJ h9oqH/UI9uk1XcjM/Ci1UrB9gpeermcgnghG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=B9Yl+6QFVge6f/OUfc8RJj/+p58W9Gjmt4hn4WnwUvsiqm6Km/Noh5P07TQwJNQuV8 KW/yTYoKvx0Cts++U4l6EUxKPO2ZUaBh9ONYlqvwB1PDH9k0JJIgqjLxp4jEy5VBG46i sDymuMy2SOjDnI5cOy7vyVhX30p+ZlYqcSQP4= MIME-Version: 1.0 Received: by 10.150.173.29 with SMTP id v29mr6179513ybe.193.1254572747274; Sat, 03 Oct 2009 05:25:47 -0700 (PDT) In-Reply-To: <4AC69FE3.30408@stpeter.im> References: <4AC69FE3.30408@stpeter.im> Date: Sat, 3 Oct 2009 17:25:47 +0500 Message-ID: <7fc4fa880910030525n70396c92ye4fc2dac0d2e026a@mail.gmail.com> From: Waqas Hussain To: XMPP Content-Type: multipart/alternative; boundary=000e0cd59546f23bf9047506fa1d Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 12:24:21 -0000 --000e0cd59546f23bf9047506fa1d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 3, 2009 at 5:50 AM, Peter Saint-Andre wrote: > If negotiation of a particular stream feature is mandatory, the > stream feature advertisement MUST include an empty child > element. > > If negotiation of a particular stream feature is voluntary, the > stream feature advertisement MAY include an empty child > element. However, because every stream feature defaults to > voluntary, the inclusion of an empty child element is not > necessary to indicate that a stream feature is voluntary. > What namespace are these elements under? Just inheriting the namespace of whatever feature they are included in is pretty evil. Elements are qualified by their names AND namespaces. A name without a namespace and a namespace without a name are meaningless. Specifying that a name has a given meaning under any and all namespaces goes against the spirit of XML namespaces and, if you think about it, is just plain Wrong(TM). Can we have a fixed namespace for these elements please? > For security reasons, certain stream features necessitate the > initiating entity to send a new initial stream header upon successful > negotiation of the feature (e.g., TLS and SASL). If a stream restart > is necessary for any given feature, the or > child element MUST include a boolean 'restart' attribute with a value > of "true" or "1" (this optional attribute defaults to false). > Although it is expected that stream restarts will be necessary only > for mandatory features, voluntary features are also allowed to > necessitate restarts. > > Aside from the child element, child element, > and 'restart' attribute, the syntax and semantics of each particular > feature are defined by an appropriate specification of that feature; > several such features are defined in this document but stream > features can be defined by other documents, as well. > I'm afraid I missed the discussion where the element and the 'restart' attribute were defined. Whether a feature requires a stream restart or not is part of the definition of the feature (e.g., it's part of the definitions of the SASL and STARTTLS features). If an entity understands a feature, then it already knows whether a restart is required or not. What value does the 'restart' attribute add? Are there any use-cases where the 'restart' attribute saves the day? The only case where the 'restart' attribute might be useful is for features which can work both with and without restarts, and the server needs to specify at runtime whether it feels like doing a stream restart or not. I don't see any need for such features. This brings to mind the restart-less SASL/etc negotiation discussed last year, but those would be new features with new definitions under new namespaces, and wouldn't need the 'restart' attribute. If the 'restart' attribute wasn't a MUST, the element wouldn't need to be defined either. There is just one case where it may be useful: for indicating that the im-session feature is optional, and saving a round trip, but then it might as well be defined for just that feature. > 5.2.4. Resending Features > > After completing negotiation of any stream feature (even stream > features that do not require a stream restart), the receiving entity > MUST send an updated list of stream features to the initiating > entity, where the list MAY be empty if there are no further features > to be advertised. > > At any time after stream establishment and before closing of the > stream, the receiving entity MAY send additional or modified stream > feature advertisements to the initiating entity (e.g., because a new > feature has been enabled). > This is pretty interesting. Features can change at runtime, and I had been looking for a way to advertise that. One thing which does make me hesitate in resending features is concern about how well existing clients and servers would cope with receiving them. Does anyone have any experience with this? How about a stream feature advertising an entity's ability to receive feature updates? -- Waqas Hussain --000e0cd59546f23bf9047506fa1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 3, 2009 at 5:50 AM= , Peter Saint-Andre=A0<stpeter@stpeter.im>=A0wrote:
=A0=A0If negotiation of a particular stream feature is mandatory, the
= =A0 stream feature advertisement MUST include an empty <required/> ch= ild
=A0 element.

=A0 If negotiation of a particular stream featur= e is voluntary, the
=A0 stream feature advertisement MAY include an empty <optional/> chi= ld
=A0 element. =A0However, because every stream feature defaults to
= =A0 voluntary, the inclusion of an empty <optional/> child element is= not
=A0 necessary to indicate that a stream feature is voluntary.

What namespace are these elements under? Just = inheriting the namespace of whatever feature they are included in is pretty= evil. Elements are qualified by their names AND namespaces. A name without= a namespace and a namespace without a name are meaningless. Specifying tha= t a name has a given meaning under any and all namespaces goes against the = spirit of XML namespaces and, if you think about it, is just plain Wrong(TM= ). Can we have a fixed namespace for these elements please?
=A0
=A0 For security reasons, certain stream features necessitate the
=A0 in= itiating entity to send a new initial stream header upon successful
=A0 = negotiation of the feature (e.g., TLS and SASL). =A0If a stream restart
= =A0 is necessary for any given feature, the <optional/> or <requir= ed/>
=A0 child element MUST include a boolean 'restart' attribute with a= value
=A0 of "true" or "1" (this optional attribute= defaults to false).
=A0 Although it is expected that stream restarts wi= ll be necessary only
=A0 for mandatory features, voluntary features are also allowed to
=A0 n= ecessitate restarts.

=A0 Aside from the <optional/> child elem= ent, <required/> child element,
=A0 and 'restart' attribut= e, the syntax and semantics of each particular
=A0 feature are defined by an appropriate specification of that feature;=A0 several such features are defined in this document but stream
=A0 f= eatures can be defined by other documents, as well.
I'm afraid I missed the discussion where the <optio= nal/> element and the 'restart' attribute were defined. Whether = a feature requires a stream restart or not is part of the definition of the= feature (e.g., it's part of the definitions of the SASL and STARTTLS f= eatures). If an entity understands a feature, then it already knows whether= a restart is required or not. What value does the 'restart' attrib= ute add? Are there any=A0use-cases=A0where the 'restart' attribute = saves the day?

The only case where the 'restart' attribute mig= ht be useful is for features which can work both with and without restarts,= and the server needs to specify at runtime whether it feels like doing a s= tream restart or not. I don't see any need for such features. This brin= gs to mind the restart-less SASL/etc negotiation discussed last year, but t= hose would be new features with new definitions under new namespaces, and w= ouldn't need the 'restart' attribute.

If the 'restart' attribute wasn't a MUST, t= he <optional/> element wouldn't need to be defined either. There = is just one case where it may be useful: for indicating that the im-session= feature is optional, and saving a round trip, but then it might as well be= defined for just that feature.
=A0
5.2.4. =A0Resending Features

=A0 After completing negotiation of any= stream feature (even stream
=A0 features that do not require a stream r= estart), the receiving entity
=A0 MUST send an updated list of stream fe= atures to the initiating
=A0 entity, where the list MAY be empty if there are no further features=A0 to be advertised.

=A0 At any time after stream establishment an= d before closing of the
=A0 stream, the receiving entity MAY send additi= onal or modified stream
=A0 feature advertisements to the initiating entity (e.g., because a new=A0 feature has been enabled).

T= his is pretty interesting. Features can change at runtime, and I had been l= ooking for a way to advertise that. One thing which does make me hesitate i= n resending features is concern about how well existing clients and servers= would cope with receiving them. Does anyone have any experience with this?= How about a stream feature advertising an entity's ability to receive = feature updates?

--
Waqas Hussain

--000e0cd59546f23bf9047506fa1d-- From jehan.marmottard@gmail.com Sun Oct 4 08:53:40 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7EF03A68A3 for ; Sun, 4 Oct 2009 08:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7sqKDI1+03X for ; Sun, 4 Oct 2009 08:53:40 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 853923A6896 for ; Sun, 4 Oct 2009 08:53:39 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so530895eye.51 for ; Sun, 04 Oct 2009 08:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=8WHgt1dEk24ITNkRPagjaJf4DQzshMN3QleswyCQ+xU=; b=Mn41z+qb4PEQrpbMCTwU8LGr5hrSJJuWmEY/2PrPFW165Zdd3UVsiVT2wHzs5t+cLP g5T5Mos+QccMrNb4Z8CLRoKiAFsha9L7FOkRKNTk1qzenPz5JN7+4s9JtwywdJapz6fF Ssp4tJSZhs1CUH5V2l8+HRqoF0ivKQKKqUp1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=iVKx3N31Nuyx1u2xSr5MagWvsgdFMbu/qrrE4b4cMR+Om8+pSEc2/vIs+S5SiwdpPY n0+gd/tEd4t/7xHIRUSbD6nwIBEEi1hXBsEOtspsVmLdAd+B1b6ItPhdjgX2r219iXzy uYI7hv+URKql6jtNDnSHaoz3675JzVotcekFk= MIME-Version: 1.0 Received: by 10.211.158.8 with SMTP id k8mr2096984ebo.98.1254671708395; Sun, 04 Oct 2009 08:55:08 -0700 (PDT) In-Reply-To: <7fc4fa880910030525n70396c92ye4fc2dac0d2e026a@mail.gmail.com> References: <4AC69FE3.30408@stpeter.im> <7fc4fa880910030525n70396c92ye4fc2dac0d2e026a@mail.gmail.com> Date: Mon, 5 Oct 2009 00:55:08 +0900 Message-ID: <75a410780910040855i718dd325t46bc8a5e76b6db4b@mail.gmail.com> From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: XMPP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 15:53:41 -0000 Hi, On Sat, Oct 3, 2009 at 9:50 AM, Peter Saint-Andre wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Earlier today I rewrote the section of 3920bis on stream features, > expanding it to cover the stream negotiation process in general. Thanks > to Jehan Pag=E8s for pointing out to me in private conversation that this > topic was underspecified. My provisional text follows. I will review > this again next, but as always feedback is welcome. My general feedback is that it looks very good. :-) Exactly how I had it in mind. Now it really becomes a "systematic" procedure, which can very easily be implemented on both clients and servers as a simple state machine. Just a simple note on the graph: after "restart required?" state, the "no" leads to "Receive stream features", and not to "Negotiation complete". Negotiation may be complete, but the server still needs to send an update (even though it may be empty) for the client to know it. This is well explained in your text, only the graph has the bug. On Sat, Oct 3, 2009 at 9:25 PM, Waqas Hussain wrote: > On Sat, Oct 3, 2009 at 5:50 AM, Peter > Saint-Andre=A0=A0wrote: >> >> =A0=A0If negotiation of a particular stream feature is mandatory, the >> =A0 stream feature advertisement MUST include an empty child >> =A0 element. >> >> =A0 If negotiation of a particular stream feature is voluntary, the >> =A0 stream feature advertisement MAY include an empty child >> =A0 element. =A0However, because every stream feature defaults to >> =A0 voluntary, the inclusion of an empty child element is no= t >> =A0 necessary to indicate that a stream feature is voluntary. > > What namespace are these elements under? Just inheriting the namespace of > whatever feature they are included in is pretty evil. Elements are qualif= ied > by their names AND namespaces. A name without a namespace and a namespace > without a name are meaningless. Specifying that a name has a given meanin= g > under any and all namespaces goes against the spirit of XML namespaces an= d, > if you think about it, is just plain Wrong(TM). Can we have a fixed > namespace for these elements please? > Right, I wondered this as well. I think the and element should be under the stream namespace. > I'm afraid I missed the discussion where the element and the > 'restart' attribute were defined. Whether a feature requires a stream > restart or not is part of the definition of the feature (e.g., it's part = of > the definitions of the SASL and STARTTLS features). If an entity understa= nds > a feature, then it already knows whether a restart is required or not. Wh= at > value does the 'restart' attribute add? Are there any=A0use-cases=A0where= the > 'restart' attribute saves the day? > The only case where the 'restart' attribute might be useful is for featur= es > which can work both with and without restarts, and the server needs to > specify at runtime whether it feels like doing a stream restart or not. I > don't see any need for such features. This brings to mind the restart-les= s > SASL/etc negotiation discussed last year, but those would be new features > with new definitions under new namespaces, and wouldn't need the 'restart= ' > attribute. I agree that 'restart' is not useful because, as you point it, if you know/negotiate the feature, you know whether or not the restart will be needed. And as you, I don't see a use case where it is useful... but maybe there will be in future, then it is better to plan it? That's the same thing as the element, I guess, but for another reason: it is the default value. It adds semantic. But except from this, it is useless. Hence may probably be safely removed if everyone wants to. > > This is pretty interesting. Features can change at runtime, and I had bee= n > looking for a way to advertise that. One thing which does make me hesitat= e > in resending features is concern about how well existing clients and serv= ers > would cope with receiving them. Does anyone have any experience with this= ? > How about a stream feature advertising an entity's ability to receive > feature updates? There don't need any feature (I guess by "stream feature", you meant in fact an entity capability? Because a stream feature is sent by a receiving entity, hence a server only) for that as it is already currently in the core spec (rfc 3920bis at least, I have not read the old 3920 for a while). So an entity is already supposed to be able to receive feature updates (even though it is not forced to do anything with it). Now I don't know if there is any current implementation doing something wit= h it. I have another note to make about sending updated features while the stream has already been negotiated. I raised it to Peter on private the other day, but he had to go, so we couldn't finish the discussion. Hence let's make it public now: what if the updated feature (in an already established stream) contains a "required" feature? Should the element be forbidden in features updated after stream establishement? If not, does it mean that it suspends your stream as long as you have not negotiated the new required feature (for instance a server which strengthens live its stream negotiation and want to force any existing connections to update?). Hence you cannot anymore send/receive stanzas, and an unavailable presence to all your roster is implied... Anyway something should be added about this (either an interdiction or an explanation about how to deal with such a case). Bye! Jehan From jehan.marmottard@gmail.com Sun Oct 4 09:30:38 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216CA3A6945 for ; Sun, 4 Oct 2009 09:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_20=-0.74, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MftJg7nGhTxH for ; Sun, 4 Oct 2009 09:30:37 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id DBD083A67D9 for ; Sun, 4 Oct 2009 09:30:36 -0700 (PDT) Received: by ewy28 with SMTP id 28so3382484ewy.42 for ; Sun, 04 Oct 2009 09:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nJu3mb7YOkB/IX3pXfWgWIivQNEgta8JvkRkAAAE9Xo=; b=hDThXEuk+9yJ/3L7wUumM1ZoaAJqOHj/UitACcUZ+k0AR3KVOcRsmhRDA9DhFqgVBx IK4QR9FgGhFjpOs/asKg3BbvlxOkYgYsvM32YDcRHOzd4xTxepsJVeGCcowE+IeL539z AXN19TKjwvCXYc8dswn6opPzPCs2WWFD3QfOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=PHkY3xb4TfzHyAzZUtYW3NZ9Q3R39S2h46svPdmN7lXYhC24OaQKrHrtQIAPu/HRrl 762Ql9OE3F+97kaNNf5expd7F+OckrIsw6fLOJ4WW4QCaDTK0YW1t1k7mj2gkBT0zyvc uB8MH9U0x4pGADjp6QKfiS4iGX7vIQUls5CNc= MIME-Version: 1.0 Received: by 10.211.159.15 with SMTP id l15mr5849158ebo.96.1254673927118; Sun, 04 Oct 2009 09:32:07 -0700 (PDT) In-Reply-To: <4AC3E223.2090805@stpeter.im> References: <75a410780909230901o1f705f94uee27599ffc3a31e1@mail.gmail.com> <4AC3E223.2090805@stpeter.im> Date: Mon, 5 Oct 2009 01:32:07 +0900 Message-ID: <75a410780910040932j1d0f83b3k5752b899ec498bd2@mail.gmail.com> From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Peter Saint-Andre , XMPP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [xmpp] Use of namespace in RFC 3920 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 16:30:38 -0000 Hi, 2009/10/1 Peter Saint-Andre : > I think that some points need to be clarified, but I do not agree with > all of your conclusions. > Sorry, did not want to speak in your name. My background sentence was not well written. >> The RFC is clearly trying to make an excuse for badly programmed XML >> parsers, not able to expand prefixes into namespaces (or keep track of >> declared prefix in parent elements). So you MUST absolutely have a >> default namespace in the root , and this one MUST be the one >> for the stanza ("jabber:client" or "jabber:server", most typically) + > > I see no reason to relax this restriction. Among other things, it would > break most XMPP implementations, which seems like a bad idea. > Hum... at this point, I will just quote Justin Karneges above: =AB At this point, I figure a good number of us are using off-the-shelf, compli= ant XML parsers, and so I would like to see the XML generation rules relaxed. = We can keep all of the backwards compatibility stuff marked with SHOULDs. =BB What I want to say and already said is that we are having the specification of a XML protocol relying on non compliant rules for no good reason. If this would really break suddenly many implementations, I would agree. But as I said and Justin said: it won't because it will be "SHOULD" and no developper will break its client on purpose against current servers. So it gives years to developers to fix this. Then at least we don't ask to all the developers using compliant XML parsers to make "tricks" for the only purpose of refusing perfectly compliant XML. >> you MUST have a prefix declared, for the stream related first level >> elements, > > As Dave pointed out, that falls out from having a default namespace. > >> and this prefix MUST be "stream". > > This is SHOULD in the spec. However, I think we can relax it to say only > that an implementation MAY accept only "stream:" as the prefix. You can > draw your own conclusions about whether you ought to set the prefix to > "stream:" in your implementation (e.g., to avoid interoperability problem= s). > For this point, I think I explained myself very bad. Indeed it is a SHOULD in the spec (and a "MAY" would be even better), but just after, the spec says: =AB If an entity receives a stream header with a streams namespace prefix it does not accept, it MUST return a stream error to the sending entity, which SHOULD be but MAY be . =BB So saying that it is allowed to send a prefix different than "stream" but that it is also ok for the peer entity to send you a stream error (which is the worse case as it breaks the connection and should only be used when you clearly break the spec!), I think there is clearly something wrong. It is as though there was a law telling that you have the right to do something, but that then, if you do it, the police has the right to arrest you. This is the same here,hence you can write a SHOULD or a MAY or whatever, in the end, it is just a fake SHOULD or MAY. I think such a text would be far better: =AB For historical reasons some implementations accept only the 'stream:' prefix and return a stream error to a sending entity sending another prefix (usually or ). Thus for backwards compatibility an implementation SHOULD generate only the 'stream:' prefix for these elements. =BB Here we still advice the use of a "stream" named prefix, but for good reasons and in a logical way (without contradiction). Then it will be as for the other point: no developer will break its implementation on purpose against current implementations and it will give years to change this if needed. Bye. Jehan From turners@ieca.com Tue Oct 6 08:25:15 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC11A3A694F for ; Tue, 6 Oct 2009 08:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf76xneVJpJT for ; Tue, 6 Oct 2009 08:25:15 -0700 (PDT) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by core3.amsl.com (Postfix) with SMTP id D45673A68E5 for ; Tue, 6 Oct 2009 08:25:14 -0700 (PDT) Received: (qmail 59196 invoked from network); 6 Oct 2009 15:25:10 -0000 Received: from unknown (HELO thunderfish.local) (turners@71.191.5.40 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 6 Oct 2009 15:25:10 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: FLUHb9wVM1myzluB1VBGdDJ.3evbSxZSaNuOb9eUpLW9v.o2TrxcIPr2qNag7ZwyOfiClPcM4U8HPNqPO6xSsmWWhbhKfPjfidJvKD44WABC4nYSWg1y_UjoEg__YKAsLtx0JCXU9P3MP7XhgfCNsNHhs33WL61d6FyZHMxkxoYOyIDPwF77NsxA4pWUJm4ajA2K5EzXBAmwrSD_XYGp5PwXFgnxfdKULXlI2EWihxXH.8192eLOnMG0sWtlcYJyfExjyKP.UXeXSaqfCD2tIMtCjP6okzirsjDBtopovNiJ0Zh41uSFEWHnXCgtk.SR2iq_YjzGyjWZq.4K3xXLda5k59gqq5PMqvDD3sx_HW7dZdoAkCKZ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACB6155.2010905@ieca.com> Date: Tue, 06 Oct 2009 11:25:09 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: XMPP Content-Type: multipart/mixed; boundary="------------060702080306040208080904" Subject: [xmpp] [Fwd: XMPP - Requested session has been scheduled for IETF 76] X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:25:15 -0000 This is a multi-part message in MIME format. --------------060702080306040208080904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI --------------060702080306040208080904 Content-Type: message/rfc822; name="XMPP - Requested session has been scheduled for IETF 76.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="XMPP - Requested session has been scheduled for IETF 76.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.75; Mon, 05 Oct 2009 18:58:33 -0700 X-YMailISG: LBXbtxAWLDuSosNJ3xyJUn4wM3PVGMKgS2N4s1CC6_1XPOXMchcU1C79RhX_HO2ZF0ROrPy6TF3ktgDqrDqNHs22ipckdOS9_gvloREjsOt.HrOFhS_lvAlfp9ahXIOcME80K6cK9fetEYNAbwvk9osT1J6ASTJQn_F.46V1rQqgg0mKMp3i5xGAErg9pvHxcd_ZyJCUJrAd8XK8JiDsAi5Egs.Ghch4h38M1TQEN0L4JyidGH4lkQbJ3ej.BBdsV.2zHuZe3vpPsNUaIhzoDvwiOBeSLzthSTMBjy2l_MUSEvN6iWHBFGVMjqo3_A6ajLfWGywVAAi2N8zILRpXmByJwdCC2DrEb5O2Mk7GZwJQ2kaLMYlcoJkvJLBjcaPNvjPAKiCcxllxRtI- X-Originating-IP: [64.170.98.32] Authentication-Results: mta107.biz.mail.re3.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta107.biz.mail.re3.yahoo.com with SMTP; Mon, 05 Oct 2009 18:58:33 -0700 Received: by core3.amsl.com (Postfix, from userid 30) id 9E1DF28C278; Mon, 5 Oct 2009 18:56:56 -0700 (PDT) From: IETF Secretariat To: turners@ieca.com Cc: jhildebr@cisco.com,rjsparks@nostrum.com,fluffy@cisco.com,session-request@ietf.org Subject: XMPP - Requested session has been scheduled for IETF 76 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091006015656.9E1DF28C278@core3.amsl.com> Date: Mon, 5 Oct 2009 18:56:56 -0700 (PDT) Dear Sean Turner, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the information of sessions that you have requested. XMPP Session 1 (2 hours) Wednesday, Afternoon Session I 1300-1500 Room Name: Cattleya 2 ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: xmpp Area Name: Real-time Applications and Infrastructure Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 2 hours Number of Attendees: 50 Conflicts to Avoid: First Priority: calsify httpbis keyprov netconf pkix saag sasl simple smime tls vcarddav avt dispatch drinks ecrit enum mmusic sipcore geopriv p2psip xcon speermint simple apparea Second Priority: bliss mediactrl Special Requests: --------------------------------------------------------- --------------060702080306040208080904-- From mwild1@gmail.com Mon Oct 12 13:54:19 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6363A6805 for ; Mon, 12 Oct 2009 13:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOQveWqGRVBN for ; Mon, 12 Oct 2009 13:54:18 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 571AF28C15B for ; Mon, 12 Oct 2009 13:54:18 -0700 (PDT) Received: by fxm28 with SMTP id 28so7860388fxm.42 for ; Mon, 12 Oct 2009 13:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=WGq20xCO8AIW8CkjjLcSYEL1SFHYl3yf2+YPl9SOvZQ=; b=iCESVt/eNstaigtKQpqLw++dQZL0a4NJjTF4x3fq9dIqhoQQao+8us26YJBtRnf4s4 +7n85LvMq7sfviwAHlsH0Kl+ftAyTOm+rwfTtIxWBiNtXqGenxGYiCckdEqwbWYXizRD PIj0KljFrXjeI20MoGW9rQx8GRkkb9Vmcn+Ls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xkoIRQfzAwj3V0vXLGHq3O49Swtni3CPnKznvfIu4sGz4iI4EXqhMeYke7Teb/Ml8M 5/n0FPVr+zUkKlAJuSjCkNptxBRT2ZP4urN0Y10M2msqI/dcpsW3Kh92SXSPW4hBQYYu 6W+nYiUYfWkqB3zbL0OL5YT5l5mrqOtZDsjOI= MIME-Version: 1.0 Received: by 10.204.2.205 with SMTP id 13mr1382113bkk.205.1255380850976; Mon, 12 Oct 2009 13:54:10 -0700 (PDT) Date: Mon, 12 Oct 2009 21:54:10 +0100 Message-ID: <4db9cacb0910121354k73d3b580g1e3ded0ce0fedf67@mail.gmail.com> From: Matthew Wild To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1 Subject: [xmpp] 3920: id attribute on error replies X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 20:54:19 -0000 Minor issue in 3920. I think it would be helpful to add in section 9.3 that when generating error replies in response to stanzas, the original stanza's 'id' attribute SHOULD be included in the reply. For example we already have this text in 9.1.3: The 'id' attribute is used by the entity that generates a stanza ("the originating entity") to track any response or error stanza that it might receive in relation to the generated stanza from another entity (such as an intermediate server or the intended recipient). But in truth there is no way (purely by the specs) to be sure error replies will contain the correct id. I'd hope that most implementations do the right thing (since this is common sense) but it makes sense to change it for the future. Agreed? Matthew From florian.zeitz@gmx.de Mon Oct 12 15:28:03 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260203A6805 for ; Mon, 12 Oct 2009 15:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yrCnplMPaXQ for ; Mon, 12 Oct 2009 15:28:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C47053A689B for ; Mon, 12 Oct 2009 15:28:01 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2009 22:28:01 -0000 Received: from xdsl-78-34-238-234.netcologne.de (EHLO [192.168.1.120]) [78.34.238.234] by mail.gmx.net (mp009) with SMTP; 13 Oct 2009 00:28:01 +0200 X-Authenticated: #30932406 X-Provags-ID: V01U2FsdGVkX185GvoVxMQ5Mh8wvQroq18vnxD7CgdtMOjewn+SZS w0cgmRhCGF7trF Message-ID: <4AD3AD70.7080509@gmx.de> Date: Tue, 13 Oct 2009 00:28:00 +0200 From: Florian Zeitz User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: xmpp@ietf.org References: <4db9cacb0910121354k73d3b580g1e3ded0ce0fedf67@mail.gmail.com> In-Reply-To: <4db9cacb0910121354k73d3b580g1e3ded0ce0fedf67@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Subject: Re: [xmpp] 3920: id attribute on error replies X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 22:28:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Wild wrote: > Minor issue in 3920. I think it would be helpful to add in section 9.3 > that when generating error replies in response to stanzas, the > original stanza's 'id' attribute SHOULD be included in the reply. > > For example we already have this text in 9.1.3: > > The 'id' attribute is used by the entity that generates a stanza > ("the originating entity") to track any response or error stanza that > it might receive in relation to the generated stanza from another > entity (such as an intermediate server or the intended recipient). > > But in truth there is no way (purely by the specs) to be sure error > replies will contain the correct id. I'd hope that most > implementations do the right thing (since this is common sense) but it > makes sense to change it for the future. > > Agreed? > > Matthew We also have: > For and stanzas, it is RECOMMENDED for the > originating entity to include an 'id' attribute; for stanzas, > it is REQUIRED. > > If the generated stanza includes an 'id' attribute then it is > REQUIRED for the response or error stanza to also include an 'id' > attribute, where the value of the 'id' attribute MUST match that of > the generated stanza. Which was AFAIR added exactly for this purpose ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrTrWoACgkQ0JXcdjR+9YRsMQCgsyRRTqA5H7otIyAkctznQxyp N7YAn2LYFwNZfW8oMDvzRXHYLy2dmaM+ =N1z5 -----END PGP SIGNATURE----- From mwild1@gmail.com Mon Oct 12 15:33:28 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5DA3A67EA for ; Mon, 12 Oct 2009 15:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+t80x8FTbPB for ; Mon, 12 Oct 2009 15:33:28 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 2CA4628C20B for ; Mon, 12 Oct 2009 15:33:19 -0700 (PDT) Received: by fxm28 with SMTP id 28so7917488fxm.42 for ; Mon, 12 Oct 2009 15:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T7hK+zR8Lg3gGDpnmOrtmY7XstTsB6r+ABe/j82IlgM=; b=RlMjWxDwVaOknONrbo0B+5XuYAJYmF4xUmhxSnalaIyLlas2Uo+nyc3gi/nV/vaq9B pWXZhpaCk5koJlqid+GOyJ/gH7qvtyZ8+l5hx3lBaoVe6nVszFClFc2UHp46fvHVtWvj LGvRnd88ax66mJR2LS1MJPVvqMYrp5gnRaDu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vgQ49PiKRiYZEGWj6z4+qZWwVl4Ckn+FyS7CTD5WoNzkMtdHld1uoAjR8YwG38fSgu kuhVurIYNSMOXco3MhrGFbGTsqz53x6ZvWsRiT22IYW5RlJdISAq/5+VKZHsShX7cBC0 hcprvarXHWo68vGkEsd53eqiIgUqQqeenN2JY= MIME-Version: 1.0 Received: by 10.204.32.16 with SMTP id a16mr5533351bkd.190.1255386796539; Mon, 12 Oct 2009 15:33:16 -0700 (PDT) In-Reply-To: <4AD3AD70.7080509@gmx.de> References: <4db9cacb0910121354k73d3b580g1e3ded0ce0fedf67@mail.gmail.com> <4AD3AD70.7080509@gmx.de> Date: Mon, 12 Oct 2009 23:33:16 +0100 Message-ID: <4db9cacb0910121533q3a99743at166f3dee28e44d37@mail.gmail.com> From: Matthew Wild To: Florian Zeitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] 3920: id attribute on error replies X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 22:33:29 -0000 2009/10/12 Florian Zeitz : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matthew Wild wrote: >> Minor issue in 3920. I think it would be helpful to add in section 9.3 >> that when generating error replies in response to stanzas, the >> original stanza's 'id' attribute SHOULD be included in the reply. >> >> For example we already have this text in 9.1.3: >> >> =A0 =A0The 'id' attribute is used by the entity that generates a stanza >> =A0 =A0("the originating entity") to track any response or error stanza = that >> =A0 =A0it might receive in relation to the generated stanza from another >> =A0 =A0entity (such as an intermediate server or the intended recipient)= . >> >> But in truth there is no way (purely by the specs) to be sure error >> replies will contain the correct id. I'd hope that most >> implementations do the right thing (since this is common sense) but it >> makes sense to change it for the future. >> >> Agreed? >> >> Matthew > > We also have: Now how did I miss that? :) I won't push it then, but still how about mentioning it in the section regarding error replies? Matthew From stpeter@stpeter.im Fri Oct 16 08:33:27 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1B93A699F for ; Fri, 16 Oct 2009 08:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIPgrqWGSf5f for ; Fri, 16 Oct 2009 08:33:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B4C773A688D for ; Fri, 16 Oct 2009 08:33:24 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 71BDA4038E; Fri, 16 Oct 2009 09:33:28 -0600 (MDT) Message-ID: <4AD8901C.1040504@stpeter.im> Date: Fri, 16 Oct 2009 09:24:12 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Waqas Hussain References: <4AC69FE3.30408@stpeter.im> <7fc4fa880910030525n70396c92ye4fc2dac0d2e026a@mail.gmail.com> In-Reply-To: <7fc4fa880910030525n70396c92ye4fc2dac0d2e026a@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 15:33:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My apologies for the delayed reply. On 10/3/09 6:25 AM, Waqas Hussain wrote: > On Sat, Oct 3, 2009 at 5:50 AM, Peter Saint-Andre > wrote: > > If negotiation of a particular stream feature is mandatory, the > stream feature advertisement MUST include an empty child > element. > > If negotiation of a particular stream feature is voluntary, the > stream feature advertisement MAY include an empty child > element. However, because every stream feature defaults to > voluntary, the inclusion of an empty child element is not > necessary to indicate that a stream feature is voluntary. > > > What namespace are these elements under? Just inheriting the namespace > of whatever feature they are included in is pretty evil. Elements are > qualified by their names AND namespaces. A name without a namespace and > a namespace without a name are meaningless. Specifying that a name has a > given meaning under any and all namespaces goes against the spirit of > XML namespaces and, if you think about it, is just plain Wrong(TM). Can > we have a fixed namespace for these elements please? I tend to agree. In fact I thought about it the morning after I wrote up the text I posted, but never replied on the list. :) In RFC 3920, the only feature that used was TLS. So we had feature declarations like this: R: You are recommending instead something like this: R: Now, what we've said is that the use of and is a convention that we will follow in defining all stream features, but I think you're right that it's better to define one qualified name for this, and probably place it in the streams namespace (we could define a new namespace just for optionality of stream features, but I don't see a compelling reason to do that). > For security reasons, certain stream features necessitate the > initiating entity to send a new initial stream header upon successful > negotiation of the feature (e.g., TLS and SASL). If a stream restart > is necessary for any given feature, the or > child element MUST include a boolean 'restart' attribute with a value > of "true" or "1" (this optional attribute defaults to false). > Although it is expected that stream restarts will be necessary only > for mandatory features, voluntary features are also allowed to > necessitate restarts. > > Aside from the child element, child element, > and 'restart' attribute, the syntax and semantics of each particular > feature are defined by an appropriate specification of that feature; > several such features are defined in this document but stream > features can be defined by other documents, as well. > > > I'm afraid I missed the discussion where the element and the > 'restart' attribute were defined. We're having that discussion now, at least for the 'restart' attribute (when writing up the state chart for the stream negotiation process I realized that it would be better to define restart explicitly instead of saying that it's implicit in certain features). > Whether a feature requires a stream > restart or not is part of the definition of the feature (e.g., it's part > of the definitions of the SASL and STARTTLS features). If an entity > understands a feature, then it already knows whether a restart is > required or not. What value does the 'restart' attribute add? Are there > any use-cases where the 'restart' attribute saves the day? IMHO it's better to be explicit than implicit in what's required throughout the stream negotiation process. > The only case where the 'restart' attribute might be useful is for > features which can work both with and without restarts, and the server > needs to specify at runtime whether it feels like doing a stream restart > or not. I don't see any need for such features. This brings to mind the > restart-less SASL/etc negotiation discussed last year, but those would > be new features with new definitions under new namespaces, and wouldn't > need the 'restart' attribute. One example is SASL: certain SASL mechanisms might require a stream restart (because they enable the negotiation of security layers) and certain SASL mechanisms might not (in fact the IETF seems to be moving away from security layers and toward channel bindings, so in the future an XMPP server might not offer any SASL mechanisms that would truly require a restart). In this case, why force a stream restart when it isn't really necessary? > If the 'restart' attribute wasn't a MUST, the element > wouldn't need to be defined either. There is just one case where it may > be useful: for indicating that the im-session feature is optional, and > saving a round trip, but then it might as well be defined for just that > feature. Well, and are really not ideal because they're defining a boolean. It would be better to have something like this: R: Here both attributes would default to FALSE. > 5.2.4. Resending Features > > After completing negotiation of any stream feature (even stream > features that do not require a stream restart), the receiving entity > MUST send an updated list of stream features to the initiating > entity, where the list MAY be empty if there are no further features > to be advertised. > > At any time after stream establishment and before closing of the > stream, the receiving entity MAY send additional or modified stream > feature advertisements to the initiating entity (e.g., because a new > feature has been enabled). > > > This is pretty interesting. Features can change at runtime, and I had > been looking for a way to advertise that. One thing which does make me > hesitate in resending features is concern about how well existing > clients and servers would cope with receiving them. Does anyone have any > experience with this? AFAIK, no XMPP software supports this behavior now. > How about a stream feature advertising an entity's > ability to receive feature updates? Nothing in RFC 3920 forbids this behavior, and in any case what you want is a feature that could be advertised by the initiating entity (so that it can tell the receiving entity "yes I support feature updates"). But that gets into the question of feature declarations from the initiating entity to the receiving entity, which is also interesting but not yet defined. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrYkBsACgkQNL8k5A2w/vwN6wCgmpopFKkgMY776YxJPEO/q4QM 80UAniOD93CGeh6MDU6yZxUXuonItbRr =Ld1p -----END PGP SIGNATURE----- From Joe.Hildebrand@webex.com Fri Oct 16 14:50:06 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DE63A67F4 for ; Fri, 16 Oct 2009 14:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.532 X-Spam-Level: X-Spam-Status: No, score=-104.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2wJVpAVWUNL for ; Fri, 16 Oct 2009 14:50:06 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id E8AD13A65A6 for ; Fri, 16 Oct 2009 14:50:05 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 14:50:09 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Oct 2009 21:49:46 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 16 Oct 2009 15:49:44 -0600 From: Joe Hildebrand To: Peter Saint-Andre , Waqas Hussain Message-ID: Thread-Topic: [xmpp] the stream negotiation process Thread-Index: AcpOqpJWVrol7FZu7UKWPPK9bzo2wA== In-Reply-To: <4AD8901C.1040504@stpeter.im> IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Oct 2009 21:50:09.0801 (UTC) FILETIME=[A1B6F790:01CA4EAA] Cc: XMPP Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:50:06 -0000 (as individual) On 10/16/09 9:24 AM, "Peter Saint-Andre" wrote: > You are recommending instead something like this: > > R: > > > > > > Now, what we've said is that the use of and is a > convention that we will follow in defining all stream features, but I > think you're right that it's better to define one qualified name for > this, and probably place it in the streams namespace (we could define a > new namespace just for optionality of stream features, but I don't see a > compelling reason to do that). +1. I really like that approach. >> Whether a feature requires a stream >> restart or not is part of the definition of the feature (e.g., it's part >> of the definitions of the SASL and STARTTLS features). If an entity >> understands a feature, then it already knows whether a restart is >> required or not. What value does the 'restart' attribute add? Are there >> any use-cases where the 'restart' attribute saves the day? > > IMHO it's better to be explicit than implicit in what's required > throughout the stream negotiation process. It also makes writing clients much easier, because they can process stream restarts generically. > Well, and are really not ideal because they're > defining a boolean. It would be better to have something like this: > > R: > > > > > > Here both attributes would default to FALSE. As well, servers SHOULD allow SASL restarts even if restart='false', for backward-compatibility. >> How about a stream feature advertising an entity's >> ability to receive feature updates? > > Nothing in RFC 3920 forbids this behavior, and in any case what you want > is a feature that could be advertised by the initiating entity (so that > it can tell the receiving entity "yes I support feature updates"). > > But that gets into the question of feature declarations from the > initiating entity to the receiving entity, which is also interesting but > not yet defined. The question is whether late stream features will break existing client software. I think there is a possibility. I've had several bad ideas about how to have clients and servers know that they both support this, but all of them are heavy-weight compared to a) the utility and b) the risk. Maybe we should just do some client/library testing to see what happens. :) -- Joe Hildebrand From Joe.Hildebrand@webex.com Mon Oct 19 17:07:20 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1E13A69DD for ; Mon, 19 Oct 2009 17:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.532 X-Spam-Level: X-Spam-Status: No, score=-104.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm7R0zuuu-mb for ; Mon, 19 Oct 2009 17:07:19 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 7467C28C21C for ; Mon, 19 Oct 2009 17:06:19 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 17:06:26 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Oct 2009 00:06:26 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 19 Oct 2009 18:06:24 -0600 From: Joe Hildebrand To: Message-ID: Thread-Topic: draft-hildebrand-dna-00 Thread-Index: AcpRGSkoDX9djjXdxkCsUEXAG/tpFA== IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 00:06:26.0669 (UTC) FILETIME=[2ABF41D0:01CA5119] Subject: [xmpp] draft-hildebrand-dna-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 00:07:20 -0000 I just posted draft-hildebrand-dna (see: http://www.ietf.org/id/draft-hildebrand-dna-00.txt). It's still pretty rough, but it has Sean's first pass at Attribute Certificate language. As we discussed in Stockholm (and at the XMPP Summit before that), this is an approach to help us host XMPP services on large, multi-domain providers, while still doing meaningful encryption. Comments are encouraged. -- Joe Hildebrand From Joe.Hildebrand@webex.com Mon Oct 19 21:49:13 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED62A3A68B0 for ; Mon, 19 Oct 2009 21:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEUunl0U8AaM for ; Mon, 19 Oct 2009 21:49:13 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 310983A6801 for ; Mon, 19 Oct 2009 21:49:12 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 21:49:20 -0700 Received: from 10.21.145.15 ([10.21.145.15]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Oct 2009 04:48:42 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 19 Oct 2009 22:48:41 -0600 From: Joe Hildebrand To: Dave Cridland , XMPP Working Group , Peter Saint-Andre , Waqas Hussain Message-ID: Thread-Topic: [xmpp] the stream negotiation process Thread-Index: AcpRBagFLOy7ZCjTR3yWh5lAWqgp9QAOvBiW In-Reply-To: <29219.1255988801.730161@puncture> IM-ID: xmpp:jhildebrand@corp.jabber.com Presence-ID: xmpp:jhildebrand@corp.jabber.com Jabber-ID: jhildebrand@corp.jabber.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 04:49:20.0264 (UTC) FILETIME=[AFCC5080:01CA5140] Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 04:49:14 -0000 On 10/19/09 3:46 PM, "Dave Cridland" wrote: > 1) You probably don't want to require features. Instead, you only > want to drop the ones the clients not allowed to use right now. We at least need to require TLS, because in some installations you want it required (high security), and in others it needs to be optional (e.g. mobile clients on a trusted network). In the past we've used "required" for this, and there's no good reason to switch it to "optional". > 2) Optional might not be needed either. If it is, it's only for the > session feature, and that only if it's actually required to be > listed, and that could be solved by a new feature, pipelining, or a > specific child for session's feature. My understanding was that we had some consensus to drop session start. In order to deal with backward-compatibility, we need to signal to new clients that the feature is optional. TLS and session don't need to use the same syntax for expressing these optional or required, but some have expressed that desire. That's how we've gotten to this point. We could also (obviously) decide that this is out of scope. > So really, I think we're chasing ghosts, here. If there's > optimizations to be made, let's please figure them out and make them. > But making things too generic is simply over-engineering something > that actually works just fine right now. Hence the "several bad ideas" I referred to in my previous mail. I don't think anyone has proposed an acceptable solution to modifying stream features on the fly, so in the absence of an extraordinarily compelling use case, I agree that keeping it simple makes sense. -- Joe Hildebrand From dave@cridland.net Tue Oct 20 16:18:51 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5953A681A for ; Tue, 20 Oct 2009 16:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4gAjRqYIbvU for ; Tue, 20 Oct 2009 16:18:49 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 0ED913A687E for ; Tue, 20 Oct 2009 16:18:46 -0700 (PDT) Received: from puncture ([217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Mon, 19 Oct 2009 22:46:38 +0100 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <29219.1255988801.730161@puncture> Date: Mon, 19 Oct 2009 22:46:41 +0100 From: Dave Cridland To: Joe Hildebrand , XMPP Working Group , Peter Saint-Andre , Waqas Hussain Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:18:51 -0000 On Fri Oct 16 22:49:44 2009, Joe Hildebrand wrote: > (as individual) > > On 10/16/09 9:24 AM, "Peter Saint-Andre" wrote: > > > You are recommending instead something like this: > > > > R: > > > > > > > > > > > > Now, what we've said is that the use of and > is a > > convention that we will follow in defining all stream features, > but I > > think you're right that it's better to define one qualified name > for > > this, and probably place it in the streams namespace (we could > define a > > new namespace just for optionality of stream features, but I > don't see a > > compelling reason to do that). > > +1. I really like that approach. > > I think this is better than the original proposition, but my worry is that it only makes sense when there is, for sake of example, only one way to skin a cat. When there are multiple features that fulfill the requirements, it seems that the logic becomes fairly complex. I don't see this happening for cases like TLS, in fact, for reasons I'll go into in a second, but for post-auth cases, I think we're trying to solve a problem for which we have no use cases. For preauth, what the server is actually trying to express is generally security requirements. Perhaps the logical thing to do, if we really want to radically change the old , is to have the server provide security requirements in some form - that form seems like something for some other working group to solve, though. But really, what we're trying to do is usually pretty simple - require encryption or not. The simple approach here is to provide features like: GSSAPI Then the client gets to pick one of those two. Picking gives it TLS, and the servers offers more mechanisms - mechanisms without a security layer as well, probably. Notice I've not used . I'm not convinced that is even needed here. The interesting case is actually , which *is* required for the old session stuff - if it weren't for the fact you can pipeline it. (And here I assume there may be good reasons to list the feature for old clients, but I'm not convinced). > >> Whether a feature requires a stream > >> restart or not is part of the definition of the feature (e.g., > it's part > >> of the definitions of the SASL and STARTTLS features). If an > entity > >> understands a feature, then it already knows whether a restart is > >> required or not. What value does the 'restart' attribute add? > Are there > >> any use-cases where the 'restart' attribute saves the day? > > > > IMHO it's better to be explicit than implicit in what's required > > throughout the stream negotiation process. > > It also makes writing clients much easier, because they can process > stream > restarts generically. > > I think you must write clients in a wholly different way to me. My XMPP client (the one I wrote for myself) has precisely two lines devoted to the thorny issue of stream restarts. I just don't see the problem. Surely the definition of the feature is very explicit in whether or not the feature requires a stream restart? (Incidentally, I just looked at the relevant places in our server code, and there's *four* lines, there. It's sheer madness, escalating out of control, and it must stop now! Or maybe not.) I mean, if I suddenly decide that the resource binding requires a stream restart, what on earth should a client do? Restart the stream once it receives an ? With what from attribute? What does a server do if the client doesn't restart? Reject it? With what error? > > Well, and are really not ideal because > they're > > defining a boolean. It would be better to have something like > this: > > > > R: > > > > > > > > > > > > Here both attributes would default to FALSE. > > As well, servers SHOULD allow SASL restarts even if > restart='false', for > backward-compatibility. > > Yay. But you can only not require a restart for TLS and SASL if you also allow for mid-stream feature updates. We need this because the security properties of the stream may change, and it's *far* easier to mandate a restart in all cases of TLS and SASL, instead of merely "when the security properties change". (It'd be marginally easier with SASL, actually, since when the security properties change the client generally knows about it, but still.) I really don't think that leaving this to server choice is very wise at all. > >> How about a stream feature advertising an entity's > >> ability to receive feature updates? > > > > Nothing in RFC 3920 forbids this behavior, and in any case what > you want > > is a feature that could be advertised by the initiating entity > (so that > > it can tell the receiving entity "yes I support feature updates"). > > > > But that gets into the question of feature declarations from the > > initiating entity to the receiving entity, which is also > interesting but > > not yet defined. > > The question is whether late stream features will break existing > client > software. I think there is a possibility. I've had several bad > ideas about > how to have clients and servers know that they both support this, > but all of > them are heavy-weight compared to a) the utility and b) the risk. Right. And without this there is no longer any value to avoiding restarts for TLS, certainly, and SASL, probably. > Maybe we should just do some client/library testing to see what > happens. :) Yes, because luckily, we're confident we can exhaustively test all extant XMPP clients with all possible feature changes. The XMPP community is pretty close-knit, but not that close-knit. Besides which, features are for stream properties - by the time the stream is established, it's too late to change these. If the change is, say, mandating TLS, then you *want* to kick off all your connections. Instead, if people really want to shave a restart off SASL, have an extra parameter to which causes the server to drop support for security layers, and pipeline a after the . Perhaps - because it's a zero-octet switchover, it makes some sense there. Doing the same for TLS is much harder - in principle it's possible, but won't save any round-trips if client session resumption is being used, if memory serves. (More round-trips are saved by batshit crazy stuff like Stunt Buffering, as Tony Finch once called it). So, here's a summary: 1) You probably don't want to require features. Instead, you only want to drop the ones the clients not allowed to use right now. 2) Optional might not be needed either. If it is, it's only for the session feature, and that only if it's actually required to be listed, and that could be solved by a new feature, pipelining, or a specific child for session's feature. 3) Altering restart behaviour on the fly is only possible if features can be sent on the fly. 4) And they can't - it's simply too big a change for the protocol. So really, I think we're chasing ghosts, here. If there's optimizations to be made, let's please figure them out and make them. But making things too generic is simply over-engineering something that actually works just fine right now. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Tue Oct 20 16:20:49 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D5B3A681A for ; Tue, 20 Oct 2009 16:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX+1KqgigA9c for ; Tue, 20 Oct 2009 16:20:48 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id B74C328B797 for ; Tue, 20 Oct 2009 16:20:47 -0700 (PDT) Received: from puncture ([217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Tue, 20 Oct 2009 08:58:16 +0100 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <14858.1256025498.543955@puncture> Date: Tue, 20 Oct 2009 08:58:18 +0100 From: Dave Cridland To: Joe Hildebrand , XMPP Working Group , Peter Saint-Andre , Waqas Hussain Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:20:49 -0000 On Tue Oct 20 05:48:41 2009, Joe Hildebrand wrote: > On 10/19/09 3:46 PM, "Dave Cridland" wrote: > > > 1) You probably don't want to require features. Instead, you only > > want to drop the ones the clients not allowed to use right now. > > We at least need to require TLS, because in some installations you > want it > required (high security), and in others it needs to be optional > (e.g. mobile > clients on a trusted network). In the past we've used "required" > for this, > and there's no good reason to switch it to "optional". > > But my point here is that you either offer a method to authenticate without encryption, or you don't. If you offer no SASL mechanisms at all, then you're effectively requiring TLS. If you offer some selected SASL mechanisms, you're requiring some security policy embodied by that selection, like encryption, or no plaintext passwords. If you offer all your mechanisms, then you're signalling you have a very liberal security policy. IMAP, ACAP, ESMTP, Submission - none of these have the need to signal that TLS is required explicitly. That's not to say we couldn't improve on this, but that's only possible if there *is* a better solution. > > 2) Optional might not be needed either. If it is, it's only for > the > > session feature, and that only if it's actually required to be > > listed, and that could be solved by a new feature, pipelining, or > a > > specific child for session's feature. > > My understanding was that we had some consensus to drop session > start. In > order to deal with backward-compatibility, we need to signal to new > clients > that the feature is optional. > > Agreed. There are a handful of server implementations out there that require session start. My client implementation (written a few years ago, now) simply doesn't bother with session start unless it sees the feature advertised, but I doubt that all clients will cope without the feature being advertised at all, sadly. > TLS and session don't need to use the same syntax for expressing > these > optional or required, but some have expressed that desire. That's > how we've > gotten to this point. We could also (obviously) decide that this > is out of > scope. > > The thing is, there's no need at all to signal that TLS is optional. All features are optional, the only exception is session-start, which historically has been mandatory, and we now need to explicitly signal that it's optional. So let's pick a method of doing so, and not turn this into a forced-march into the weeds. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Wed Oct 21 08:04:17 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D103A6982 for ; Wed, 21 Oct 2009 08:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldmySIh4+6bP for ; Wed, 21 Oct 2009 08:04:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3366D3A689A for ; Wed, 21 Oct 2009 08:04:16 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 984DC40D0B; Wed, 21 Oct 2009 09:04:21 -0600 (MDT) Message-ID: <4ADF1E7B.20804@stpeter.im> Date: Wed, 21 Oct 2009 08:45:15 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dave Cridland References: <14858.1256025498.543955@puncture> In-Reply-To: <14858.1256025498.543955@puncture> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Joe Hildebrand , XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 15:04:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/09 1:58 AM, Dave Cridland wrote: Dave, let me see if I can summarize your perspective... 1. Negotiation of all stream features is optional. If the receiving entity considers negotiation of a given feature to be mandatory, it will advertise only that feature; and if the initiating entity does not negotiate that feature (e.g., by attempting to send stanzas before it is allowed to do so), then the receiving entity will return an error to the initiating entity. Therefore, we have no need to specify over the wire if a given stream feature must be negotiated at any given stage of the stream negotiation process. 2. Whether a stream restart is mandatory is defined by the stream feeature and does not need to be specified on the wire. All that 3920bis needs to say is that the definition of a stream feature must specify whether stream restarts are necessary after negotiation of that feature. Is that an accurate summary? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrfHnsACgkQNL8k5A2w/vydBQCdH339g4sozqgQ4iVf6ubESinW DMkAnA9MZ28l5mdWOIq1aN2hIFpbQFyY =vnCD -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Oct 22 13:08:02 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9AB3A69D3 for ; Thu, 22 Oct 2009 13:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwZtg6qxQicA for ; Thu, 22 Oct 2009 13:08:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AD4473A67B2 for ; Thu, 22 Oct 2009 13:08:00 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0D90140341; Thu, 22 Oct 2009 14:08:09 -0600 (MDT) Message-ID: <4AE0BBA8.1030601@stpeter.im> Date: Thu, 22 Oct 2009 14:08:08 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dave Cridland References: <14858.1256025498.543955@puncture> <4ADF1E7B.20804@stpeter.im> In-Reply-To: <4ADF1E7B.20804@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:08:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My apologies for the long post... On 10/21/09 8:45 AM, Peter Saint-Andre wrote: > On 10/20/09 1:58 AM, Dave Cridland wrote: > > > > Dave, let me see if I can summarize your perspective... Because I am working to publish revised versions of 3920bis and 3921bis by the I-D cutoff date on Monday, I shall assume that my summary is accurate. :) > 1. Negotiation of all stream features is optional. If the receiving > entity considers negotiation of a given feature to be mandatory, it will > advertise only that feature; and if the initiating entity does not > negotiate that feature (e.g., by attempting to send stanzas before it is > allowed to do so), then the receiving entity will return an error to the > initiating entity. Therefore, we have no need to specify over the wire > if a given stream feature must be negotiated at any given stage of the > stream negotiation process. For TLS, we felt the need in RFC 3920 to define a method whereby the server could flag negotiation of TLS as mandatory to negotiate ("MTN") in order to enforce local service policies. The discussions since then have always assumed that we need a way to flag (some) features as MTN. The thread here has attempted to define MTN in a standardized way, rather than assuming that MTN will be explicit in the definition of some features (TLS) but not others (everything else), implicit in the definition of a given feature (SASL is always mandatory) or implicit via the inclusion of a given feature and only that feature at a particular point in the stream negotiation process (what Mr. Cridland appears to be suggesting). I think the following are very different: (a) As the first stream features, inform the initating entity that TLS is MTN. (b) At some point in the stream negotiation process, inform the initiating entity that SASL is MTN. DIGEST-MD5 PLAIN (c) As the last stream features (after resource binding), inform the initiating entity that stream compression is voluntary to negotiate ("VTN"). zlib lzw If we say that a feature is MTN if it is the only feature advertised at a particular point in the stream negotiation process, then (c) would mean compression is MTN after resource binding. Because that is non-sensical, I must conclude that all features are VTN unless explicitly defined otherwise (i.e., we cannot deduce that a feature is MTN simply by the absence of other features in that particular instance of stream features advertisement). The initiating entity can implicitly know that a given feature is MTN (we "just know" that SASL is MTN because you must authenticate) or the receiving entity can explicitly inform the intitiating entity (we don't "just know" and therefore need a way for the receiving entity to inform the initiating entity that Feature X is MTN). I don't like these things to be implicit (the stream feature approach is open-ended and we don't know what features people might define in the future), which is why I think that we need some kind of method for explicitly signalling that a feature is MTN. We have two options: 1. Place the burden on each stream feature. Therefore we might end up with things like this: vs. DIGEST-MD5 PLAIN vs. zlib lzw 2. Define a generalized data structure that can be re-used by all stream features. DIGEST-MD5 PLAIN zlib lzw Option #2 is a lot cleaner, it can be re-used by any stream feature that people might define in the future, it simplifies processing by the initiating entity, and it reduces the chance of nasty surprises (e.g., disconnections because the initiating entity assumed that Feature X was VTN while the receiving entity assumed that Feature X was MTN). > 2. Whether a stream restart is mandatory is defined by the stream > feeature and does not need to be specified on the wire. All that 3920bis > needs to say is that the definition of a stream feature must specify > whether stream restarts are necessary after negotiation of that feature. Here again, I think it would be helpful to be explicit about whether a restart is needed or not. In general, stream restarts apply to any protocol in which the entities need to discard information received in an insecure manner before the given feature was negotiated. Right now that is true only for TLS and for SASL-with-security-layers. It is probably unlikely that we will define new technologies that also force stream restarts (since they would essentially be replacements for TLS or for SASL-with-security-layers), so I am not as worked up about defining an explicit signalling method here. However, it seems to me that if we are defining an explicit signalling method for MTN vs. VTN then we might as well define one for restarts while we're at it. I will update -03 along these lines and flag this as an item for discussion on the list and in Hiroshima. There is one more issue that is still unclear in -02: how to handle stream feature advertisements that contain multiple features. The following combinations are possible: (a) 1+ features, all of which are MTN. (b) 1+ features, 1 or 1+ (but not all) of which are MTN. (c) 1+ features, none of which are MTN. In the case of (a) I think the initiating just picks one MTN feature to negotiate based on local preferences. In the case of (b) I think the initiating entity can negotiate one of the VTN features (say, in-band registration instead of SASL) or one of the MTN features, but it needs to negotiate something. In the case of (c) I think the initiating entity can negotiate any of the features or none of the features. I tried to capture this in the state chart, but I've made a few edits to the chart since -02 and those will show up in -03. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrgu6gACgkQNL8k5A2w/vw+sACfRmv2L2HjV0l1Ml3h79zxql+Q JagAn0Xa9+bsDfuuZ4hfdHL2WhxD7V8E =syg/ -----END PGP SIGNATURE----- From waqas20@gmail.com Thu Oct 22 17:49:26 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDCA28C194 for ; Thu, 22 Oct 2009 17:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOjkAmXFRoxW for ; Thu, 22 Oct 2009 17:49:24 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id D52333A68B4 for ; Thu, 22 Oct 2009 17:49:23 -0700 (PDT) Received: by ywh13 with SMTP id 13so11605127ywh.29 for ; Thu, 22 Oct 2009 17:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rJ8vt4P+Nj1e//kC7HY3+9hquwHmSV/reIPIBIRK1z8=; b=mUYhcVJ8hHdAZjt5+QUWYsqatHjYds1JfijI5flY+nZ5uyKygvMQOvRFJfw5dphZAP tGvTI3T5f3D5axhwNNvKYdjHno/Z66zC3A4qbxSwcA1z0R86z5hyyRRG+caImrRFlwux UNK1+/ywaOY11KhVSKy1CXCAc9vggAhyqZ6C0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AbueiAqCbFYcnIDEydKNchpMf7fQ0LzDt3zRd0mSOnpOCBA9brlavaItDdbTHyD/NS /H8S7vbuhIQa1/vtTakMlQrdYKOAKZ2LFZDBndBP1k4HGvkjuinuxHfNh/Nmo4GePPOd 5GUYs/IELXEZEKZ345hkwpVmpXo8aqe0qL7rE= MIME-Version: 1.0 Received: by 10.150.1.18 with SMTP id 18mr3286765yba.156.1256258970724; Thu, 22 Oct 2009 17:49:30 -0700 (PDT) In-Reply-To: <4AE0BBA8.1030601@stpeter.im> References: <14858.1256025498.543955@puncture> <4ADF1E7B.20804@stpeter.im> <4AE0BBA8.1030601@stpeter.im> Date: Fri, 23 Oct 2009 05:49:30 +0500 Message-ID: <7fc4fa880910221749m62463793w4f0ea806e06bb954@mail.gmail.com> From: Waqas Hussain To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=000e0cd48830b22b2f04768f9580 Cc: XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 00:49:26 -0000 --000e0cd48830b22b2f04768f9580 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 23, 2009 at 1:08 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My apologies for the long post... > > On 10/21/09 8:45 AM, Peter Saint-Andre wrote: > > On 10/20/09 1:58 AM, Dave Cridland wrote: > > > > > > > > Dave, let me see if I can summarize your perspective... > > Because I am working to publish revised versions of 3920bis and 3921bis > by the I-D cutoff date on Monday, I shall assume that my summary is > accurate. :) > > 1. Negotiation of all stream features is optional. If the receiving > > entity considers negotiation of a given feature to be mandatory, it will > > advertise only that feature; and if the initiating entity does not > > negotiate that feature (e.g., by attempting to send stanzas before it is > > allowed to do so), then the receiving entity will return an error to the > > initiating entity. Therefore, we have no need to specify over the wire > > if a given stream feature must be negotiated at any given stage of the > > stream negotiation process. > > For TLS, we felt the need in RFC 3920 to define a method whereby the > server could flag negotiation of TLS as mandatory to negotiate ("MTN") > in order to enforce local service policies. The discussions since then > have always assumed that we need a way to flag (some) features as MTN. > And that's the assumption being questioned here :-) > The thread here has attempted to define MTN in a standardized way, > rather than assuming that MTN will be explicit in the definition of some > features (TLS) but not others (everything else), implicit in the > definition of a given feature (SASL is always mandatory) or implicit via > the inclusion of a given feature and only that feature at a particular > point in the stream negotiation process (what Mr. Cridland appears to be > suggesting). > > I think the following are very different: > > (a) As the first stream features, inform the initating entity that TLS > is MTN. > > > > > > > > (b) At some point in the stream negotiation process, inform the > initiating entity that SASL is MTN. > > > > DIGEST-MD5 > PLAIN > > > > (c) As the last stream features (after resource binding), inform the > initiating entity that stream compression is voluntary to negotiate > ("VTN"). > > > > zlib > lzw > > > > If we say that a feature is MTN if it is the only feature advertised at > a particular point in the stream negotiation process, then (c) would > mean compression is MTN after resource binding. Because that is > non-sensical, I must conclude that all features are VTN unless > explicitly defined otherwise (i.e., we cannot deduce that a feature is > MTN simply by the absence of other features in that particular instance > of stream features advertisement). > As far as I can see, the need here isn't for individual features to be MTN or VTN, but a way for the server to indicate its readiness for normal XMPP IM. From what I have seen, the algorithm clients (and servers) tend to use is to negotiate all negotiable features they are able and configured to negotiate, and as the last step they bind a resource. At this point they assume the server is ready for XMPP IM. This seems reasonable enough, and I have not seen clients actually testing individual features for being MTN or VTN. While what I just said applies to C2S, the process used by other initiating entities isn't any different. The initiating entities are only interested in the stream's readiness for their purposes, not about individual features being MTN or VTN (or non-negotiable; not all features are negotiable). > The initiating entity can implicitly know that a given feature is MTN > (we "just know" that SASL is MTN because you must authenticate) or the > receiving entity can explicitly inform the intitiating entity (we don't > "just know" and therefore need a way for the receiving entity to inform > the initiating entity that Feature X is MTN). > > I don't like these things to be implicit (the stream feature approach is > open-ended and we don't know what features people might define in the > future), which is why I think that we need some kind of method for > explicitly signalling that a feature is MTN. We have two options: > > 1. Place the burden on each stream feature. Therefore we might end up > with things like this: > > > > > > > > vs. > > > mandatory='true'> > DIGEST-MD5 > PLAIN > > > > vs. > > > > zlib > lzw > > > > > 2. Define a generalized data structure that can be re-used by all stream > features. > > > > > > > > > > DIGEST-MD5 > PLAIN > > > > > > > zlib > lzw > > > > > Option #2 is a lot cleaner, it can be re-used by any stream feature that > people might define in the future, it simplifies processing by the > initiating entity, and it reduces the chance of nasty surprises (e.g., > disconnections because the initiating entity assumed that Feature X was > VTN while the receiving entity assumed that Feature X was MTN). If the MTN vs. VTN distinction was really necessary, I would agree. > > 2. Whether a stream restart is mandatory is defined by the stream > > feeature and does not need to be specified on the wire. All that 3920bis > > needs to say is that the definition of a stream feature must specify > > whether stream restarts are necessary after negotiation of that feature. > > Here again, I think it would be helpful to be explicit about whether a > restart is needed or not. In general, stream restarts apply to any > protocol in which the entities need to discard information received in > an insecure manner before the given feature was negotiated. Right now > that is true only for TLS and for SASL-with-security-layers. It is > probably unlikely that we will define new technologies that also force > stream restarts (since they would essentially be replacements for TLS or > for SASL-with-security-layers), so I am not as worked up about defining > an explicit signalling method here. However, it seems to me that if we > are defining an explicit signalling method for MTN vs. VTN then we might > as well define one for restarts while we're at it. I will update -03 > along these lines and flag this as an item for discussion on the list > and in Hiroshima. > If the MTN vs. VTN distinction was really necessary, this would be still be arguable. > There is one more issue that is still unclear in -02: how to handle > stream feature advertisements that contain multiple features. The > following combinations are possible: > > (a) 1+ features, all of which are MTN. > (b) 1+ features, 1 or 1+ (but not all) of which are MTN. > (c) 1+ features, none of which are MTN. > > In the case of (a) I think the initiating just picks one MTN feature to > negotiate based on local preferences. > > In the case of (b) I think the initiating entity can negotiate one of > the VTN features (say, in-band registration instead of SASL) or one of > the MTN features, but it needs to negotiate something. > So, basically as far as the initiating entity is concerned, there is no distinction between (a) and (b). The initiating entity will do the same thing for either case: Pick any one feature it likes. > In the case of (c) I think the initiating entity can negotiate any of > the features or none of the features. > And only (c) really matters. That is, all that matters is a signal that negotiation is complete. Currently, for C2S this is assumed to be the case after resource binding, and for S2S this is assumed to be the case after auth (SASL or dialback). Your goal seems to be making this explicit. Wouldn't a simple stream feature making this explicit be enough? What would an MTN/VTN flag on each feature buy us that a (or more appropriately , etc) feature will not? > I tried to capture this in the state chart, but I've made a few edits to > the chart since -02 and those will show up in -03. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > -- Waqas Hussain --000e0cd48830b22b2f04768f9580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 23, 2009 at 1:08 AM, Peter Saint-And= re <stpeter@stpe= ter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My apologies for the long post...

On 10/21/09 8:45 AM, Peter Saint-Andre wrote:
> On 10/20/09 1:58 AM, Dave Cridland wrote:
>
> <snip/>
>
> Dave, let me see if I can summarize your perspective...

Because I am working to publish revised versions of 3920bis and 3921b= is
by the I-D cutoff date on Monday, I shall assume that my summary is
accurate. :)=A0

> 1. Negotiation of all st= ream features is optional. If the receiving
> entity considers negotiation of a given feature to be mandatory, it wi= ll
> advertise only that feature; and if the initiating entity does not
> negotiate that feature (e.g., by attempting to send stanzas before it = is
> allowed to do so), then the receiving entity will return an error to t= he
> initiating entity. Therefore, we have no need to specify over the wire=
> if a given stream feature must be negotiated at any given stage of the=
> stream negotiation process.

For TLS, we felt the need in RFC 3920 to define a method whereby the<= br> server could flag negotiation of TLS as mandatory to negotiate ("MTN&q= uot;)
in order to enforce local service policies. The discussions since then
have always assumed that we need a way to flag (some) features as MTN.
<= /blockquote>

And that's the assumption being questio= ned here :-)
=A0
The thread here has attempted to define MTN in a standardized way,
rather than assuming that MTN will be explicit in the definition of some features (TLS) but not others (everything else), implicit in the
definition of a given feature (SASL is always mandatory) or implicit via the inclusion of a given feature and only that feature at a particular
point in the stream negotiation process (what Mr. Cridland appears to be suggesting).

I think the following are very different:

(a) As the first stream features, inform the initating entity that TLS
is MTN.

=A0 <stream:features>
=A0 =A0 <starttls xmlns=3D'urn:ietf:params:xml:ns:xmpp-tls'>=
=A0 =A0 =A0 <required/>
=A0 =A0 </starttls>
=A0 </stream:features>

(b) At some point in the stream negotiation process, inform the
initiating entity that SASL is MTN.

=A0 <stream:features>
=A0 =A0 <mechanisms xmlns=3D'urn:ietf:params:xml:ns:xmpp-sasl'&= gt;
=A0 =A0 =A0 <mechanism>DIGEST-MD5</mechanism>
=A0 =A0 =A0 <mechanism>PLAIN</mechanism>
=A0 =A0 </mechanisms>
=A0 </stream:features>

(c) As the last stream features (after resource binding), inform the
initiating entity that stream compression is voluntary to negotiate ("= VTN").

=A0 <stream:features>
=A0 =A0 <compression xmlns=3D'http://jabber.org/features/c= ompress'>
=A0 =A0 =A0 <method>zlib</method>
=A0 =A0 =A0 <method>lzw</method>
=A0 =A0 </compression>
=A0 </stream:features>

If we say that a feature is MTN if it is the only feature advertised at
a particular point in the stream negotiation process, then (c) would
mean compression is MTN after resource binding. Because that is
non-sensical, I must conclude that all features are VTN unless
explicitly defined otherwise (i.e., we cannot deduce that a feature is
MTN simply by the absence of other features in that particular instance
of stream features advertisement).

As f= ar as I can see, the need here isn't for individual features to be MTN = or VTN, but a way for the server to indicate its readiness for normal XMPP = IM. From what I have seen, the algorithm clients (and servers) tend to use = is to negotiate all negotiable features they are able and configured to neg= otiate, and as the last step they bind a resource. At this point they assum= e the server is ready for XMPP IM. This seems reasonable enough, and I have= not seen clients actually testing individual features for being MTN or VTN= .

While what I just said applies to C2S, the process used= by other initiating entities isn't any different. The initiating entit= ies are only interested in the stream's readiness for their purposes, n= ot about individual features being MTN or VTN (or non-negotiable; not all f= eatures are negotiable).
=A0
The initiating entity can implicitly know that a given feature is MTN
(we "just know" that SASL is MTN because you must authenticate) o= r the
receiving entity can explicitly inform the intitiating entity (we don't=
"just know" and therefore need a way for the receiving entity to = inform
the initiating entity that Feature X is MTN).

I don't like these things to be implicit (the stream feature approach i= s
open-ended and we don't know what features people might define in the future), which is why I think that we need some kind of method for
explicitly signalling that a feature is MTN. We have two options:

1. Place the burden on each stream feature. Therefore we might end up
with things like this:

=A0 <stream:features>
=A0 =A0 <starttls xmlns=3D'urn:ietf:params:xml:ns:xmpp-tls'>=
=A0 =A0 =A0 <required/>
=A0 =A0 </starttls>
=A0 </stream:features>

vs.

=A0 <stream:features>
=A0 =A0 <mechanisms xmlns=3D'urn:ietf:params:xml:ns:xmpp-sasl'<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mandatory=3D'true'>
=A0 =A0 =A0 <mechanism>DIGEST-MD5</mechanism>
=A0 =A0 =A0 <mechanism>PLAIN</mechanism>
=A0 =A0 </mechanisms>
=A0 </stream:features>

vs.

=A0 <stream:features>
=A0 =A0 <compression xmlns=3D'http://jabber.org/features/c= ompress'>
=A0 =A0 =A0 <method>zlib</method>
=A0 =A0 =A0 <method>lzw</method>
=A0 =A0 =A0 <you-gotta-negotiate-this/>
=A0 =A0 </compression>
=A0 </stream:features>

2. Define a generalized data structure that can be re-used by all stream features.

=A0 <stream:features>
=A0 =A0 <starttls xmlns=3D'urn:ietf:params:xml:ns:xmpp-tls'>=
=A0 =A0 =A0 <stream:usage mandatory=3D'true'/>
=A0 =A0 </starttls>
=A0 </stream:features>

=A0 <stream:features>
=A0 =A0 <mechanisms xmlns=3D'urn:ietf:params:xml:ns:xmpp-sasl'&= gt;
=A0 =A0 =A0 <mechanism>DIGEST-MD5</mechanism>
=A0 =A0 =A0 <mechanism>PLAIN</mechanism>
=A0 =A0 =A0 <stream:usage mandatory=3D'true'/>
=A0 =A0 </mechanisms>
=A0 </stream:features>

=A0 <stream:features>
=A0 =A0 <compression xmlns=3D'http://jabber.org/features/c= ompress'>
=A0 =A0 =A0 <method>zlib</method>
=A0 =A0 =A0 <method>lzw</method>
=A0 =A0 =A0 <stream:usage mandatory=3D'true'/>
=A0 =A0 </compression>
=A0 </stream:features>

Option #2 is a lot cleaner, it can be re-used by any stream feature that people might define in the future, it simplifies processing by the
initiating entity, and it reduces the chance of nasty surprises (e.g.,
disconnections because the initiating entity assumed that Feature X was
VTN while the receiving entity assumed that Feature X was MTN).

If the MTN vs. VTN distinction was really necessary, I= would agree.
=A0
> 2. Whether a stream restart is mandatory is defined by the stream
> feeature and does not need to be specified on the wire. All that 3920b= is
> needs to say is that the definition of a stream feature must specify > whether stream restarts are necessary after negotiation of that featur= e.

Here again, I think it would be helpful to be explicit about whether = a
restart is needed or not. In general, stream restarts apply to any
protocol in which the entities need to discard information received in
an insecure manner before the given feature was negotiated. Right now
that is true only for TLS and for SASL-with-security-layers. It is
probably unlikely that we will define new technologies that also force
stream restarts (since they would essentially be replacements for TLS or for SASL-with-security-layers), so I am not as worked up about defining
an explicit signalling method here. However, it seems to me that if we
are defining an explicit signalling method for MTN vs. VTN then we might as well define one for restarts while we're at it. I will update -03 along these lines and flag this as an item for discussion on the list
and in Hiroshima.

If the MTN vs. V= TN distinction was really necessary, this would be still be arguable.
=
=A0
There is one more issue that is still unclear in -02: how to handle
stream feature advertisements that contain multiple features. The
following combinations are possible:

(a) 1+ features, all of which are MTN.
(b) 1+ features, 1 or 1+ (but not all) of which are MTN.
(c) 1+ features, none of which are MTN.

In the case of (a) I think the initiating just picks one MTN feature to
negotiate based on local preferences.

In the case of (b) I think the initiating entity can negotiate one of
the VTN features (say, in-band registration instead of SASL) or one of
the MTN features, but it needs to negotiate something.

So, basically as far as the initiating entity is concerned,= there is no distinction between (a) and (b). The initiating entity will do= the same thing for either case: Pick any one feature it likes.
=A0
In the case of (c) I think the initiating entity can negotiate any of
the features or none of the features.

A= nd only (c) really matters. That is, all that matters is a signal that nego= tiation is complete. Currently, for C2S this is assumed to be the case afte= r resource binding, and for S2S this is assumed to be the case after auth (= SASL or dialback). Your goal seems to be making this explicit. Wouldn't= a simple stream feature making this explicit be enough? What would an MTN/= VTN flag on each feature buy us that a <negitiation-complete/> (or mo= re appropriately <xmpp-im/>, etc) feature will not?
=A0
I tried to capture this in the state chart, but I've made a few edits t= o
the chart since -02 and those will show up in -03.

Peter

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

--
Waqas Hussain
<= br>
--000e0cd48830b22b2f04768f9580-- From justin@affinix.com Thu Oct 22 18:07:40 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C732A3A68D7 for ; Thu, 22 Oct 2009 18:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JajquXpBv5VQ for ; Thu, 22 Oct 2009 18:07:39 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id E32783A635F for ; Thu, 22 Oct 2009 18:07:39 -0700 (PDT) Received: from localhost (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPSA id 2B95F8C063 for ; Thu, 22 Oct 2009 18:07:50 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Thu, 22 Oct 2009 18:07:52 -0700 User-Agent: KMail/1.9.10 References: <4ADF1E7B.20804@stpeter.im> <4AE0BBA8.1030601@stpeter.im> In-Reply-To: <4AE0BBA8.1030601@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910221807.52525.justin@affinix.com> Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 01:07:40 -0000 On Thursday 22 October 2009 13:08:08 Peter Saint-Andre wrote: > On 10/21/09 8:45 AM, Peter Saint-Andre wrote: > > 1. Negotiation of all stream features is optional. If the receiving > > entity considers negotiation of a given feature to be mandatory, it will > > advertise only that feature; and if the initiating entity does not > > negotiate that feature (e.g., by attempting to send stanzas before it is > > allowed to do so), then the receiving entity will return an error to the > > initiating entity. Therefore, we have no need to specify over the wire > > if a given stream feature must be negotiated at any given stage of the > > stream negotiation process. > > For TLS, we felt the need in RFC 3920 to define a method whereby the > server could flag negotiation of TLS as mandatory to negotiate ("MTN") > in order to enforce local service policies. The discussions since then > have always assumed that we need a way to flag (some) features as MTN. > The thread here has attempted to define MTN in a standardized way, > rather than assuming that MTN will be explicit in the definition of some > features (TLS) but not others (everything else), implicit in the > definition of a given feature (SASL is always mandatory) or implicit via > the inclusion of a given feature and only that feature at a particular > point in the stream negotiation process (what Mr. Cridland appears to be > suggesting). I feel similar to Dave on this matter, that the suggested changes to stream features amount to overengineering. If we want a future feature to be required, it should be enough to state in the spec that it is required. A client isn't going to say to an end-user: "Sorry, the server requires the 'ugly-long-namespace' feature in order to log in." Either the client will display a generic error ("Sorry, the server requires a feature not supported by this client"), or it will be spec-aware and display ("Sorry, the server requires the Foo feature, which is not supported by this client" (except that it sort of is, if the client can write such a message..)). Sure, a generic way to flag any feature as required would allow a client to easily display the generic "feature not supported" error message. Otherwise, as mentioned, the client would have to send a stanza and receive an error in order to determine that there was an unnegotiated required feature. I'm partial to using an error as a solution, since it requires the least amount of change to XMPP. I'd suggest a stream error here and not (or not merely) a stanza error. Finally, I want to say that very few features should be required at all anyway. TLS, SASL, and resource binding are the only ones that matter. Everything else should almost always be optional. Is anyone really planning to require compression or stream management for example, to the point where the client can't even use the service without them? I don't think you will, but in the chance that you do, you can bounce the client off with a stream error. -Justin From stpeter@stpeter.im Thu Oct 22 20:32:05 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17AFF3A67A2 for ; Thu, 22 Oct 2009 20:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[AWL=5.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJZtcY7p-4og for ; Thu, 22 Oct 2009 20:32:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 013D73A677E for ; Thu, 22 Oct 2009 20:32:04 -0700 (PDT) Received: from squire.local (dsl-251-21.dynamic-dsl.frii.net [216.17.251.21]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BF18040341; Thu, 22 Oct 2009 21:32:13 -0600 (MDT) Message-ID: <4AE123BC.5040509@stpeter.im> Date: Thu, 22 Oct 2009 21:32:12 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Justin Karneges References: <4ADF1E7B.20804@stpeter.im> <4AE0BBA8.1030601@stpeter.im> <200910221807.52525.justin@affinix.com> In-Reply-To: <200910221807.52525.justin@affinix.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 03:32:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/22/09 7:07 PM, Justin Karneges wrote: > On Thursday 22 October 2009 13:08:08 Peter Saint-Andre wrote: >> On 10/21/09 8:45 AM, Peter Saint-Andre wrote: >>> 1. Negotiation of all stream features is optional. If the receiving >>> entity considers negotiation of a given feature to be mandatory, it will >>> advertise only that feature; and if the initiating entity does not >>> negotiate that feature (e.g., by attempting to send stanzas before it is >>> allowed to do so), then the receiving entity will return an error to the >>> initiating entity. Therefore, we have no need to specify over the wire >>> if a given stream feature must be negotiated at any given stage of the >>> stream negotiation process. >> For TLS, we felt the need in RFC 3920 to define a method whereby the >> server could flag negotiation of TLS as mandatory to negotiate ("MTN") >> in order to enforce local service policies. The discussions since then >> have always assumed that we need a way to flag (some) features as MTN. >> The thread here has attempted to define MTN in a standardized way, >> rather than assuming that MTN will be explicit in the definition of some >> features (TLS) but not others (everything else), implicit in the >> definition of a given feature (SASL is always mandatory) or implicit via >> the inclusion of a given feature and only that feature at a particular >> point in the stream negotiation process (what Mr. Cridland appears to be >> suggesting). > > I feel similar to Dave on this matter, that the suggested changes to stream > features amount to overengineering. > > If we want a future feature to be required, it should be enough to state in > the spec that it is required. Sometimes TLS is required and sometimes it isn't -- that depends on the local service policy. The case of SASL or dialback for s2s is interesting, but we have never clearly defined that. It might be that the receiving entity would require either SASL or dialback in some situations, in which case SASL is not required in all circumstances (again, it depends on the context). > A client isn't going to say to an > end-user: "Sorry, the server requires the 'ugly-long-namespace' feature in > order to log in." Either the client will display a generic error ("Sorry, > the server requires a feature not supported by this client"), or it will be > spec-aware and display ("Sorry, the server requires the Foo feature, which is > not supported by this client" (except that it sort of is, if the client can > write such a message..)). > > Sure, a generic way to flag any feature as required would allow a client to > easily display the generic "feature not supported" error message. Otherwise, > as mentioned, the client would have to send a stanza and receive an error in > order to determine that there was an unnegotiated required feature. I'm > partial to using an error as a solution, since it requires the least amount > of change to XMPP. I'd suggest a stream error here and not (or not merely) a > stanza error. Of course it must be a stream error -- the initiating entity hasn't necessarily sent any stanzas (e.g., if it hasn't completed SASL negotiation yet). > Finally, I want to say that very few features should be required at all > anyway. TLS, SASL, and resource binding are the only ones that matter. TLS or something very much like it. SASL or something very much like it. Resource binding or something very much like it. But, in case we should ever design or re-use things very much like TLS, SASL, and resource binding then most likely those features would be defined as required, too. > Everything else should almost always be optional. Is anyone really planning > to require compression or stream management for example, to the point where > the client can't even use the service without them? I don't think you will, > but in the chance that you do, you can bounce the client off with a stream > error. Sure, if people find that acceptable. My concern is not so much with endless extensibility and future-proofing, but with features that right now can be either mandatory or voluntary depending on local service policies. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrhI7wACgkQNL8k5A2w/vxHJwCgt3WrcHlJw55f3RhIkZKxpTMV PIQAoIXNkEgdrfJ+K0mpwPMa47tyB0OR =YdhH -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Oct 22 20:56:30 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2D433A67AE for ; Thu, 22 Oct 2009 20:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[AWL=4.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upMCFEkEEZcg for ; Thu, 22 Oct 2009 20:56:29 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 06F1E3A67A2 for ; Thu, 22 Oct 2009 20:56:29 -0700 (PDT) Received: from squire.local (dsl-251-21.dynamic-dsl.frii.net [216.17.251.21]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 67C5340341; Thu, 22 Oct 2009 21:56:38 -0600 (MDT) Message-ID: <4AE12975.7010303@stpeter.im> Date: Thu, 22 Oct 2009 21:56:37 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Waqas Hussain References: <14858.1256025498.543955@puncture> <4ADF1E7B.20804@stpeter.im> <4AE0BBA8.1030601@stpeter.im> <7fc4fa880910221749m62463793w4f0ea806e06bb954@mail.gmail.com> In-Reply-To: <7fc4fa880910221749m62463793w4f0ea806e06bb954@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 03:56:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/22/09 6:49 PM, Waqas Hussain wrote: > On Fri, Oct 23, 2009 at 1:08 AM, Peter Saint-Andre > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My apologies for the long post... > > On 10/21/09 8:45 AM, Peter Saint-Andre wrote: > > On 10/20/09 1:58 AM, Dave Cridland wrote: > > > > > > > > Dave, let me see if I can summarize your perspective... > > Because I am working to publish revised versions of 3920bis and 3921bis > by the I-D cutoff date on Monday, I shall assume that my summary is > accurate. :) > > > > 1. Negotiation of all stream features is optional. If the receiving > > entity considers negotiation of a given feature to be mandatory, > it will > > advertise only that feature; and if the initiating entity does not > > negotiate that feature (e.g., by attempting to send stanzas before > it is > > allowed to do so), then the receiving entity will return an error > to the > > initiating entity. Therefore, we have no need to specify over the wire > > if a given stream feature must be negotiated at any given stage of the > > stream negotiation process. > > For TLS, we felt the need in RFC 3920 to define a method whereby the > server could flag negotiation of TLS as mandatory to negotiate ("MTN") > in order to enforce local service policies. The discussions since then > have always assumed that we need a way to flag (some) features as MTN. > > > And that's the assumption being questioned here :-) Do you question the assumption that local service policies might necessitate flagging TLS as mandatory to negotiate? If so, then either you are saying that a service can never force TLS on c2s or s2s connections or that TLS must always be mandatory to negotiate. > The thread here has attempted to define MTN in a standardized way, > rather than assuming that MTN will be explicit in the definition of some > features (TLS) but not others (everything else), implicit in the > definition of a given feature (SASL is always mandatory) or implicit via > the inclusion of a given feature and only that feature at a particular > point in the stream negotiation process (what Mr. Cridland appears to be > suggesting). > > I think the following are very different: > > (a) As the first stream features, inform the initating entity that TLS > is MTN. > > > > > > > > (b) At some point in the stream negotiation process, inform the > initiating entity that SASL is MTN. > > > > DIGEST-MD5 > PLAIN > > > > (c) As the last stream features (after resource binding), inform the > initiating entity that stream compression is voluntary to negotiate > ("VTN"). > > > > zlib > lzw > > > > If we say that a feature is MTN if it is the only feature advertised at > a particular point in the stream negotiation process, then (c) would > mean compression is MTN after resource binding. Because that is > non-sensical, I must conclude that all features are VTN unless > explicitly defined otherwise (i.e., we cannot deduce that a feature is > MTN simply by the absence of other features in that particular instance > of stream features advertisement). > > > As far as I can see, the need here isn't for individual features to be > MTN or VTN, but a way for the server to indicate its readiness for > normal XMPP IM. From what I have seen, the algorithm clients (and > servers) tend to use is to negotiate all negotiable features they are > able and configured to negotiate, and as the last step they bind a > resource. At this point they assume the server is ready for XMPP IM. > This seems reasonable enough, and I have not seen clients actually > testing individual features for being MTN or VTN. That seems reasonable. However, let's say my client is configured to prefer TLS connections, whereas the server I connect to is configured to mandate TLS. I try to connect but the server offers only TLS. Does my client negotiate TLS or not? I suppose it does ("use TLS if available" is the usual configuration option in mail and IM clients). > While what I just said applies to C2S, the process used by other > initiating entities isn't any different. The initiating entities are > only interested in the stream's readiness for their purposes, not about > individual features being MTN or VTN (or non-negotiable; not all > features are negotiable). Correct. > The initiating entity can implicitly know that a given feature is MTN > (we "just know" that SASL is MTN because you must authenticate) or the > receiving entity can explicitly inform the intitiating entity (we don't > "just know" and therefore need a way for the receiving entity to inform > the initiating entity that Feature X is MTN). > > I don't like these things to be implicit (the stream feature approach is > open-ended and we don't know what features people might define in the > future), which is why I think that we need some kind of method for > explicitly signalling that a feature is MTN. We have two options: > > 1. Place the burden on each stream feature. Therefore we might end up > with things like this: > > > > > > > > vs. > > > mandatory='true'> > DIGEST-MD5 > PLAIN > > > > vs. > > > > zlib > lzw > > > > > 2. Define a generalized data structure that can be re-used by all stream > features. > > > > > > > > > > DIGEST-MD5 > PLAIN > > > > > > > zlib > lzw > > > > > Option #2 is a lot cleaner, it can be re-used by any stream feature that > people might define in the future, it simplifies processing by the > initiating entity, and it reduces the chance of nasty surprises (e.g., > disconnections because the initiating entity assumed that Feature X was > VTN while the receiving entity assumed that Feature X was MTN). > > > If the MTN vs. VTN distinction was really necessary, I would agree. It is necessary for TLS and (depending on your interpretation of TLS-plus-dialback vs. SASL) it might be necessary for SASL. Other than that, I tend to agree. > > 2. Whether a stream restart is mandatory is defined by the stream > > feeature and does not need to be specified on the wire. All that > 3920bis > > needs to say is that the definition of a stream feature must specify > > whether stream restarts are necessary after negotiation of that > feature. > > Here again, I think it would be helpful to be explicit about whether a > restart is needed or not. In general, stream restarts apply to any > protocol in which the entities need to discard information received in > an insecure manner before the given feature was negotiated. Right now > that is true only for TLS and for SASL-with-security-layers. It is > probably unlikely that we will define new technologies that also force > stream restarts (since they would essentially be replacements for TLS or > for SASL-with-security-layers), so I am not as worked up about defining > an explicit signalling method here. However, it seems to me that if we > are defining an explicit signalling method for MTN vs. VTN then we might > as well define one for restarts while we're at it. I will update -03 > along these lines and flag this as an item for discussion on the list > and in Hiroshima. > > > If the MTN vs. VTN distinction was really necessary, this would be still > be arguable. I suppose you would argue that stream restarts are mandatory after TLS and SASL but are not needed for any other features. In today's world that is valid. We can simply say that stream features need to define whether they require a stream restart after being negotiated (and right now that would apply only to TLS and SASL). > There is one more issue that is still unclear in -02: how to handle > stream feature advertisements that contain multiple features. The > following combinations are possible: > > (a) 1+ features, all of which are MTN. > (b) 1+ features, 1 or 1+ (but not all) of which are MTN. > (c) 1+ features, none of which are MTN. > > In the case of (a) I think the initiating just picks one MTN feature to > negotiate based on local preferences. > > In the case of (b) I think the initiating entity can negotiate one of > the VTN features (say, in-band registration instead of SASL) or one of > the MTN features, but it needs to negotiate something. > > > So, basically as far as the initiating entity is concerned, there is no > distinction between (a) and (b). The initiating entity will do the same > thing for either case: Pick any one feature it likes. Quite possibly, yes. I need to think about that a bit more. > In the case of (c) I think the initiating entity can negotiate any of > the features or none of the features. > > > And only (c) really matters. That is, all that matters is a signal that > negotiation is complete. Currently, for C2S this is assumed to be the > case after resource binding, and for S2S this is assumed to be the case > after auth (SASL or dialback). Your goal seems to be making this > explicit. Not only this. I don't like all this implicit stuff in the protocol because it seems to open up potential problems. But perhaps I'm worried about things that aren't deserving of worry. > Wouldn't a simple stream feature making this explicit be > enough? What would an MTN/VTN flag on each feature buy us that a > (or more appropriately , etc) feature > will not? If we had status messages instead of only error messages, we could handle this with some kind of stream status. It doesn't quite seem like a stream feature: But, as you say, perhaps it's enough to say that for c2s you are cleared for sending stanzas after resource binding, and for s2s after SASL or dialback. That seems to have worked just fine for the last 10 years, so there's probably no reason to fix it. :) > I tried to capture this in the state chart, but I've made a few edits to > the chart since -02 and those will show up in -03. Interestingly, the state chart pretty much stays the same (perhaps except for the distinction between (a), (b), and (c) above) no matter whether we define things explicitly or implicitly... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrhKXUACgkQNL8k5A2w/vym7wCffVxw5w9pZfLvXrIyyfZeYoS5 08sAoO3AzfXtNx+qNM8Hc2pRjrk7x36c =Rs8i -----END PGP SIGNATURE----- From justin@affinix.com Thu Oct 22 21:56:44 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9DB3A6774 for ; Thu, 22 Oct 2009 21:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqlll8Jgpty8 for ; Thu, 22 Oct 2009 21:56:43 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id EA75E3A6898 for ; Thu, 22 Oct 2009 21:56:43 -0700 (PDT) Received: from localhost (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id DE0C3D4895 for ; Thu, 22 Oct 2009 21:56:51 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Thu, 22 Oct 2009 21:56:54 -0700 User-Agent: KMail/1.9.10 References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> In-Reply-To: <4AE123BC.5040509@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910222156.54456.justin@affinix.com> Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 04:56:44 -0000 On Thursday 22 October 2009 20:32:12 you wrote: > On 10/22/09 7:07 PM, Justin Karneges wrote: > > I feel similar to Dave on this matter, that the suggested changes to > > stream features amount to overengineering. > > > > If we want a future feature to be required, it should be enough to state > > in the spec that it is required. > > Sometimes TLS is required and sometimes it isn't -- that depends on the > local service policy. Yes, I should have been more clear: the spec would define the feature's requiredness, whether that means always required or only sometimes. For example, TLS is required if is present as a child element, and resource binding is always required. I understand the rationale for wanting to make a generic concept, because it might be handy if we find ourselves defining such a flag for lots of features. I guess my question is if anyone is really wanting to make all those features flaggable. Right now, only TLS has this flag, and the rest of the features are defined as either required or optional. > The case of SASL or dialback for s2s is interesting, but we have never > clearly defined that. It might be that the receiving entity would > require either SASL or dialback in some situations, in which case SASL > is not required in all circumstances (again, it depends on the context). Something to define, then. :) > > A client isn't going to say to an > > end-user: "Sorry, the server requires the 'ugly-long-namespace' feature > > in order to log in." Either the client will display a generic error > > ("Sorry, the server requires a feature not supported by this client"), or > > it will be spec-aware and display ("Sorry, the server requires the Foo > > feature, which is not supported by this client" (except that it sort of > > is, if the client can write such a message..)). > > > > Sure, a generic way to flag any feature as required would allow a client > > to easily display the generic "feature not supported" error message. > > Otherwise, as mentioned, the client would have to send a stanza and > > receive an error in order to determine that there was an unnegotiated > > required feature. I'm partial to using an error as a solution, since it > > requires the least amount of change to XMPP. I'd suggest a stream error > > here and not (or not merely) a stanza error. > > Of course it must be a stream error -- the initiating entity hasn't > necessarily sent any stanzas (e.g., if it hasn't completed SASL > negotiation yet). How else would the receiving entity know to send an error? If I negotiate TLS and then just sit there and not negotiate SASL, the server shouldn't boot me (well except due to a timeout, but that's not the same thing as skipping over a required feature). The server pretty much has to wait for me to make a wrong move. Maybe you mean if I try to negotiate a stream feature out of sequence? That would be one non-stanza way of me doing something wrong. > > Finally, I want to say that very few features should be required at all > > anyway. TLS, SASL, and resource binding are the only ones that matter. > > TLS or something very much like it. SASL or something very much like it. > Resource binding or something very much like it. But, in case we should > ever design or re-use things very much like TLS, SASL, and resource > binding then most likely those features would be defined as required, too. If an alternative feature to SASL existed (let's call it NGAuth), I think the best approach would be for the new feature to define not only itself but its relationship to SASL. For example, if both are offered, then the NGAuth is preferred, else SASL is used. I don't think flags would be enough to drive this. You'd need a way to specify that one deprecates the other or should be tried before the other, and that only one of them should be used. In the case of ensuring only one of these features is used, and not both, of course the server could be smart about how the features are offered. For example, on the first pass it could offer both NGAuth and SASL, but if NGAuth is used and succeeds then the next set of stream features would not contain either of them. That said, the client shouldn't be so dumb that it relies on the server for this logic. A client shouldn't auth twice, and it should know that it only needs one of NGAuth or SASL because it would say so in the spec. -Justin From stpeter@stpeter.im Fri Oct 23 06:51:33 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7B83A6823 for ; Fri, 23 Oct 2009 06:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.21 X-Spam-Level: * X-Spam-Status: No, score=1.21 tagged_above=-999 required=5 tests=[AWL=3.809, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPepd6COrF+D for ; Fri, 23 Oct 2009 06:51:32 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B836B3A6821 for ; Fri, 23 Oct 2009 06:51:32 -0700 (PDT) Received: from squire.local (dsl-251-21.dynamic-dsl.frii.net [216.17.251.21]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 21B4140341; Fri, 23 Oct 2009 07:51:40 -0600 (MDT) Message-ID: <4AE1B4EA.4000408@stpeter.im> Date: Fri, 23 Oct 2009 07:51:38 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Justin Karneges References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> <200910222156.54456.justin@affinix.com> In-Reply-To: <200910222156.54456.justin@affinix.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:51:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/22/09 10:56 PM, Justin Karneges wrote: > On Thursday 22 October 2009 20:32:12 you wrote: >> On 10/22/09 7:07 PM, Justin Karneges wrote: >> >>> Sure, a generic way to flag any feature as required would allow a client >>> to easily display the generic "feature not supported" error message. >>> Otherwise, as mentioned, the client would have to send a stanza and >>> receive an error in order to determine that there was an unnegotiated >>> required feature. I'm partial to using an error as a solution, since it >>> requires the least amount of change to XMPP. I'd suggest a stream error >>> here and not (or not merely) a stanza error. >> Of course it must be a stream error -- the initiating entity hasn't >> necessarily sent any stanzas (e.g., if it hasn't completed SASL >> negotiation yet). > > How else would the receiving entity know to send an error? If I negotiate TLS > and then just sit there and not negotiate SASL, the server shouldn't boot me > (well except due to a timeout, but that's not the same thing as skipping over > a required feature). The server pretty much has to wait for me to make a > wrong move. Maybe you mean if I try to negotiate a stream feature out of > sequence? That would be one non-stanza way of me doing something wrong. A stanza is , , or . If the server is expecting SASL and I try to negotiate XEP-0198 support or dialback or whatever, I haven't sent a stanza so how can the server return a stanza error to me? >>> Finally, I want to say that very few features should be required at all >>> anyway. TLS, SASL, and resource binding are the only ones that matter. >> TLS or something very much like it. SASL or something very much like it. >> Resource binding or something very much like it. But, in case we should >> ever design or re-use things very much like TLS, SASL, and resource >> binding then most likely those features would be defined as required, too. > > If an alternative feature to SASL existed (let's call it NGAuth), I think the > best approach would be for the new feature to define not only itself but its > relationship to SASL. For example, if both are offered, then the NGAuth is > preferred, else SASL is used. > > I don't think flags would be enough to drive this. You'd need a > way to specify that one deprecates the other or should be tried before the > other, and that only one of them should be used. > > In the case of ensuring only one of these features is used, and not both, of > course the server could be smart about how the features are offered. For > example, on the first pass it could offer both NGAuth and SASL, but if NGAuth > is used and succeeds then the next set of stream features would not contain > either of them. That said, the client shouldn't be so dumb that it relies on > the server for this logic. A client shouldn't auth twice, and it should know > that it only needs one of NGAuth or SASL because it would say so in the spec. That seems reasonable. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrhtOoACgkQNL8k5A2w/vzlJACff/ZAjRy2faDzj1TEyfvDkAMY e6YAnj2zvUQPpBWboMQKDLQQg3XGhQDU =n9QH -----END PGP SIGNATURE----- From fippo@mail.symlynx.com Fri Oct 23 07:20:51 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F713A683E for ; Fri, 23 Oct 2009 07:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGq37k4zMyKL for ; Fri, 23 Oct 2009 07:20:51 -0700 (PDT) Received: from lectern.tobij.de (lectern.tobij.de [62.75.216.40]) by core3.amsl.com (Postfix) with ESMTP id C43593A6821 for ; Fri, 23 Oct 2009 07:20:50 -0700 (PDT) Received: from [192.168.178.24] (p548BEE27.dip.t-dialin.net [84.139.238.39]) (authenticated bits=0) by lectern.tobij.de (8.14.0/8.14.0) with ESMTP id n9NEKwuP028379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Oct 2009 16:20:59 +0200 Message-ID: <4AE1BBC4.3050606@mail.symlynx.com> Date: Fri, 23 Oct 2009 16:20:52 +0200 From: Philipp Hancke User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: xmpp@ietf.org References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> <200910222156.54456.justin@affinix.com> <4AE1B4EA.4000408@stpeter.im> In-Reply-To: <4AE1B4EA.4000408@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 14:20:52 -0000 Peter Saint-Andre wrote: [...] >> How else would the receiving entity know to send an error? If I negotiate TLS >> and then just sit there and not negotiate SASL, the server shouldn't boot me >> (well except due to a timeout, but that's not the same thing as skipping over >> a required feature). The server pretty much has to wait for me to make a >> wrong move. Maybe you mean if I try to negotiate a stream feature out of >> sequence? That would be one non-stanza way of me doing something wrong. > > A stanza is , , or . If the server is > expecting SASL and I try to negotiate XEP-0198 support or dialback or > whatever, I haven't sent a stanza so how can the server return a stanza > error to me? In the case of dialback that is rather easy now that we have dialback errors in xep 220. The additional error conditions might be: * policy-violation: dialback without tls when tls is required by policy * forbidden: dialback with tls but invalid certificate philipp From stpeter@stpeter.im Fri Oct 23 09:24:47 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321BD3A68A6 for ; Fri, 23 Oct 2009 09:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyCZxMZqbYyf for ; Fri, 23 Oct 2009 09:24:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5A3393A6891 for ; Fri, 23 Oct 2009 09:24:46 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D5BA340D09; Fri, 23 Oct 2009 10:24:56 -0600 (MDT) Message-ID: <4AE1D8D8.9030609@stpeter.im> Date: Fri, 23 Oct 2009 10:24:56 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dave Cridland References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> <200910222156.54456.justin@affinix.com> <4AE1B4EA.4000408@stpeter.im> <3832.1256306357.303069@puncture> In-Reply-To: <3832.1256306357.303069@puncture> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:24:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/09 7:59 AM, Dave Cridland wrote: > On Fri Oct 23 14:51:38 2009, Peter Saint-Andre wrote: >> A stanza is , , or . If the server is >> expecting SASL and I try to negotiate XEP-0198 support or dialback or >> whatever, I haven't sent a stanza so how can the server return a stanza >> error to me? > > Well, why would you try to negotiate XEP-0198 if you're not yet > authenticated? Because you're stupid. Well, you aren't, but your software is. :) > That's surely an error in all cases. It is. But it's not a stanza error. That's my only point here. > So you'd have to do SASL (or XEP-0078, or XEP-0220, both of which have > defined errors if they're attempted when in fact disabled) first. Indeed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrh2NcACgkQNL8k5A2w/vzktACfUPXAb9JiZf9cHbX32o0TOw/u qjsAmwRTGqbAFUsvOfHo1+7YYvZRKAr/ =bGV1 -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Oct 23 09:27:38 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271BC3A67FB for ; Fri, 23 Oct 2009 09:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIoIzSbTg4TJ for ; Fri, 23 Oct 2009 09:27:37 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 41AF03A67F4 for ; Fri, 23 Oct 2009 09:27:37 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D35C940341; Fri, 23 Oct 2009 10:27:47 -0600 (MDT) Message-ID: <4AE1D982.3020602@stpeter.im> Date: Fri, 23 Oct 2009 10:27:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Philipp Hancke References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> <200910222156.54456.justin@affinix.com> <4AE1B4EA.4000408@stpeter.im> <4AE1BBC4.3050606@mail.symlynx.com> In-Reply-To: <4AE1BBC4.3050606@mail.symlynx.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:27:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/09 8:20 AM, Philipp Hancke wrote: > Peter Saint-Andre wrote: > [...] >>> How else would the receiving entity know to send an error? If I >>> negotiate TLS and then just sit there and not negotiate SASL, the >>> server shouldn't boot me (well except due to a timeout, but that's >>> not the same thing as skipping over a required feature). The server >>> pretty much has to wait for me to make a wrong move. Maybe you mean >>> if I try to negotiate a stream feature out of sequence? That would >>> be one non-stanza way of me doing something wrong. >> >> A stanza is , , or . If the server is >> expecting SASL and I try to negotiate XEP-0198 support or dialback or >> whatever, I haven't sent a stanza so how can the server return a stanza >> error to me? > > In the case of dialback that is rather easy now that we have dialback > errors in xep 220. The additional error conditions might be: > * policy-violation: dialback without tls when tls is required by policy > * forbidden: dialback with tls but invalid certificate Correct. My only point in this context is that the server can't send you a stanza error out of the blue -- you need to send a stanza first. If you haven't sent any stanzas yet but you have sent other things over the stream before you are authenticated or cleared for sending stanzas, then the server needs to send you a stream error, not a stanza error. A very simple point. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrh2YIACgkQNL8k5A2w/vyLyACg5L9bhmnXDePi+3T7TCvFom7v JcEAn3qNcyhkUqtM0gSVZHqR7lOskxm1 =i8RN -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Oct 23 09:44:59 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B943A68AD for ; Fri, 23 Oct 2009 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCpxolDJona4 for ; Fri, 23 Oct 2009 09:44:54 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 110C73A6950 for ; Fri, 23 Oct 2009 09:44:51 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 43D9340D09; Fri, 23 Oct 2009 10:44:59 -0600 (MDT) Message-ID: <4AE1DD8A.7080903@stpeter.im> Date: Fri, 23 Oct 2009 10:44:58 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Matthew Wild References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> <200910222156.54456.justin@affinix.com> <4AE1B4EA.4000408@stpeter.im> <4db9cacb0910230739v24edf4a8xc63d266850beb7c@mail.gmail.com> In-Reply-To: <4db9cacb0910230739v24edf4a8xc63d266850beb7c@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:44:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/23/09 8:39 AM, Matthew Wild wrote: > I disengage from mailing lists for 24 hours and look where it gets me... :) I assume that you meant to reply-to-all, so I am replying to the list. > Apologies for the semi-top-post, but I'd like to summarise my response > to some earlier posts in the thread. Give a shout if I've missed the > gist of anything. > > I agree with Justin that any required/optional/restart flags are > over-engineering. The current process works just fine. To clarify, > this is how I see it working now: > > Loop > Server offers a set of features available to the client at the current time > Client chooses and negotiates its most preferred option > Until connection complete > > That is to say, if TLS is required... what we really mean is that "TLS > is required before you can authenticate" (or compress, or etc.). So we > would end up with TLS being the only feature published to the client > at the start. Basically you and others are saying that until the initiating entity is cleared to send stanzas, it needs to treat a feature as required if the server advertises only that feature. Correct? > The feature negotiation process is not a shopping list, but a tree. > The current system also allows use to advertise different SASL > mechanisms depending on whether the client has negotiated TLS or not > yet. Indeed. > Now the most interesting thing is how to detect when the server is > ready for you to send stanzas. Isn't this when it offers resource > binding to the client? Yes. > If we really need to define anything else, > could we perhaps re-use the IM session feature (which Dave has been > muttering about for a while). At the very first XMPP Summit and interop event in July 2006, we had strong consensus among all the server and client developers present that the im-session feature was a no-op. I haven't seen anything since then that would lead me to change my mind. > More follows... > > 2009/10/23 Peter Saint-Andre : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/22/09 10:56 PM, Justin Karneges wrote: >>> On Thursday 22 October 2009 20:32:12 you wrote: >>>> On 10/22/09 7:07 PM, Justin Karneges wrote: >>>> > >>> In the case of ensuring only one of these features is used, and not both, of >>> course the server could be smart about how the features are offered. For >>> example, on the first pass it could offer both NGAuth and SASL, but if NGAuth >>> is used and succeeds then the next set of stream features would not contain >>> either of them. That said, the client shouldn't be so dumb that it relies on >>> the server for this logic. A client shouldn't auth twice, and it should know >>> that it only needs one of NGAuth or SASL because it would say so in the spec. > > I disagree (even if we have abandoned the "smart servers, simple > clients" philosophy which used to be so prevalent round here). The > logic *is* defined by the server (and its admin), it's the server that > is choosing what is required and what is not, and so I'd consider it a > bug for the server to offer an authentication method when the stream > is already authenticated. > > The current system is nice and flexible, I don't see anything that > needs changing. What did I miss? Nothing. Version -03 of 3920bis will keep things as-is, just explain the state transitions more clearly. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrh3YoACgkQNL8k5A2w/vz6twCggkMSIjUMapiJW88cnaiEDNFB 2AsAoOcqLiJ1QM0ddCdQA/8ugm6w5oAr =baiF -----END PGP SIGNATURE----- From mwild1@gmail.com Fri Oct 23 10:03:43 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7A73A6894 for ; Fri, 23 Oct 2009 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YavQqbrjnJTO for ; Fri, 23 Oct 2009 10:03:42 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 3CCB93A6784 for ; Fri, 23 Oct 2009 10:03:41 -0700 (PDT) Received: by fxm18 with SMTP id 18so10504779fxm.37 for ; Fri, 23 Oct 2009 10:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=+XhKqw1JPpMe+VFmSTWB6DAC0/hKrSTQ1ky1ux1dbbg=; b=V0kMKkF8oMsayhGRSJ23HteBeZm5FaWZ837/bMo0z05yBL21iwsxj6fTST0OwcDuNg WssnzmQBfGnl04eWMjfzuLWiJD/mKLNCsfxdLFxV4ejNj8iY9mpiNqMJldAUjdlfq5aE 734b9qMxv0fiD3zHEXee6R0/GTYEAQGIFuEL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Lto9yFxFA+cwP6ryL7jUEGcpWh3bhyDHhUyDWIELjd/JawlnqKmx2nWJyqJhAyEv3F Kk1R5f7RmrE80E2L4rpicykNURp6QGmUS75i6wOKimqBrqYApOFTq2GRiL3f3JZPKkjR NdfQe4SiVsdSNqvxyEQEmAdVi8G2qvDueuRIM= MIME-Version: 1.0 Received: by 10.204.148.78 with SMTP id o14mr11278779bkv.83.1256317429206; Fri, 23 Oct 2009 10:03:49 -0700 (PDT) In-Reply-To: <4AE1DD8A.7080903@stpeter.im> References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> <200910222156.54456.justin@affinix.com> <4AE1B4EA.4000408@stpeter.im> <4db9cacb0910230739v24edf4a8xc63d266850beb7c@mail.gmail.com> <4AE1DD8A.7080903@stpeter.im> From: Matthew Wild Date: Fri, 23 Oct 2009 18:03:29 +0100 Message-ID: <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 17:03:43 -0000 2009/10/23 Peter Saint-Andre : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/23/09 8:39 AM, Matthew Wild wrote: >> I disengage from mailing lists for 24 hours and look where it gets me...= :) > > I assume that you meant to reply-to-all, so I am replying to the list. > Indeed yes, too long away from mailing lists, like I said :) >> That is to say, if TLS is required... what we really mean is that "TLS >> is required before you can authenticate" (or compress, or etc.). So we >> would end up with TLS being the only feature published to the client >> at the start. > > Basically you and others are saying that until the initiating entity is > =A0cleared to send stanzas, it needs to treat a feature as required if th= e > server advertises only that feature. Correct? > It needs to treat the list of features offered by the server as "choose one of these to continue", so yes if TLS is mandatory before any other negotiation can continue, it would appear on its own. I'm trying to differentiate from the earlier "mark a feature as MTN by offering it alone", because if there are multiple MTN features in which negotiation order does not matter, they could all be offered together. >> If we really need to define anything else, >> could we perhaps re-use the IM session feature (which Dave has been >> muttering about for a while). > > At the very first XMPP Summit and interop event in July 2006, we had > strong consensus among all the server and client developers present that > the im-session feature was a no-op. I haven't seen anything since then > that would lead me to change my mind. > Agreed. I'll leave it for Dave if he does want to resume this in the context of this thread. >> The current system is nice and flexible, I don't see anything that >> needs changing. What did I miss? > > Nothing. Version -03 of 3920bis will keep things as-is, just explain the > state transitions more clearly. > All good to me, thanks, Matthew From root@core3.amsl.com Fri Oct 23 11:45:01 2009 Return-Path: X-Original-To: xmpp@ietf.org Delivered-To: xmpp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 84B333A6849; Fri, 23 Oct 2009 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023184501.84B333A6849@core3.amsl.com> Date: Fri, 23 Oct 2009 11:45:01 -0700 (PDT) Cc: xmpp@ietf.org Subject: [xmpp] I-D Action:draft-ietf-xmpp-3920bis-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Core Author(s) : P. Saint-Andre Filename : draft-ietf-xmpp-3920bis-03.txt Pages : 178 Date : 2009-10-23 This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3920bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xmpp-3920bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23114246.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 23 11:45:01 2009 Return-Path: X-Original-To: xmpp@ietf.org Delivered-To: xmpp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8C0C53A6856; Fri, 23 Oct 2009 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023184501.8C0C53A6856@core3.amsl.com> Date: Fri, 23 Oct 2009 11:45:01 -0700 (PDT) Cc: xmpp@ietf.org Subject: [xmpp] I-D Action:draft-ietf-xmpp-3921bis-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence Author(s) : P. Saint-Andre Filename : draft-ietf-xmpp-3921bis-02.txt Pages : 105 Date : 2009-10-23 This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with RFC 2779. This document obsoletes RFC 3921. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3921bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xmpp-3921bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23114248.I-D@ietf.org> --NextPart-- From stpeter@stpeter.im Fri Oct 23 11:45:05 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A4828C139 for ; Fri, 23 Oct 2009 11:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xnfFdKmZAf8 for ; Fri, 23 Oct 2009 11:45:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8629F28C112 for ; Fri, 23 Oct 2009 11:45:04 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 13C2A40341 for ; Fri, 23 Oct 2009 12:45:14 -0600 (MDT) Message-ID: <4AE1F9B9.4090209@stpeter.im> Date: Fri, 23 Oct 2009 12:45:13 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: XMPP X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] updated bis drafts X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:45:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, I just submitted updated versions of 3920bis (03) and 3921bis (02). To the best of my knowledge these incorporate all feedback received to date. Thanks to the many people who have commented on these specs. All errors are my responsibility. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrh+bkACgkQNL8k5A2w/vyaGQCffphZB+7xODKekvW+q46tROMZ NNMAnj62XwlooNngliVXk9fD0QnA2EDB =uv+V -----END PGP SIGNATURE----- From justin@affinix.com Fri Oct 23 11:58:00 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5278D3A6986 for ; Fri, 23 Oct 2009 11:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7KivTzaF63w for ; Fri, 23 Oct 2009 11:57:59 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 943783A697A for ; Fri, 23 Oct 2009 11:57:59 -0700 (PDT) Received: from localhost (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id B1E80BCB2F for ; Fri, 23 Oct 2009 11:58:01 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Fri, 23 Oct 2009 11:58:04 -0700 User-Agent: KMail/1.9.10 References: <4AE1DD8A.7080903@stpeter.im> <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> In-Reply-To: <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200910231158.04863.justin@affinix.com> Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:58:00 -0000 On Friday 23 October 2009 10:03:29 Matthew Wild wrote: > 2009/10/23 Peter Saint-Andre : > > Basically you and others are saying that until the initiating entity is > > =A0cleared to send stanzas, it needs to treat a feature as required if = the > > server advertises only that feature. Correct? > > It needs to treat the list of features offered by the server as > "choose one of these to continue", so yes if TLS is mandatory before > any other negotiation can continue, it would appear on its own. I'm > trying to differentiate from the earlier "mark a feature as MTN by > offering it alone", because if there are multiple MTN features in > which negotiation order does not matter, they could all be offered > together. I'm not opposed to deferring features from appearing as a way of making oth= er=20 features required. But first: does anyone know if not offering SASL on the= =20 first pass could cause a problem with existing code? Or if it may violate= =20 RFC 3920? This approach could also be used to force the client to enable features in = a=20 certain sequence, though for most features there is already a defined order= =20 that the server can't muck with. For example, a server can't make a client= =20 negotiate TLS after SASL, or make it negotiate resource binding without=20 having done SASL. These would be considered protocol errors by the client. =2DJustin From mwild1@gmail.com Fri Oct 23 12:22:59 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5B73A67FA for ; Fri, 23 Oct 2009 12:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+RDbiB1Yw0O for ; Fri, 23 Oct 2009 12:22:59 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A560B3A677D for ; Fri, 23 Oct 2009 12:22:58 -0700 (PDT) Received: by fxm18 with SMTP id 18so10611960fxm.37 for ; Fri, 23 Oct 2009 12:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rnIP9xcAxJVrg1gz+PTJO//GwaXz8T36MsAIdpaDacE=; b=bOSo7AcYV1veaYywWskmEtS4CHWLSQewyO+l8JGFy/b7t0FBIrOd/VTV0AACx/bHiJ UXGcerxWSxgy2j3Z6J8gxaqX6ZC2aVcb0OD0Vs8Z6FHDL1ub/LOIhZR4NU3o/UfFtCMH 2tGKKteOVOYawg4UQgGoq7LiFcXjJ0eDRWOew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=WiTtQJTGmd+zj4nY4MWYsQBNbPd591koJEHRGpoxZvpAUekpa5yMcTh9KtjEtE+LZL XGfy0P97e4iYVChfhtiPj/p01KNco5/czUFv3JxYnhljetWH9r91IxsSJckIw8mcDLdc +1TfPo1V8DaMpy9YlEHU6N7JCpR6P77k9Vl6I= MIME-Version: 1.0 Received: by 10.204.23.77 with SMTP id q13mr2986934bkb.14.1256325785176; Fri, 23 Oct 2009 12:23:05 -0700 (PDT) In-Reply-To: <200910231158.04863.justin@affinix.com> References: <4AE1DD8A.7080903@stpeter.im> <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> <200910231158.04863.justin@affinix.com> From: Matthew Wild Date: Fri, 23 Oct 2009 20:22:45 +0100 Message-ID: <4db9cacb0910231222r2d5a7c4bjac8030ad89b26105@mail.gmail.com> To: Justin Karneges Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:22:59 -0000 2009/10/23 Justin Karneges : > On Friday 23 October 2009 10:03:29 Matthew Wild wrote: >> 2009/10/23 Peter Saint-Andre : >> > Basically you and others are saying that until the initiating entity i= s >> > =A0cleared to send stanzas, it needs to treat a feature as required if= the >> > server advertises only that feature. Correct? >> >> It needs to treat the list of features offered by the server as >> "choose one of these to continue", so yes if TLS is mandatory before >> any other negotiation can continue, it would appear on its own. I'm >> trying to differentiate from the earlier "mark a feature as MTN by >> offering it alone", because if there are multiple MTN features in >> which negotiation order does not matter, they could all be offered >> together. > > I'm not opposed to deferring features from appearing as a way of making o= ther > features required. =A0But first: does anyone know if not offering SASL on= the > first pass could cause a problem with existing code? =A0Or if it may viol= ate > RFC 3920? > It's what Prosody does and it's working great as far as I can see. If it really does violate the RFC (I don't see why) then I propose we fix the RFC :) > This approach could also be used to force the client to enable features i= n a > certain sequence, though for most features there is already a defined ord= er > that the server can't muck with. =A0For example, a server can't make a cl= ient > negotiate TLS after SASL, or make it negotiate resource binding without > having done SASL. =A0These would be considered protocol errors by the cli= ent. > The RFC could define a recommended order, TLS <=3D SASL, SASL < binding, et= c.. Matthew. From justin@affinix.com Fri Oct 23 12:29:59 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEB33A679F for ; Fri, 23 Oct 2009 12:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKOsyADUx1Ve for ; Fri, 23 Oct 2009 12:29:59 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 3E7213A677D for ; Fri, 23 Oct 2009 12:29:59 -0700 (PDT) Received: from localhost (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 5BBAC4147C for ; Fri, 23 Oct 2009 12:30:09 -0700 (PDT) From: Justin Karneges To: xmpp@ietf.org Date: Fri, 23 Oct 2009 12:30:12 -0700 User-Agent: KMail/1.9.10 References: <200910231158.04863.justin@affinix.com> <4db9cacb0910231222r2d5a7c4bjac8030ad89b26105@mail.gmail.com> In-Reply-To: <4db9cacb0910231222r2d5a7c4bjac8030ad89b26105@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200910231230.12837.justin@affinix.com> Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:30:00 -0000 On Friday 23 October 2009 12:22:45 you wrote: > 2009/10/23 Justin Karneges : > > This approach could also be used to force the client to enable features > > in a certain sequence, though for most features there is already a > > defined order that the server can't muck with. =A0For example, a server > > can't make a client negotiate TLS after SASL, or make it negotiate > > resource binding without having done SASL. =A0These would be considered > > protocol errors by the client. > > The RFC could define a recommended order, TLS <=3D SASL, SASL < binding, > etc.. It already does. However it's a bit more than "recommended". It's the=20 required sequence. If a server offers binding before SASL, for example, it= 's=20 not like the client is going to use binding and say "woo-hoo I'm in!". =20 Instead the client going to disconnect and present an error to the user,=20 since the server is speaking nonsense. =2DJustin From fippo@mail.symlynx.com Fri Oct 23 12:31:00 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7563A679F for ; Fri, 23 Oct 2009 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djkmiXroXTeQ for ; Fri, 23 Oct 2009 12:30:59 -0700 (PDT) Received: from lectern.tobij.de (lectern.tobij.de [62.75.216.40]) by core3.amsl.com (Postfix) with ESMTP id 51F4E3A67FA for ; Fri, 23 Oct 2009 12:30:59 -0700 (PDT) Received: from [192.168.178.24] (p548BEE27.dip.t-dialin.net [84.139.238.39]) (authenticated bits=0) by lectern.tobij.de (8.14.0/8.14.0) with ESMTP id n9NJV6V9003691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Oct 2009 21:31:08 +0200 Message-ID: <4AE20473.2060902@mail.symlynx.com> Date: Fri, 23 Oct 2009 21:30:59 +0200 From: Philipp Hancke User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: xmpp@ietf.org References: <4AE1DD8A.7080903@stpeter.im> <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> <200910231158.04863.justin@affinix.com> <4db9cacb0910231222r2d5a7c4bjac8030ad89b26105@mail.gmail.com> In-Reply-To: <4db9cacb0910231222r2d5a7c4bjac8030ad89b26105@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:31:00 -0000 Matthew Wild wrote: > 2009/10/23 Justin Karneges : >> On Friday 23 October 2009 10:03:29 Matthew Wild wrote: >>> 2009/10/23 Peter Saint-Andre : >>>> Basically you and others are saying that until the initiating entity is >>>> cleared to send stanzas, it needs to treat a feature as required if the >>>> server advertises only that feature. Correct? >>> It needs to treat the list of features offered by the server as >>> "choose one of these to continue", so yes if TLS is mandatory before >>> any other negotiation can continue, it would appear on its own. I'm >>> trying to differentiate from the earlier "mark a feature as MTN by >>> offering it alone", because if there are multiple MTN features in >>> which negotiation order does not matter, they could all be offered >>> together. >> I'm not opposed to deferring features from appearing as a way of making other >> features required. But first: does anyone know if not offering SASL on the >> first pass could cause a problem with existing code? Or if it may violate >> RFC 3920? >> > > It's what Prosody does and it's working great as far as I can see. If > it really does violate the RFC (I don't see why) then I propose we fix > the RFC :) +1 I would not expect problems either, because the TLS+SASL PLAIN path exists. >> This approach could also be used to force the client to enable features in a >> certain sequence, though for most features there is already a defined order >> that the server can't muck with. For example, a server can't make a client >> negotiate TLS after SASL, or make it negotiate resource binding without >> having done SASL. These would be considered protocol errors by the client. >> > > The RFC could define a recommended order, TLS <= SASL, SASL < binding, etc.. xep 0170 does that already :-p From mwild1@gmail.com Fri Oct 23 12:34:30 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474103A679F for ; Fri, 23 Oct 2009 12:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zSP6mx-hAW6 for ; Fri, 23 Oct 2009 12:34:29 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 480C43A677D for ; Fri, 23 Oct 2009 12:34:29 -0700 (PDT) Received: by bwz23 with SMTP id 23so1159678bwz.29 for ; Fri, 23 Oct 2009 12:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ylcijo0W/PWCWpwwGyb+i2I5QCjFG3LRCvIArRNIxwo=; b=o2GSfJqvtUS+9LOqp6GUZlMPUM/Fxic53wa1FDmnVlj4rHa5aDBVi1YAvfoc5bGK5E jIwAng7tj9jZc5C+KmkrWSjES7dEhUhaO335EzktMOQcH9iydHCShH9IJICZ2+8Be8IE vU59ZiEGrx1FqBoqs4JakA+fYr64XD7R60pSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=jsp5Kg9vhXOzG7gEWIPLf8IwP9s2MMQu23mxcp4oXPW7KJpoiLRNrZ8vIJaMS+njjI 7e8TKkl4zJ8j9HOqBaNXVm1xDhok47RrswROeu8Z1pWyaWYf8rdnd59iu15zX2oPcPVM CLvN0tnJKCUBTje7Z2RgfUK9ogJGdj8ItFupY= MIME-Version: 1.0 Received: by 10.204.32.76 with SMTP id b12mr1388792bkd.165.1256326475114; Fri, 23 Oct 2009 12:34:35 -0700 (PDT) In-Reply-To: <200910231230.12837.justin@affinix.com> References: <200910231158.04863.justin@affinix.com> <4db9cacb0910231222r2d5a7c4bjac8030ad89b26105@mail.gmail.com> <200910231230.12837.justin@affinix.com> From: Matthew Wild Date: Fri, 23 Oct 2009 20:34:15 +0100 Message-ID: <4db9cacb0910231234u51327fecqf6702a57de7254e0@mail.gmail.com> To: Justin Karneges Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: xmpp@ietf.org Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:34:30 -0000 2009/10/23 Justin Karneges : > On Friday 23 October 2009 12:22:45 you wrote: >> 2009/10/23 Justin Karneges : >> > This approach could also be used to force the client to enable feature= s >> > in a certain sequence, though for most features there is already a >> > defined order that the server can't muck with. =A0For example, a serve= r >> > can't make a client negotiate TLS after SASL, or make it negotiate >> > resource binding without having done SASL. =A0These would be considere= d >> > protocol errors by the client. >> >> The RFC could define a recommended order, TLS <=3D SASL, SASL < binding, >> etc.. > > It already does. =A0However it's a bit more than "recommended". =A0It's t= he > required sequence. =A0If a server offers binding before SASL, for example= , it's > not like the client is going to use binding and say "woo-hoo I'm in!". If the server offers binding then I see no reason it couldn't do exactly th= at :) > Instead the client going to disconnect and present an error to the user, > since the server is speaking nonsense. > If the server speaks nonsense, all hope is lost. It's an implementation issue, and not a protocol issue. Matthew From dave@cridland.net Mon Oct 26 00:31:38 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477363A68DE for ; Mon, 26 Oct 2009 00:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We9zOw5c-p3x for ; Mon, 26 Oct 2009 00:31:37 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 29FAF3A68B4 for ; Mon, 26 Oct 2009 00:31:37 -0700 (PDT) Received: from puncture ([217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id ; Fri, 23 Oct 2009 14:59:22 +0100 References: <200910221807.52525.justin@affinix.com> <4AE123BC.5040509@stpeter.im> <200910222156.54456.justin@affinix.com> <4AE1B4EA.4000408@stpeter.im> In-Reply-To: <4AE1B4EA.4000408@stpeter.im> MIME-Version: 1.0 Message-Id: <3832.1256306357.303069@puncture> Date: Fri, 23 Oct 2009 14:59:17 +0100 From: Dave Cridland To: Peter Saint-Andre , XMPP Working Group , Justin Karneges Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 07:31:38 -0000 On Fri Oct 23 14:51:38 2009, Peter Saint-Andre wrote: > A stanza is , , or . If the server is > expecting SASL and I try to negotiate XEP-0198 support or dialback > or > whatever, I haven't sent a stanza so how can the server return a > stanza > error to me? Well, why would you try to negotiate XEP-0198 if you're not yet authenticated? That's surely an error in all cases. So you'd have to do SASL (or XEP-0078, or XEP-0220, both of which have defined errors if they're attempted when in fact disabled) first. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From turners@ieca.com Tue Oct 27 08:47:26 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9EB3A6858 for ; Tue, 27 Oct 2009 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW08LDtOv9K4 for ; Tue, 27 Oct 2009 08:47:25 -0700 (PDT) Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by core3.amsl.com (Postfix) with SMTP id 4D1663A67E7 for ; Tue, 27 Oct 2009 08:47:25 -0700 (PDT) Received: (qmail 5346 invoked from network); 27 Oct 2009 15:47:32 -0000 Received: from pool-96-231-128-183.washdc.east.verizon.net (turners@96.231.128.183 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 27 Oct 2009 08:47:32 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: B_kVH3oVM1m292oj5QnKRk9_UWJiQVQdJdcB5qdhuQsqrwaLErZFZwuifj8INGcAO0wdqHW5.PDVoS9YghSyLiX_Km0YmHyAmWGXzTgxnPuXzWtGEQktSZq63ubo3yYJdmCkRUDB40MnIaB1.VODKbTqc9jphkRI8_tOBUQc91WkpCN9PdLt2.wgWL75RihPHioW2W8KbEtbdJlwXEg7UHUhLjIrbfkYIVcTyLmMfqZNJPl5DJkxZ0A_cokjkIDHvCkZ_MykD1fHQpFaFcp5FEOtUxwihBPEUqY8DMiHC7RIzhTjeKL.DIOCIFxyb5sFcT2d0O_B6y19cjkh21H7 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE71610.3030401@ieca.com> Date: Tue, 27 Oct 2009 11:47:28 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: XMPP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [xmpp] Call for XMPP Agenda Items X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:47:26 -0000 All, The XMPP WG will meet Wednesday November 11th between 1-3. We're obviously going to discuss the 3 WG IDs, but we'd also like to know if there are others that have something they'd like to present. If you do, then please let me know the title of presentation and an approximate length. spt From waqas20@gmail.com Tue Oct 27 11:32:12 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD893A6994 for ; Tue, 27 Oct 2009 11:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyOvgFbCTSOp for ; Tue, 27 Oct 2009 11:32:11 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 534BE3A698F for ; Tue, 27 Oct 2009 11:32:11 -0700 (PDT) Received: by ywh13 with SMTP id 13so414853ywh.29 for ; Tue, 27 Oct 2009 11:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=8VZeKIxT+PokPi8rWxnJJkm2tizklzO63Y83eHZC8eY=; b=d9i44lnCPHi0h9KDBBVILNbX4O3wM5g/qPYKKiqgLIp6HoNrVOMhYslJIXTzAKWwYP IzigZoEfsPmrdE7cGBhmvsiq9nLHXWYpLgGWGCWHI1jmiUSMySrRYZB+ebT6MpiRRLvL /HqJ7dg7zLYecH+T2FjWJomwLkbjsslUAW9Ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Lt//GFixTBAbTawmzRrYMhorOcn26P3XtNKFNKRR08yMxbXEscDDTE4VBPPSwtDYrF kL4W7IkAFKvxVRh15DroK+J7kFvPxSF0vbkf3qqvZ7Xu7c7yY20NgBuSP6eGwrVtVZIH PODQwBJicRbyE4V20xQfHrROrWNRNMip2wAH8= MIME-Version: 1.0 Received: by 10.150.234.5 with SMTP id g5mr13532168ybh.339.1256668343105; Tue, 27 Oct 2009 11:32:23 -0700 (PDT) In-Reply-To: <4AE1F9B9.4090209@stpeter.im> References: <4AE1F9B9.4090209@stpeter.im> From: Waqas Hussain Date: Tue, 27 Oct 2009 23:32:03 +0500 Message-ID: <7fc4fa880910271132p4616cc93g899c330253e50149@mail.gmail.com> To: XMPP Content-Type: multipart/alternative; boundary=000e0cd5cc8c30f9560476eee6f0 Subject: Re: [xmpp] updated bis drafts X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:32:12 -0000 --000e0cd5cc8c30f9560476eee6f0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 23, 2009 at 11:45 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FYI, I just submitted updated versions of 3920bis (03) and 3921bis (02). > To the best of my knowledge these incorporate all feedback received to > date. > > Thanks to the many people who have commented on these specs. All errors > are my responsibility. :) > > Peter > I noticed an issue: 3921bis-02 changes the server handling of inbound presence subscription stanzas. According to bis-01, the server SHOULD NOT deliver inbound presence subscription stanzas (except "subscribe" stanzas) to the user. According to bis-02 the server MUST deliver them if they modify the roster. The bis-02 appendix A however was not updated to reflect this change, and still suggests 'SHOULD NOT'. -- Waqas Hussain --000e0cd5cc8c30f9560476eee6f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 23, 2009 at 11:45 PM, Peter Saint-An= dre <stpeter@stp= eter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI, I just submitted updated versions of 3920bis (03) and 3921bis (02). To the best of my knowledge these incorporate all feedback received to
date.

Thanks to the many people who have commented on these specs. All errors
are my responsibility. :)

Peter

I noticed an issue:
3921bis-02 changes the server handling of inbound presence subs= cription stanzas. According to bis-01, the server SHOULD NOT deliver inboun= d presence subscription stanzas (except "subscribe" stanzas) to t= he user. According to bis-02 the server MUST deliver them if they modify th= e roster. The bis-02 appendix A however was not updated to reflect this cha= nge, and still suggests 'SHOULD NOT'.

--
Waqas Hussain

--000e0cd5cc8c30f9560476eee6f0-- From stpeter@stpeter.im Tue Oct 27 12:58:35 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BA83A6A30 for ; Tue, 27 Oct 2009 12:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DizwQRjlOWS0 for ; Tue, 27 Oct 2009 12:58:31 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 983093A69C0 for ; Tue, 27 Oct 2009 12:58:31 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 64C714008F; Tue, 27 Oct 2009 13:58:45 -0600 (MDT) Message-ID: <4AE750F4.8070507@stpeter.im> Date: Tue, 27 Oct 2009 13:58:44 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Waqas Hussain References: <4AE1F9B9.4090209@stpeter.im> <7fc4fa880910271132p4616cc93g899c330253e50149@mail.gmail.com> In-Reply-To: <7fc4fa880910271132p4616cc93g899c330253e50149@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] updated bis drafts X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 19:58:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 12:32 PM, Waqas Hussain wrote: > On Fri, Oct 23, 2009 at 11:45 PM, Peter Saint-Andre > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FYI, I just submitted updated versions of 3920bis (03) and 3921bis (02). > To the best of my knowledge these incorporate all feedback received to > date. > > Thanks to the many people who have commented on these specs. All errors > are my responsibility. :) > > Peter > > > I noticed an issue: > > 3921bis-02 changes the server handling of inbound presence subscription > stanzas. According to bis-01, the server SHOULD NOT deliver inbound > presence subscription stanzas (except "subscribe" stanzas) to the user. > According to bis-02 the server MUST deliver them if they modify the > roster. The bis-02 appendix A however was not updated to reflect this > change, and still suggests 'SHOULD NOT'. Sorry about that, I neglected to update the appendix. As to whether the server needs to deliver inbound presence subscription stanzas (subscribed, unsubscribe, unsubscribed), my reasoning is that if the server does not deliver them to the client then the client has no way to tell whether the roster push was generated by another resource or triggered by the contact. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrnUPQACgkQNL8k5A2w/vxQ5gCgx7BNAQawU4Tg0LGwxJsAfWM4 JvAAoIK4PtY8eX37rLsSCoSxy5THoD4E =Bpf+ -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Oct 27 14:09:18 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A8928C112 for ; Tue, 27 Oct 2009 14:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRiWSumZC9Ta for ; Tue, 27 Oct 2009 14:09:18 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1A65C28C108 for ; Tue, 27 Oct 2009 14:09:16 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42C0E4008F; Tue, 27 Oct 2009 15:09:30 -0600 (MDT) Message-ID: <4AE76188.9010107@stpeter.im> Date: Tue, 27 Oct 2009 15:09:28 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sean Turner References: <4AE71610.3030401@ieca.com> In-Reply-To: <4AE71610.3030401@ieca.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Call for XMPP Agenda Items X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:09:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 9:47 AM, Sean Turner wrote: > All, > > The XMPP WG will meet Wednesday November 11th between 1-3. We're > obviously going to discuss the 3 WG IDs, but we'd also like to know if > there are others that have something they'd like to present. If you do, > then please let me know the title of presentation and an approximate > length. I assume that Joe Hildebrand can talk about DNA: http://tools.ietf.org/html/draft-hildebrand-dna-00 I can talk about recent updates to 3920bis and 3921bis. That might take 30 minutes for both. I will post to the list in the next week about specific "bis" topics that we might want to cover at IETF 76. To me, the major remaining issue is internationalized addresses. I have reviewed the full suite of IDNAbis documents with an eye toward usage in XMPP, but that is only one aspect of i18n since we also need to deal with JID localparts and "resourceparts". Should we continue using Stringprep or take the IDNAbis approach of whitelisting certain characters? (That probably makes more sense for IDNA than for localparts or resourceparts.) Should we use IDNA2003 or IDNA2008? And so on. We might also want to compare our work here to the email i18n work: http://tools.ietf.org/wg/eai/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrnYYgACgkQNL8k5A2w/vy6RQCgy5j9Q3HWbO9OdcPwDJBb24xb iYoAoIFxeIjJEDnPGnQKiEksmDCrN5ul =4BYx -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Tue Oct 27 16:06:09 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382553A682F for ; Tue, 27 Oct 2009 16:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EAUEsRSx7oR for ; Tue, 27 Oct 2009 16:06:08 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 413A23A6904 for ; Tue, 27 Oct 2009 16:06:08 -0700 (PDT) Received: from [172.16.2.109] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 27 Oct 2009 23:06:21 +0000 Message-ID: <4AE77CE1.90905@isode.com> Date: Tue, 27 Oct 2009 23:06:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <4AE71610.3030401@ieca.com> <4AE76188.9010107@stpeter.im> In-Reply-To: <4AE76188.9010107@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Call for XMPP Agenda Items X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:06:09 -0000 Peter Saint-Andre wrote: >On 10/27/09 9:47 AM, Sean Turner wrote: > > >>All, >> >>The XMPP WG will meet Wednesday November 11th between 1-3. We're >>obviously going to discuss the 3 WG IDs, but we'd also like to know if >>there are others that have something they'd like to present. If you do, >>then please let me know the title of presentation and an approximate >>length. >> >> >I assume that Joe Hildebrand can talk about DNA: > >http://tools.ietf.org/html/draft-hildebrand-dna-00 > > +1. >I can talk about recent updates to 3920bis and 3921bis. That might take >30 minutes for both. I will post to the list in the next week about >specific "bis" topics that we might want to cover at IETF 76. > >To me, the major remaining issue is internationalized addresses. I have >reviewed the full suite of IDNAbis documents with an eye toward usage in >XMPP, but that is only one aspect of i18n since we also need to deal >with JID localparts and "resourceparts". Should we continue using >Stringprep or take the IDNAbis approach of whitelisting certain >characters? > I think the answer to this question would depend on StringPrep BOF outcome. I was hoping to have it in Hiroshima, but it is delayed till the following IETF. >(That probably makes more sense for IDNA than for localparts >or resourceparts.) Should we use IDNA2003 or IDNA2008? And so on. We >might also want to compare our work here to the email i18n work: > >http://tools.ietf.org/wg/eai/ > From balfanz@google.com Wed Oct 28 11:12:29 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1933428C1D7 for ; Wed, 28 Oct 2009 11:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwZF9cd6pkZt for ; Wed, 28 Oct 2009 11:12:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id A9E8328C179 for ; Wed, 28 Oct 2009 11:12:27 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id n9SICduT020048 for ; Wed, 28 Oct 2009 18:12:40 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1256753560; bh=fhHxg9EHSNayhnWUi2nCAFV40Xg=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=oQT+76NpGMM6ZQ3TIhgPCAYrQKA2pvvQaaCqJt2GnBOYfoe4fm3huGg0lgHJCXls4 NdIIBJj56c/CKG4Ppa/+Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=vr+e8u9Hz+Qq703bBn/C6UCtPui9Mhw1Dfg7hS8bJBZnkdeMfdGdzVH0MDrlTXXST iO1+/YEo6aA0mBug2N8Yg== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by wpaz21.hot.corp.google.com with ESMTP id n9SICaDU030989 for ; Wed, 28 Oct 2009 11:12:36 -0700 Received: by pwj3 with SMTP id 3so944762pwj.28 for ; Wed, 28 Oct 2009 11:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.85.16 with SMTP id n16mr7252483wal.123.1256753555992; Wed, 28 Oct 2009 11:12:35 -0700 (PDT) Date: Wed, 28 Oct 2009 11:12:35 -0700 Message-ID: <60c552b80910281112u76bd45f1h572c73df0c43914a@mail.gmail.com> From: Dirk Balfanz To: xmpp@ietf.org Content-Type: multipart/alternative; boundary=0016e64ca2a6467524047702bdd3 X-System-Of-Record: true Subject: Re: [xmpp] draft-hildebrand-dna-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 18:12:29 -0000 --0016e64ca2a6467524047702bdd3 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I wanted to give some feedback on draft-hildebrand-dna-00. I just joined the mailing list, so I probably missed a bunch of the discussion regarding this topic. I'm new to XMPP, but have been helping out the Wave folks at Google with some crypto/PKI bits. My biggest question is why you're tangling up this spec with Attribute Certificates. I've never seen an RFC 3281-style AC in the wild, and hadn't heard of draft-ietf-pkix-3281update until I read this spec. Is 3281update real? Are there parsers out there that understand this stuff? It makes sense to stand on the shoulders, so to speak, of other specs if there is wide-spread adoption out there and code that can process these things, but you don't want to depend on specs that nobody is using - it just complicates things. Ok, now for more detailed, turn-by-turn comments: - it says "The issuer's certificate MUST NOT have a basicConstraints extension with the cA BOOLEAN set to TRUE." Why? - The holder field MUST be the baseCertificateID. This seems to mean that it points to a issuer/serial number in some other PKC. Hows does the validating entity get hold of that PKC? How did the issuer of the AC know what to put there? - http://www.ietf.org/id/draft-ietf-pkix-3281update-05.txt says "Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options [wherever the spec asks for a GeneralName]" Your spec says to use registeredId, so you seem to be advocating a non-3281update-compliant AC. - For encoding the AC, issuer cert and potential intermediate certs, you're depending on yet another RFC ( http://tools.ietf.org/html/draft-ietf-smime-3851bis-11) for encoding the cert chain, which seems like overkill. Why not just say that proof-type attribute-cert has sub-elements, like (base64 of AC) (base64 of issuer PKC) (base64 of intermediate PKC that issued issuer PKC) What do you guys think? You probably discussed all these things to death and i'm just late to the party... Dirk. --0016e64ca2a6467524047702bdd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys,=A0

I wanted to give some feedback on=A0draft-hildebrand-= dna-00. I just joined the mailing list, so I probably missed a bunch of the= discussion regarding this topic. I'm new to XMPP, but have been helpin= g out the Wave folks at Google with some crypto/PKI bits.

My biggest question is why you're tangling up this spec with A= ttribute Certificates. I've never seen an RFC 3281-style AC in the wild= , and hadn't heard of draft-ietf-pkix-3281update until I read th= is spec. Is 3281update real? Are there parsers out there that understand th= is stuff? It makes sense to stand on the shoulders, so to speak, of other s= pecs if there is wide-spread adoption out there and code that can process t= hese things, but you don't want to depend on specs that nobody is using= - it just complicates things.=A0

Ok, now for more detailed, turn-by-turn comments:
=

- it says "The issuer's certificate MUST NOT h= ave a basicConstraints=A0extension with the cA BOOLEAN set to TRUE." W= hy?

- The holder field MUST be the baseCertificateID. This = seems to mean that=A0it points to a issuer/serial number in some other PKC.= Hows does the=A0validating entity get hold of that PKC? How did the issuer= of the AC know what to put there?


- For encoding the AC, issuer cert and potential interm= ediate certs, you're depending on yet another RFC=A0(http://tools.ietf.org/html= /draft-ietf-smime-3851bis-11) for=A0encoding the cert chain, which seem= s like overkill. Why not just say that=A0proof-type attribute-cert has sub-= elements, like=A0
=A0=A0 <proof xmlns=3D'urn:ietf:params:xml:ns:dna'
=A0=A0 =A0 =A0 =A0 =A0from=3D'asserted.tld'
=A0=A0 =A0 = =A0 =A0 =A0type=3D'urn:ietf:params:dna:proof:attribute-cert'>
=A0=A0 =A0 <ac>
=A0=A0 =A0 =A0 (base64 of AC)
=A0=A0 =A0 </ac>
= =A0=A0 =A0 <pkc>
=A0=A0 =A0 =A0 (base64 of issuer PKC)
=A0=A0 =A0 </pkc>
=A0=A0 =A0 <pkc>
= =A0=A0 =A0 =A0 (base64 of intermediate PKC that issued issuer PKC)
=A0=A0 =A0 </pkc>
=A0=A0 </proof>

=
What do you guys think? You probably discussed all these things = to death and i'm just late to the party...

Dir= k.

--0016e64ca2a6467524047702bdd3-- From turners@ieca.com Wed Oct 28 12:11:41 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DAC73A689D for ; Wed, 28 Oct 2009 12:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isQb27kZFcOi for ; Wed, 28 Oct 2009 12:11:40 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id D518D3A67F3 for ; Wed, 28 Oct 2009 12:11:39 -0700 (PDT) Received: (qmail 22234 invoked from network); 28 Oct 2009 19:11:53 -0000 Received: from pool-71-191-8-106.washdc.east.verizon.net (turners@71.191.8.106 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 28 Oct 2009 12:11:52 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: IG5mIrIVM1kQo1pfRvGzy8Im9UF8NneMVJzC_YZe9NC8GDi7ctGSR4t1cf.eKqtaDZqzaKO4GTR76rB.j6L01HYIuUKuOidwWam0ZNeZvs_lDXBCEHAzc3ZyS0PcjwsCZKDMte3ZkFyA32Fhw5kZj4onFXFhXPhxeJbJSf9.dvT677E9hde4hb.TlZqz7WMy59oL2GmWZ0Szuf5YkmC9TnX5hz8Lmal6qrTyFctwcZBqCAipxS_APApSbwloykba5.PBmrpas9vBRBF8RanqkI8qOMjSvasWZ4cMWdB0RJ678BbPd2SwTeHc.XeljXYnULkqxuHjuoDhHS4MXuf1.u5NnNKKomM3wPUi.8mDgwTazsIWLl7PdhdCWiA5doQkE_6BWD8sVE8Szq8i4VK8 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE89778.2030806@ieca.com> Date: Wed, 28 Oct 2009 15:11:52 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dirk Balfanz References: <60c552b80910281112u76bd45f1h572c73df0c43914a@mail.gmail.com> In-Reply-To: <60c552b80910281112u76bd45f1h572c73df0c43914a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] draft-hildebrand-dna-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:11:41 -0000 Dirk Balfanz wrote: > Hi guys, > > I wanted to give some feedback on draft-hildebrand-dna-00. I just joined > the mailing list, so I probably missed a bunch of the discussion > regarding this topic. I'm new to XMPP, but have been helping out the > Wave folks at Google with some crypto/PKI bits. The discussion on the list has actually been pretty minimal. Technically, it's not even a working group document. > My biggest question is why you're tangling up this spec with Attribute > Certificates. I've never seen an RFC 3281-style AC in the wild, and > hadn't heard of draft-ietf-pkix-3281update until I read this spec. Is > 3281update real? Are there parsers out there that understand this stuff? > It makes sense to stand on the shoulders, so to speak, of other specs if > there is wide-spread adoption out there and code that can process these > things, but you don't want to depend on specs that nobody is using - it > just complicates things. I'm not sure what you mean by real? That ID fixes some errata and some minor bugs, so it's not a big update. It's in the RFC editor's queue. The document it was pinned on just got approved. It ought to be published soon. There are some code bits from bouncy castle, though I have to admit I haven't used them. I'm sure there are others. > Ok, now for more detailed, turn-by-turn comments: > > - it says "The issuer's certificate MUST NOT have a > basicConstraints extension with the cA BOOLEAN set to TRUE." Why? The statement is for compliance with RFC 3281/3281bis section 4.5. It says: "The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage extension in the PKC MUST NOT explicitly indicate that the AC issuer's public key cannot be used to validate a digital signature. In order to avoid confusion regarding serial numbers and revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a basicConstraints extension with the cA BOOLEAN set to TRUE." > - The holder field MUST be the baseCertificateID. This seems to mean > that it points to a issuer/serial number in some other PKC. Hows does > the validating entity get hold of that PKC? How did the issuer of the AC > know what to put there? The AC issuer will include their name in the issuer field (taken from their PKC's subject field) and the issuer's serial # (taken from their PKC's serial number field). Then the path for the AC would be included along with the AC (see Section 5.5). I proposed a "certs-only" message. It would include one attribute certificate and any public key certificates necessary to validate them. "certs-only" message have been around a while and are most recently documented in draft-ietf-smime-3851bis-11. > - http://www.ietf.org/id/draft-ietf-pkix-3281update-05.txt > says "Conforming implementations MUST NOT use the > x400Address, ediPartyName, or registeredID options [wherever the spec > asks for a GeneralName]" Your spec says to use registeredId, so you > seem to be advocating a non-3281update-compliant AC. That's my bad. We wouldn't want to be non-compliant. Joe suggested just using OIDs for id-xmpp and another one for id-xmpp-client/id-xmpp-server so I stuck it in there. If we can't use registerdID, then we need to pick another one or define an other-name. I guess I lean towards a new other-name. Thoughts? > - For encoding the AC, issuer cert and potential intermediate certs, > you're depending on yet another > RFC (http://tools.ietf.org/html/draft-ietf-smime-3851bis-11) > for encoding the cert chain, which seems like overkill. Why not just say > that proof-type attribute-cert has sub-elements, like > from='asserted.tld' > type='urn:ietf:params:dna:proof:attribute-cert'> > > (base64 of AC) > > > (base64 of issuer PKC) > > > (base64 of intermediate PKC that issued issuer PKC) > > We could do that, but it's not like what we picked is new. certs-only has been around since before '99 (see RFC 2633). I guess I don't really have a strong opinion one way or another. If we're not going to use PKCS#7 should we use from XMLDSig? > What do you guys think? You probably discussed all these things to death > and i'm just late to the party... Cheers, spt > Dirk. > > > ------------------------------------------------------------------------ > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From dave@cridland.net Thu Oct 29 02:16:16 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBE828C0ED for ; Thu, 29 Oct 2009 02:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw7qdKWxgJQP for ; Thu, 29 Oct 2009 02:16:15 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id B89933A6A4D for ; Thu, 29 Oct 2009 02:16:14 -0700 (PDT) Received: from puncture ([217.155.137.60]) by peirce.dave.cridland.net (submission) via TCP with ESMTPA id for ; Mon, 26 Oct 2009 11:37:05 +0000 References: <4AE1DD8A.7080903@stpeter.im> <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> <200910231158.04863.justin@affinix.com> In-Reply-To: <200910231158.04863.justin@affinix.com> MIME-Version: 1.0 Message-Id: <582.1256557019.053400@puncture> Date: Mon, 26 Oct 2009 11:36:59 +0000 From: Dave Cridland To: XMPP Working Group Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 09:16:16 -0000 On Fri Oct 23 18:58:04 2009, Justin Karneges wrote: > I'm not opposed to deferring features from appearing as a way of > making other > features required. But first: does anyone know if not offering > SASL on the > first pass could cause a problem with existing code? Or if it may > violate > RFC 3920? Just to pick up on this point, features can surely only be advertised if they're available. If they're not available - because the client cannot use them in this stream, since it needs to do the TLS dance and make a new stream - then they shouldn't be advertised. If you're reading RFC 3920 as saying that all possible features - even those not yes available - must be listed, then I'd think that would need clarification. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From mwild1@gmail.com Thu Oct 29 02:32:56 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3594A28C0F6 for ; Thu, 29 Oct 2009 02:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u+29y3HzWZz for ; Thu, 29 Oct 2009 02:32:55 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 291CB28C0F4 for ; Thu, 29 Oct 2009 02:32:54 -0700 (PDT) Received: by bwz23 with SMTP id 23so2059347bwz.29 for ; Thu, 29 Oct 2009 02:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=6adiYkYKf4kjCXCk8d/Wp0pYWQPXQR7BhfSeiebaM84=; b=kU7KXZEth9z9JUNASERlRRTw6wr1ril0M43PXoZVtOj+vUUamr3b8nFX7OWs+jMiWP 7LWMiiQC7T60/fIGW1e4LkB+Me6M6bpGZItjInAXSQJupYesEFyIEzTypEIUvvmQ/f1S pg1dofq2ERyhc6LWhJ3vdsFmEcZ65Tf8+4Aog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=wgl3+5hzSPf9hsuaA56Vt5feLpRM1oA9QwCWTVI+/UuQ5ywhR9zAFUYIVPmpvSz3OW AEeMX6OHQwp5STCuEln2Oc/yN93e7PX1aBUojvZiBcmfATcaW2vwQ6VmduMzZvkVKQl/ zzNVprVwjDYbbuXHiDdT8gL6n/CpjD85LAMmk= MIME-Version: 1.0 Received: by 10.204.151.210 with SMTP id d18mr6130341bkw.203.1256808771188; Thu, 29 Oct 2009 02:32:51 -0700 (PDT) In-Reply-To: <582.1256557019.053400@puncture> References: <4AE1DD8A.7080903@stpeter.im> <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> <200910231158.04863.justin@affinix.com> <582.1256557019.053400@puncture> From: Matthew Wild Date: Thu, 29 Oct 2009 09:32:31 +0000 Message-ID: <4db9cacb0910290232i5a5dc20dw4d57933e1504c9f1@mail.gmail.com> To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 09:32:56 -0000 2009/10/26 Dave Cridland : > On Fri Oct 23 18:58:04 2009, Justin Karneges wrote: >> >> I'm not opposed to deferring features from appearing as a way of making >> other >> features required. =A0But first: does anyone know if not offering SASL o= n >> the >> first pass could cause a problem with existing code? =A0Or if it may vio= late >> RFC 3920? > > Just to pick up on this point, features can surely only be advertised if > they're available. > > If they're not available - because the client cannot use them in this > stream, since it needs to do the TLS dance and make a new stream - then t= hey > shouldn't be advertised. > > If you're reading RFC 3920 as saying that all possible features - even th= ose > not yes available - must be listed, then I'd think that would need > clarification. > Agreed, this is how I interpret it also. Matthew From stpeter@stpeter.im Thu Oct 29 05:43:25 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45603A69CB for ; Thu, 29 Oct 2009 05:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.787 X-Spam-Level: X-Spam-Status: No, score=0.787 tagged_above=-999 required=5 tests=[AWL=3.386, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boH0jABdu681 for ; Thu, 29 Oct 2009 05:43:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 14CD83A696B for ; Thu, 29 Oct 2009 05:43:21 -0700 (PDT) Received: from squire.local (dsl-228-69.dynamic-dsl.frii.net [216.17.228.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 910DD4008F; Thu, 29 Oct 2009 06:43:33 -0600 (MDT) Message-ID: <4AE98DF1.2000606@stpeter.im> Date: Thu, 29 Oct 2009 06:43:29 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Matthew Wild References: <4AE1DD8A.7080903@stpeter.im> <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> <200910231158.04863.justin@affinix.com> <582.1256557019.053400@puncture> <4db9cacb0910290232i5a5dc20dw4d57933e1504c9f1@mail.gmail.com> In-Reply-To: <4db9cacb0910290232i5a5dc20dw4d57933e1504c9f1@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:43:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 3:32 AM, Matthew Wild wrote: > 2009/10/26 Dave Cridland : >> On Fri Oct 23 18:58:04 2009, Justin Karneges wrote: >>> I'm not opposed to deferring features from appearing as a way of making >>> other >>> features required. But first: does anyone know if not offering SASL on >>> the >>> first pass could cause a problem with existing code? Or if it may violate >>> RFC 3920? >> Just to pick up on this point, features can surely only be advertised if >> they're available. >> >> If they're not available - because the client cannot use them in this >> stream, since it needs to do the TLS dance and make a new stream - then they >> shouldn't be advertised. >> >> If you're reading RFC 3920 as saying that all possible features - even those >> not yes available - must be listed, then I'd think that would need >> clarification. >> > > Agreed, this is how I interpret it also. The text in 3920bis (and I think also 3920) talks about "available features", but if need be we can clarify this a bit further. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrpjfEACgkQNL8k5A2w/vzsQgCfeT+LWOCReRYJwT64+NvjwTmm Cl8AoN3R8KUsjRTXbXk2V8cUIiz4abdV =fviE -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Oct 29 06:31:21 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E932E3A697E for ; Thu, 29 Oct 2009 06:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.448 X-Spam-Level: X-Spam-Status: No, score=0.448 tagged_above=-999 required=5 tests=[AWL=3.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7C4AkEYB8LX for ; Thu, 29 Oct 2009 06:31:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B15DC28C0D6 for ; Thu, 29 Oct 2009 06:31:14 -0700 (PDT) Received: from squire.local (dsl-228-69.dynamic-dsl.frii.net [216.17.228.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F0504008F; Thu, 29 Oct 2009 07:31:26 -0600 (MDT) Message-ID: <4AE9992E.8040602@stpeter.im> Date: Thu, 29 Oct 2009 07:31:26 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Matthew Wild References: <4AE1DD8A.7080903@stpeter.im> <4db9cacb0910231003i7b68ab43ufd8354d0b6cd8e22@mail.gmail.com> <200910231158.04863.justin@affinix.com> <582.1256557019.053400@puncture> <4db9cacb0910290232i5a5dc20dw4d57933e1504c9f1@mail.gmail.com> <4AE98DF1.2000606@stpeter.im> In-Reply-To: <4AE98DF1.2000606@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] the stream negotiation process X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 13:31:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 6:43 AM, Peter Saint-Andre wrote: > On 10/29/09 3:32 AM, Matthew Wild wrote: >> 2009/10/26 Dave Cridland : >>> On Fri Oct 23 18:58:04 2009, Justin Karneges wrote: >>>> I'm not opposed to deferring features from appearing as a way of making >>>> other >>>> features required. But first: does anyone know if not offering SASL on >>>> the >>>> first pass could cause a problem with existing code? Or if it may violate >>>> RFC 3920? >>> Just to pick up on this point, features can surely only be advertised if >>> they're available. >>> >>> If they're not available - because the client cannot use them in this >>> stream, since it needs to do the TLS dance and make a new stream - then they >>> shouldn't be advertised. >>> >>> If you're reading RFC 3920 as saying that all possible features - even those >>> not yes available - must be listed, then I'd think that would need >>> clarification. >>> >> Agreed, this is how I interpret it also. > > The text in 3920bis (and I think also 3920) talks about "available > features", but if need be we can clarify this a bit further. I've added a few minor clarifications about this to my working copy. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrpmS4ACgkQNL8k5A2w/vwoigCguURY3fkFmw7dVv/n6rnRg6w2 o1IAn28cP6HMaoID+0VsizyidO7WpWwK =QRZw -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Oct 29 12:33:10 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD3F3A6A27 for ; Thu, 29 Oct 2009 12:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I76p3VUb6KhN for ; Thu, 29 Oct 2009 12:33:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7E3183A6A19 for ; Thu, 29 Oct 2009 12:33:09 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B71EE4008F; Thu, 29 Oct 2009 13:33:25 -0600 (MDT) Message-ID: <4AE9EE03.9080701@stpeter.im> Date: Thu, 29 Oct 2009 13:33:23 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov References: <4AE71610.3030401@ieca.com> <4AE76188.9010107@stpeter.im> <4AE77CE1.90905@isode.com> In-Reply-To: <4AE77CE1.90905@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Call for XMPP Agenda Items X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:33:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 5:06 PM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> To me, the major remaining issue is internationalized addresses. I have >> reviewed the full suite of IDNAbis documents with an eye toward usage in >> XMPP, but that is only one aspect of i18n since we also need to deal >> with JID localparts and "resourceparts". Should we continue using >> Stringprep or take the IDNAbis approach of whitelisting certain >> characters? >> > I think the answer to this question would depend on StringPrep BOF > outcome. I was hoping to have it in Hiroshima, but it is delayed till > the following IETF. Perhaps the XMPP WG can identify the issues that it thinks are important, for input to the Stringprep BoF. Given that XMPP is one of the main users of Stringprep, such an exercise might be useful for us and for people working on Stringprep / i18n. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrp7gMACgkQNL8k5A2w/vyokACghSbmtUlUBK4JGnJZTwgmKVm6 M7oAnA4mI9kOgW075R7FDEPOMfWjzN3G =OIhi -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Thu Oct 29 13:56:57 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23943A6A5E for ; Thu, 29 Oct 2009 13:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2spPhZe09pon for ; Thu, 29 Oct 2009 13:56:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 00DB23A69C1 for ; Thu, 29 Oct 2009 13:56:57 -0700 (PDT) Received: from [92.40.79.110] (92.40.79.110.sub.mbb.three.co.uk [92.40.79.110]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 29 Oct 2009 20:57:12 +0000 Message-ID: <4AEA019F.1000707@isode.com> Date: Thu, 29 Oct 2009 20:57:03 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <4AE71610.3030401@ieca.com> <4AE76188.9010107@stpeter.im> <4AE77CE1.90905@isode.com> <4AE9EE03.9080701@stpeter.im> In-Reply-To: <4AE9EE03.9080701@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Call for XMPP Agenda Items X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 20:56:57 -0000 Peter Saint-Andre wrote: >On 10/27/09 5:06 PM, Alexey Melnikov wrote: > > >>Peter Saint-Andre wrote: >> >> >>>To me, the major remaining issue is internationalized addresses. I have >>>reviewed the full suite of IDNAbis documents with an eye toward usage in >>>XMPP, but that is only one aspect of i18n since we also need to deal >>>with JID localparts and "resourceparts". Should we continue using >>>Stringprep or take the IDNAbis approach of whitelisting certain >>>characters? >>> >>> >>I think the answer to this question would depend on StringPrep BOF >>outcome. I was hoping to have it in Hiroshima, but it is delayed till >>the following IETF. >> >> >Perhaps the XMPP WG can identify the issues that it thinks are >important, for input to the Stringprep BoF. Given that XMPP is one of >the main users of Stringprep, such an exercise might be useful for us >and for people working on Stringprep / i18n. > > I think this is a good idea. As XMPP is conflicting with KRB-WG, I would like to suggest that we use SASL slot to discuss this. Opinions? From stpeter@stpeter.im Thu Oct 29 14:30:53 2009 Return-Path: X-Original-To: xmpp@core3.amsl.com Delivered-To: xmpp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A9D3A695D for ; Thu, 29 Oct 2009 14:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz2WMey3VaQT for ; Thu, 29 Oct 2009 14:30:52 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 571C43A6800 for ; Thu, 29 Oct 2009 14:30:52 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 795224008F; Thu, 29 Oct 2009 15:31:08 -0600 (MDT) Message-ID: <4AEA099B.5030707@stpeter.im> Date: Thu, 29 Oct 2009 15:31:07 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov References: <4AE71610.3030401@ieca.com> <4AE76188.9010107@stpeter.im> <4AE77CE1.90905@isode.com> <4AE9EE03.9080701@stpeter.im> <4AEA019F.1000707@isode.com> In-Reply-To: <4AEA019F.1000707@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Call for XMPP Agenda Items X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:30:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 2:57 PM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> On 10/27/09 5:06 PM, Alexey Melnikov wrote: >> >> >>> Peter Saint-Andre wrote: >>> >>>> To me, the major remaining issue is internationalized addresses. I have >>>> reviewed the full suite of IDNAbis documents with an eye toward >>>> usage in >>>> XMPP, but that is only one aspect of i18n since we also need to deal >>>> with JID localparts and "resourceparts". Should we continue using >>>> Stringprep or take the IDNAbis approach of whitelisting certain >>>> characters? >>>> >>> I think the answer to this question would depend on StringPrep BOF >>> outcome. I was hoping to have it in Hiroshima, but it is delayed till >>> the following IETF. >>> >> Perhaps the XMPP WG can identify the issues that it thinks are >> important, for input to the Stringprep BoF. Given that XMPP is one of >> the main users of Stringprep, such an exercise might be useful for us >> and for people working on Stringprep / i18n. >> >> > I think this is a good idea. > As XMPP is conflicting with KRB-WG, I would like to suggest that we use > SASL slot to discuss this. Opinions? That sounds like a productive use of the time. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrqCZsACgkQNL8k5A2w/vzHNQCcCQxvoCD0pwT3/4SkxB+LbYgI wB0AnRcv8T5TjJuS6etT84FER6bu0NZr =Fs/0 -----END PGP SIGNATURE-----