From Joe.Hildebrand@webex.com Fri Dec 4 14:55: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 9561F3A6947 for ; Fri, 4 Dec 2009 14:55:57 -0800 (PST) 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 5ijx6OzlCzzJ for ; Fri, 4 Dec 2009 14:55:56 -0800 (PST) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id ADBEE3A690D for ; Fri, 4 Dec 2009 14:55:56 -0800 (PST) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 14:55:46 -0800 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, 4 Dec 2009 22:55:44 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 04 Dec 2009 15:55:54 -0700 From: Joe Hildebrand To: Jonas Lindberg , Message-ID: Thread-Topic: [xmpp] draft-hildebrand-dna-00 review Thread-Index: Acp1NO7hVULxMrWy602tG2fXqRf8sA== In-Reply-To: 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: 04 Dec 2009 22:55:46.0875 (UTC) FILETIME=[EAA288B0:01CA7534] Subject: Re: [xmpp] draft-hildebrand-dna-00 review 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, 04 Dec 2009 22:55:57 -0000 Inline, as individual contributor. On 11/25/09 9:38 AM, "Jonas Lindberg" wrote: > Assumption: not all service administrators will provide an attribute > certificate proof for their domain. > > Given assumption above, a feature that may be useful for a large > hosting providers is allowing domain administrators to choose their > policy for what is an acceptable proof. Some domain administrators may > require strong evidence like attribute certificates proofs. Others > administrators may be OK with some weaker proof (e.g. SRV record > lookup) if that enables their users to chat with with more domains. Agree. > Implementing per domain proof policies using the current draft > protocol would be a bit clunky, since for a given stream a remote > domain is either valid on invalid as far as all local domains are > concerned. > > One possible solution is to do assertions on domain pair basis, adding > a from attribute to the valid stanza and so on: > > from='target.tld'/> I'm fine with that. There might need to be some text that says that if the stream has already offered proof that a particular domain would be willing to accept, a further challenges are not required. > This requires sending significantly more assert/valid stanzas, but if > done on demand this setup overhead would hopefully be small on average > compared to subsequent traffic between the domains. > > Thoughts? If this gets to be a problem with the amount of traffic, we can figure out some compression or caching schemes later. Let's get some implementation experience. > 4.3. Invalidation > > Here or elsewhere, suggest saying that a server SHOULD send an > impossible element when it is no longer authoritative for a given > domain that it previously validated. The remote server should > re-resolve SRV record when receiving the 'impossible' to see if > service moved. +1 > Servers may also want to periodically resolve SRV and redo validation > of remote domains, just in case the remote service fails to notify > that it no longer authoritative for a domain. +1. Validation probably also requires revocation checks, too. > 4.4: > > > > < type='http://example.com/proof/custom'/> > > > Why not: > > > type='http://example.com/proof/custom'/> > The intent was that those were two different proof options that the challenger was offering, which your approach doesn't capture. I also wanted to preserve the option to add children in the namespace of the challenge element if we needed to send information there for some challenge types. > 6.4: > > Once an originating server completes this first validation it signals > that it is willing and able to participate in bi-directional XMPP > federation traffic, as long as all of the domains required have been > asserted and validated at least once on this stream. > > At Google, we run one set of servers for inbound s2s traffic and one > set for outbound for reasons that have to do with our production > setup. Changing this to accommodate bi-directional traffic should be > doable, but if others have similar setups then it may make sense to > consider a one-way traffic option. I'm open to the directionality being negotiated mutually. > 6.7: > > If the server receiving a proactive validation is no long authoritative for > a given domain, it MUST send an "impossible" element, at which point > the sender MUST remove the receiver from any cache and not send any > stanzas on this stream to the given domain." > > s/long/longer Nod. > 6.9 > > Ensure that only one challenge is outstanding on a given connection > for a given domain. Ensure that only one assertion or one proof is > outstanding on a given connection for a given domain. > > Assume 'for a given domain' means 'for a given local domain/remote > domain pair'? Seems useful for two big hosting providers to validate > many domain pairs in parallel when setting up a connection. Yes, with your addition above, this needs to be per-pair. There are probably several other places that need to be cleaned up for that change. -- Joe Hildebrand From bernard.aboba@gmail.com Tue Dec 15 08:42:50 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 4B0533A6A10 for ; Tue, 15 Dec 2009 08:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 GghWza+4U7iX for ; Tue, 15 Dec 2009 08:42:49 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id DF46B3A67BE for ; Tue, 15 Dec 2009 08:42:48 -0800 (PST) Received: by pzk6 with SMTP id 6so25844pzk.29 for ; Tue, 15 Dec 2009 08:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=f7e7ZMm8ApncdoizZxhgpMGxkESO2Jr7j6ZsqBVLAi4=; b=HJdb8sMCVhV7MacHt8DGt3fCVA9O7d9sdJSyvWTXnxY+B8W6pZfWiGtVVzxgbgaHf4 TE2iL8UGKD8h3Iuh+bVdqii69oJMUh2qxIzMTpXDwpnzRJbjRkzzX8fefBPg/BSk5M8R P/O4YLPku2NNTfuci+5l8gdDVLZU3DPxCMzlU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=B4Uw3KdKx5ghZz78RZVj0fHvvnh8QRIIpxxR4pdo48U3MGuB3k720RYQvEOUfLa54w lRVqVJNA65bE5yNz7hYL8qUTYUflt+xBrglpk4g4ta3eHYfLTZt2BCSZTo1gNpeKMK5t Okj8ECfQ9HLzVSAUIbFAwvEadqlzgXhdefQ9s= MIME-Version: 1.0 Received: by 10.142.61.19 with SMTP id j19mr4240889wfa.184.1260895352089; Tue, 15 Dec 2009 08:42:32 -0800 (PST) From: Bernard Aboba Date: Tue, 15 Dec 2009 08:42:12 -0800 Message-ID: <223709240912150842v1b4429b2wf11928797e071838@mail.gmail.com> To: xmpp@ietf.org Content-Type: multipart/alternative; boundary=001636e0a6b28f6e40047ac71328 Subject: [xmpp] RFC 3920bis and IDNA2008 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, 15 Dec 2009 16:42:50 -0000 --001636e0a6b28f6e40047ac71328 Content-Type: text/plain; charset=ISO-8859-1 In looking at 3920bis there would appear to be some text that may be worth updating for IDNA2008. Section 17: References You may wish to remove the [IDNA] reference and substitute references to the IDNA2008 document set: [IDNA2008-Defs] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", Internet draft (work in progress), draft-ietf-idnabis-defs-12.txt, October 2009. [IDNA2008-Rationale] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", Internet draft (work in progress), draft-ietf-idnabis-rationale-14.txt, October 2009. [IDNA2008-Protocol] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Protocol", Internet draft (work in progress), draft-ietf-idnabis-protocol-17.txt, October 2009. [IDNA2008-Tables] Falstrom, P., "The Unicode Code Points and IDNA", Internet draft (work in progress), draft-ietf-idnabis-tables-08.txt, November 2009. [IDNA2008-Bidi] Alvestrand, H., Karp, C., "Right-to-left scripts for IDNA", Internet draft (work in progress), draft-ietf-idnabis-bidi-06.txt, September 2009. Section 13 "As specified under Section 3, a server MUST support and enforce [IDNA] for domain identifiers..." [BA] Suggest that [IDNA] be changed to [IDNA2008-Protocol] here. Section 3.2 A domain identifier MUST be an "internationalized domain name" as defined in [IDNA], that is, "a domain name in which every label is an internationalized label". [BA] My suggestion is that the [IDNA] reference here be changed to [IDNA2008-Defs]. In terms of the definition, I think you may want to be more specific, such as using the term "U-label" instead of internationalized label in the above sentence. Note that [IDNA2008-Defs] Section 2.3.2.3 defines an "internationalized domain name" a bit differently than [IDNA] did: 2.3.2.3. Internationalized Domain Name An "internationalized domain name" (IDN) is a domain name that contains at least one A-label or U-label, but that otherwise may contain any mixture of NR-LDH-labels, A-labels, or U-labels. -------------------------------------------- When preparing a text label (consisting of a sequence of Unicode code points) for representation as an internationalized label in the process of constructing an XMPP domain identifier or comparing two XMPP domain identifiers, an application MUST ensure that for each text label it is possible to apply without failing the ToASCII operation specified in [IDNA] with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label. An internationalized domain name (and therefore an XMPP domain identifier) is constructed from its constituent internationalized labels by following the rules specified in [IDNA]. [BA] Suggest that this be changed to: "When preparing a U-label (consisting of a sequence of Unicode code points) for representation as an A-label in the process of constructing an XMPP domain identifier or comparing two XMPP domain identifiers, an application MUST ensure that each U-label can be successfully converted to an A-label according to the "Punycode" specification [RFC3492], and that other constraints on the validity of a U-label are met, as described in [IDNA2008-Defs] Section 2.3.2.1. An internationalized domain name (and therefore an XMPP domain identifier) is constructed from its constitutent internationalized labels by following the rules specified in [IDNA2008-Protocol]." "Note: The ToASCII operation includes application of the [NAMEPREP] profile of [STRINGPREP] and encoding using the algorithm specified in [PUNYCODE]; for details, see [IDNA]. Although the output of the ToASCII operation is not used in XMPP, it MUST be possible to apply that operation without failing. " [BA] As described in draft-ietf-idnabis-rationale Section 7.3, IDNA2008 is not dependent on Nameprep. Therefore it is not clear to me that the Note is still necessary. 7.3. Character Mapping As discussed at length in Section 6, IDNA2003, via Nameprep (see Section 7.5), mapped many characters into related ones. Those mappings no longer exist as requirements in IDNA2008. These specifications strongly prefer that only A-labels or U-labels be used in protocol contexts and as much as practical more generally. IDNA2008 does anticipate situations in which some mapping at the time of user input into lookup applications is appropriate and desirable. The issues are discussed in Section 6 and specific recommendations are made in [IDNA2008-Mapping]. --001636e0a6b28f6e40047ac71328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In looking at 3920bis there would appear to be some text that may be worth = updating for IDNA2008.

Section 17: References

You may wish t= o remove the [IDNA] reference and substitute references to the IDNA2008 doc= ument set:

[IDNA2008-Defs] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", Internet draft (work in progress), draft-ietf-idnabis-defs-12.txt, October 2009.

[IDNA2008-Rationale] Klensin, J., "Internationalized Domain Names for Applications (IDNA):=A0 Background, Explanation, and Rationale", Internet draft (work in progress), draft-ietf-idnabis-rationale-14.txt, October 2009.

[IDNA2008-Protocol] Klensin, J., "Internationalized Domain Names for Applications (IDNA):=A0 Protocol", Internet draft (work in progress), draft-ietf-idnabis-protocol-17.txt, October 2009.

[IDNA2008-Tables] Falstrom, P., "The Unicode Code Points and IDNA"= ;, Internet draft (work in progress), draft-ietf-idnabis-tables-08.txt, November 2009.

[IDNA2008-Bidi] Alvestrand, H., Karp, C., "Right-to-left scripts for I= DNA", Internet draft (work in progress), draft-ietf-idnabis-bidi-06.tx= t, September 2009.


Section 13

"As specified under Section 3, a server M= UST support and enforce [IDNA] for domain identifiers..."

[BA] Suggest that [IDNA] b= e changed to [IDNA2008-Protocol] here.


Section 3.2

A = domain identifier MUST be an "internationalized domain name" as defined in [IDNA], that is, "a domain name in which every label is = an internationalized label".

[BA]=A0 My suggestion is that th= e [IDNA] reference here be changed to [IDNA2008-Defs].=A0 In terms of the d= efinition, I think you may want to be more specific, such as using the term= "U-label" instead of internationalized label in the above senten= ce.

Note that [IDNA2008-Defs] Section 2.3.2.3 defines an "internationa= lized domain name" a bit differently than [IDNA] did:

2.3.2.3.  Internationalized Domain Name

   An "internation=
alized domain name" (IDN) is a domain name that
   contains at leas=
t one A-label or U-label, but that otherwise may
   contain any mixture =
of NR-LDH-labels, A-labels, or U-labels.


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

When preparing = a text label (consisting of a sequence of Unicode code points) for representation as an internationalized label in the process of constructing an XMPP domain identifier or comparing two XMPP domain identifiers, an application MUST ensure that for each text label it is possible to apply without failing the ToASCII operation specified in [IDNA] with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label.

An internationalized domain name (and therefore an XMPP domain identifier) is constructed from its constituent internationalized labels by following the rules specified in [IDNA].

[BA] Suggest that this be changed to:

"When preparing a= U-label (consisting of a sequence of Unicode code points) for representati= on as an A-label in the process of constructing an XMPP domain identifier o= r comparing two XMPP
domain identifiers, an application MUST ensure that each U-label can be suc= cessfully converted to an A-label according to the "Punycode" spe= cification [RFC3492], and that other constraints on the validity
of a U-= label are met, as described in [IDNA2008-Defs] Section 2.3.2.1.

An internationalized domain name (and therefore an XMPP domain identif= ier) is constructed from its constitutent internationalized labels by follo= wing the rules specified in [IDNA2008-Protocol]."


"Note: The ToASCII operation includes application of the [NAME= PREP] profile of [STRINGPREP] and encoding using the algorithm specified in [PUNYCODE]; for details, see [IDNA]. Although the output of the ToASCII operation is not used in XMPP, it MUST be possible to apply that operation without failing. "

[BA] As described in=A0 draft-ietf-idnabis-rationale Section = 7.3, IDNA2008 is not dependent on Nameprep.=A0 Therefore it is not clear to= me that the Note is still necessary. 

7.3.  Character Mapping<=
br>


   As discussed at length in Section 6, IDNA2003, via Nameprep (see
=
   Section 7.5), mapped many characters into related ones.  Those
   map=
pings no longer exist as requirements in IDNA2008.  These
   specificati=
ons strongly prefer that only A-labels or U-labels be used


   in protocol contexts and as much as practical more generally.
   IDNA=
2008 does anticipate situations in which some mapping at the time
   of =
user input into lookup applications is appropriate and desirable.
   The=
 issues are discussed in Section 6 and specific recommendations


   are made in [IDNA2008-Mapping].



--001636e0a6b28f6e40047ac71328-- From stpeter@stpeter.im Tue Dec 15 09:18: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 027733A6A9E for ; Tue, 15 Dec 2009 09:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, GB_I_LETTER=-2] 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 WVJlRovACjgA for ; Tue, 15 Dec 2009 09:18:10 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 659E83A6ACE for ; Tue, 15 Dec 2009 09:18:10 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 30BC640C29; Tue, 15 Dec 2009 10:17:56 -0700 (MST) Message-ID: <4B27C4C2.8000407@stpeter.im> Date: Tue, 15 Dec 2009 10:17:54 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba References: <223709240912150842v1b4429b2wf11928797e071838@mail.gmail.com> In-Reply-To: <223709240912150842v1b4429b2wf11928797e071838@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020607010301090308000801" Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 3920bis and IDNA2008 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, 15 Dec 2009 17:18:12 -0000 This is a cryptographically signed message in MIME format. --------------ms020607010301090308000801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/15/09 9:42 AM, Bernard Aboba wrote: > In looking at 3920bis there would appear to be some text that may be > worth updating for IDNA2008. Many thanks for this post (and your previous one about e2e encryption, to which I still need to reply). The IDNA2008 work introduces a number of interesting issues for XMPP. And those issues are not limited to domain labels, because we also use stringprep (as did IDNA2003) for localparts and resourceparts of XMPP addresses. We've been dancing around these issues for quite a while, hoping that a more general approach to "fixing i18n" would emerge within the IETF. That has not happened yet, but I have heard rumors that there will be more discussion about this in Anaheim. I've been meaning to write a more general report about these issues as they impinge on XMPP (based on my in-depth reading of the IDNA2008 specs and my own imperfect knowledge of i18n challenges), but I haven't found the time yet. Perhaps I'll do that in the next 10 days... > Section 17: References > > You may wish to remove the [IDNA] reference and substitute references to > the IDNA2008 document set: > > [IDNA2008-Defs] Klensin, J., "Internationalized Domain Names for > Applications (IDNA): Definitions and Document Framework", Internet draft > (work in progress), draft-ietf-idnabis-defs-12.txt, October 2009. > > [IDNA2008-Rationale] Klensin, J., "Internationalized Domain Names for > Applications (IDNA): Background, Explanation, and Rationale", Internet > draft (work in progress), draft-ietf-idnabis-rationale-14.txt, October > 2009. > > [IDNA2008-Protocol] Klensin, J., "Internationalized Domain Names for > Applications (IDNA): Protocol", Internet draft (work in progress), > draft-ietf-idnabis-protocol-17.txt, October 2009. > > [IDNA2008-Tables] Falstrom, P., "The Unicode Code Points and IDNA", > Internet draft (work in progress), draft-ietf-idnabis-tables-08.txt, > November 2009. > > [IDNA2008-Bidi] Alvestrand, H., Karp, C., "Right-to-left scripts for > IDNA", Internet draft (work in progress), > draft-ietf-idnabis-bidi-06.txt, September 2009. If we decide that we need to "upgrade" to IDNA2008, yes. I don't see how we could *not* do that, but it might have some nasty implications (e.g., perhaps existing deployments use both A-labels and U-labels). > Section 13 > > "As specified under Section 3, a server MUST support and enforce [IDNA] > for domain identifiers..." > > [BA] Suggest that [IDNA] be changed to [IDNA2008-Protocol] here. Yes, with the foregoing proviso. > Section 3.2 > > A domain identifier MUST be an "internationalized domain name" as > defined in [IDNA], that is, "a domain name in which every label is an > internationalized label". > > [BA] My suggestion is that the [IDNA] reference here be changed to > [IDNA2008-Defs]. In terms of the definition, I think you may want to be > more specific, such as using the term "U-label" instead of > internationalized label in the above sentence. Yes, the IDNA2008 specs are much clearer in their terminology. Ideally we'd recommend the use of U-labels only, but we probably have deployment of A-labels on the XMPP network, which makes things messier. > Note that [IDNA2008-Defs] Section 2.3.2.3 defines an "internationalized > domain name" a bit differently than [IDNA] did: > > 2.3.2.3. Internationalized Domain Name > > An "internationalized domain name" (IDN) is a domain name that > contains at least one A-label or U-label, but that otherwise may > contain any mixture of NR-LDH-labels, A-labels, or U-labels. True, i18n applies only to a given label. Vint Cerf had a good post about this a few days ago on the IDNA list. > -------------------------------------------- > > When preparing a text label (consisting of a sequence of Unicode code > points) for representation as an internationalized label in the process > of constructing an XMPP domain identifier or comparing two XMPP domain > identifiers, an application MUST ensure that for each text label it is > possible to apply without failing the ToASCII operation specified in > [IDNA] with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code > points other than letters, digits, and hyphens). If the ToASCII > operation can be applied without failing, then the label is an > internationalized label. > > An internationalized domain name (and therefore an XMPP domain > identifier) is constructed from its constituent internationalized labels > by following the rules specified in [IDNA]. > > [BA] Suggest that this be changed to: > > "When preparing a U-label (consisting of a sequence of Unicode code > points) for representation as an A-label in the process of constructing > an XMPP domain identifier or comparing two XMPP > domain identifiers, an application MUST ensure that each U-label can be > successfully converted to an A-label according to the "Punycode" > specification [RFC3492], and that other constraints on the validity > of a U-label are met, as described in [IDNA2008-Defs] Section 2.3.2.1. > > An internationalized domain name (and therefore an XMPP domain > identifier) is constructed from its constitutent internationalized > labels by following the rules specified in [IDNA2008-Protocol]." > > "Note: The ToASCII operation includes application of the [NAMEPREP] > profile of [STRINGPREP] and encoding using the algorithm specified in > [PUNYCODE]; for details, see [IDNA]. Although the output of the ToASCII > operation is not used in XMPP, it MUST be possible to apply that > operation without failing. " > > [BA] As described in draft-ietf-idnabis-rationale Section 7.3, IDNA2008 > is not dependent on Nameprep. Therefore it is not clear to me that the > Note is still necessary. I think the note is no longer needed, and that your suggested text is consistent with IDNA2008 (though I'll need to double-check it against my grasp of IDNA2008, which always feels rather tenuous). One point of clarification: I think we need to be especially careful about statements such as "a sequence of Unicode code points" because (as was pointed out at the IRI BoF in Hiroshima) Unicode code points are just identifiers for characters, for example: U+13AB U+13AA U+13F4 U+13F4 U+13AC U+13D2 Those aren't encoded at all -- I could write a sequence of Unicode code points in pen or pencil or whatever. So we need to specify more carefully that for XMPP the sequence of code points is encoded as UTF-8. > 7.3. Character Mapping > > As discussed at length in Section 6, IDNA2003, via Nameprep (see > Section 7.5), mapped many characters into related ones. Those > mappings no longer exist as requirements in IDNA2008. These > specifications strongly prefer that only A-labels or U-labels be used > in protocol contexts and as much as practical more generally. > IDNA2008 does anticipate situations in which some mapping at the time > of user input into lookup applications is appropriate and desirable. > The issues are discussed in Section 6 and specific recommendations > are made in [IDNA2008-Mapping]. > > ------------------------------------------------------------------------ I think we would prefer U-labels above A-levels (XMPP is pure UTF-8, so why use A-label representations at all?). And this text feels a bit vague to me, but I don't have clearer text to offer at the moment. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020607010301090308000801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNTE3MTc1NFowIwYJKoZIhvcNAQkEMRYEFLWu3PbYlZYG8OUQWhGa hFo0QjSGMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAVQxiE4i2hSGnzfhq7gYagUlWqlRDUGnCodi4h+yl 05EFTkrAW1OSLqM7kkctJXuZr8bdAhOGSonIkBNLnQ9zvglqlimYypWa05blkP83VNbUqlc4 Wx/wL+xoLi2uon1VsA7a/z3/l99wC3AQSAxuGQPrTFtvKeuNZx7lsDXvHXSv2NjbrMXg9PEC ks2Nxzp+hOnL99oJ4IXmPVx0IA7pX80u762ElXJ0XndRv1kiIk5ad1lpeNWJ+s+dI6qbO/b3 +Hb0Ob35cAd8UOLZ7S30CR8iq3bQ0I4magXJ5Ff9Tgr5puZWnGFOgw077x8a6vMeDi+kHhZm olPrDKRdl9UbfQAAAAAAAA== --------------ms020607010301090308000801-- From bernard.aboba@gmail.com Tue Dec 15 12:52:45 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 B39593A68CF for ; Tue, 15 Dec 2009 12:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 KiWCWa6d7Usg for ; Tue, 15 Dec 2009 12:52:44 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id B232E3A6857 for ; Tue, 15 Dec 2009 12:52:44 -0800 (PST) Received: by pxi1 with SMTP id 1so178814pxi.29 for ; Tue, 15 Dec 2009 12:52:26 -0800 (PST) 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=7zNqO1eku0eohKQXTeUG0CW8kjKKjEqn63rJR05+AxQ=; b=nRAQwy9B99PrFXSMQ1w0qkGjahmN3okLo8/bDh8sA//a8LSY3wswWXGC1cgkfMfO9U 0FJ4/a67Ebht50AzU0DJSHWFeF0DosRya/81ijYuc3tVZ71d5lQppYNCWH4uUP4ghxgb 7TGIXp4uX6ahMT/8eAp4cDlj5R1f3Yc8huVYc= 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=WmDFzgeVrprBSZBbrxCUZC01ATaJ68flUMd0pGv2SsuPNvhb5SVlSN1StP5DJKjv2R efEAN6TWoNkzjigyOVKE6BC1D18w5nD8nY5G+kvNEKz5oi3DSOTlVnVrtQQQCiZBS8dh e0x3KqSsDSdnNh4MjXWra6XVJZfRC+WDF1dqA= MIME-Version: 1.0 Received: by 10.143.153.29 with SMTP id f29mr13097wfo.294.1260910345109; Tue, 15 Dec 2009 12:52:25 -0800 (PST) In-Reply-To: <223709240912151122x886cac1iee6ab9ba052bda93@mail.gmail.com> References: <223709240912150842v1b4429b2wf11928797e071838@mail.gmail.com> <4B27C4C2.8000407@stpeter.im> <223709240912151122x886cac1iee6ab9ba052bda93@mail.gmail.com> From: Bernard Aboba Date: Tue, 15 Dec 2009 12:52:05 -0800 Message-ID: <223709240912151252l250cc64cm3ce708f3e8d1726d@mail.gmail.com> To: xmpp@ietf.org Content-Type: multipart/alternative; boundary=001636e0b8c836bf4d047aca9181 Subject: Re: [xmpp] RFC 3920bis and IDNA2008 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, 15 Dec 2009 20:52:45 -0000 --001636e0b8c836bf4d047aca9181 Content-Type: text/plain; charset=ISO-8859-1 As noted in [IDNA2008-Rationale] document Section 7.5, IDNA2008 did not modify Stringprep or Nameprep (or SASLPrep, for that matter). This enables us to keep the issue of localparts/resourceparts separate from IDNA2008. That's probably a good thing, since the "more general approach" (or even a revision of Stringprep/Nameprep) does not appear on the horizon. In the meantime though, it may be useful to gain an understanding of how current implementations behave. 7.5. Stringprep Changes and Compatibility The Nameprep [RFC3491] specification, a key part of IDNA2003, is a profile of Stringprep [RFC3454]. While Nameprep is a Stringprep profile specific to IDNA, Stringprep is used by a number of other protocols. Were Stringprep to have been modified by IDNA2008, those changes to improve the handling of IDNs could cause problems for non- DNS uses, most notably if they affected identification and authentication protocols. Several elements of IDNA2008 give interpretations to strings prohibited under IDNA2003 or prohibit strings that IDNA2003 permitted. Those elements include the proposed new inclusion tables [IDNA2008-Tables], the reduction in the number of characters permitted as input for registration or lookup (Section 3), and even the proposed changes in handling of right to left strings [IDNA2008-Bidi]. IDNA2008 does not use Nameprep or Stringprep at all, so there are no side-effect changes to other protocols. It is particularly important to keep IDNA processing separate from processing for various security protocols because some of the constraints that are necessary for smooth and comprehensible use of IDNs may be unwanted or undesirable in other contexts. For example, the criteria for good passwords or passphrases are very different from those for desirable IDNs: passwords should be hard to guess, while domain names should normally be easily memorable. Similarly, internationalized SCSI identifiers and other protocol components are likely to have different requirements than IDNs. On Tue, Dec 15, 2009 at 9:17 AM, Peter Saint-Andre wrote: > > The IDNA2008 work introduces a number of interesting issues for XMPP. > And those issues are not limited to domain labels, because we also use > stringprep (as did IDNA2003) for localparts and resourceparts of XMPP > addresses. We've been dancing around these issues for quite a while, > hoping that a more general approach to "fixing i18n" would emerge within > the IETF. That has not happened yet, but I have heard rumors that there > will be more discussion about this in Anaheim. I've been meaning to > write a more general report about these issues as they impinge on XMPP > (based on my in-depth reading of the IDNA2008 specs and my own imperfect > knowledge of i18n challenges), but I haven't found the time yet. Perhaps > I'll do that in the next 10 days... > > > --001636e0b8c836bf4d047aca9181 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As noted in=A0[IDNA2008-Rationale] document Section 7.5, IDNA2008 did not m= odify Stringprep or Nameprep (or SASLPrep, for that matter). This enables u= s to keep the issue of localparts/resourceparts separate from IDNA2008.=A0 = That's probably a good thing, since the "more general approach&quo= t; (or even a revision of Stringprep/Nameprep) does not appear on the horiz= on.=A0=A0In the meantime though, it=A0may be useful to gain an understandin= g=A0of how current implementations behave. =A0
=A0
7.5.=A0 Stringprep Changes and Compatibility

=A0=A0 The Namepre= p [RFC3491] specification, a key part of IDNA2003, is a
=A0=A0 profile o= f Stringprep [RFC3454].=A0 While Nameprep is a Stringprep
=A0=A0 profile= specific to IDNA, Stringprep is used by a number of other
=A0=A0 protocols.=A0 Were Stringprep to have been modified by IDNA2008, tho= se
=A0=A0 changes to improve the handling of IDNs could cause problems f= or non-
=A0=A0 DNS uses, most notably if they affected identification an= d
=A0=A0 authentication protocols.=A0 Several elements of IDNA2008 give<= br> =A0=A0 interpretations to strings prohibited under IDNA2003 or prohibit
= =A0=A0 strings that IDNA2003 permitted.=A0 Those elements include the propo= sed
=A0=A0 new inclusion tables [IDNA2008-Tables], the reduction in the = number
=A0=A0 of characters permitted as input for registration or lookup
=A0= =A0 (Section 3), and even the proposed changes in handling of right to
= =A0=A0 left strings [IDNA2008-Bidi].=A0 IDNA2008 does not use Nameprep or=A0=A0 Stringprep at all, so there are no side-effect changes to other =A0=A0 protocols.

=A0=A0 It is particularly important to keep IDNA p= rocessing separate from
=A0=A0 processing for various security protocols= because some of the
=A0=A0 constraints that are necessary for smooth an= d comprehensible use of
=A0=A0 IDNs may be unwanted or undesirable in other contexts.=A0 For exampl= e,
=A0=A0 the criteria for good passwords or passphrases are very differ= ent
=A0=A0 from those for desirable IDNs: passwords should be hard to gu= ess,
=A0=A0 while domain names should normally be easily memorable.=A0 S= imilarly,
=A0=A0 internationalized SCSI identifiers and other protocol components are=
=A0=A0 likely to have different requirements than IDNs.
=
=A0
On Tue, Dec 15, 2009 at 9:17 AM, Peter Saint-And= re <stpeter@stpeter.im> wrote:

The IDNA2008 = work introduces a number of interesting issues for XMPP.
And those issue= s are not limited to domain labels, because we also use
stringprep (as did IDNA2003) for localparts and resourceparts of XMPP
ad= dresses. We've been dancing around these issues for quite a while,
h= oping that a more general approach to "fixing i18n" would emerge = within
the IETF. That has not happened yet, but I have heard rumors that there
= will be more discussion about this in Anaheim. I've been meaning to
= write a more general report about these issues as they impinge on XMPP
(based on my in-depth reading of the IDNA2008 specs and my own imperfectknowledge of i18n challenges), but I haven't found the time yet. Perha= ps
I'll do that in the next 10 days...

=A0

--001636e0b8c836bf4d047aca9181-- From stpeter@stpeter.im Tue Dec 15 13:06: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 45E4F3A682F for ; Tue, 15 Dec 2009 13:06:03 -0800 (PST) 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 G+yX1NHYzJdL for ; Tue, 15 Dec 2009 13:06:02 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1B7003A6814 for ; Tue, 15 Dec 2009 13:06:02 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 070FC40352; Tue, 15 Dec 2009 14:05:47 -0700 (MST) Message-ID: <4B27FA2A.4040208@stpeter.im> Date: Tue, 15 Dec 2009 14:05:46 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba References: <223709240912150842v1b4429b2wf11928797e071838@mail.gmail.com> <4B27C4C2.8000407@stpeter.im> <223709240912151122x886cac1iee6ab9ba052bda93@mail.gmail.com> <223709240912151252l250cc64cm3ce708f3e8d1726d@mail.gmail.com> In-Reply-To: <223709240912151252l250cc64cm3ce708f3e8d1726d@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010203060308070406060508" Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 3920bis and IDNA2008 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, 15 Dec 2009 21:06:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010203060308070406060508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/15/09 1:52 PM, Bernard Aboba wrote: > As noted in [IDNA2008-Rationale] document Section 7.5, IDNA2008 did not > modify Stringprep or Nameprep (or SASLPrep, for that matter). This > enables us to keep the issue of localparts/resourceparts separate from > IDNA2008. Agreed. However, the fact that IDNA is moving away from the stringprep model might give us pause. There are important differences between domain names and usernames (localpart) or device identifiers (resourcepart), but I think the IDNA2008 work might lead us to at least question some of our assumptions. Perhaps we'll draw the same conclusion we drew before, but it doesn't hurt to think about it a bit more. > That's probably a good thing, since the "more general > approach" (or even a revision of Stringprep/Nameprep) does not appear on > the horizon. Indeed. But given that XMPP technologies are one of the main applications of stringprep, we might have some good insights to contribute based on our implementation experience. > In the meantime though, it may be useful to gain an > understanding of how current implementations behave. Yes. > 7.5. Stringprep Changes and Compatibility > > The Nameprep [RFC3491] specification, a key part of IDNA2003, is a > profile of Stringprep [RFC3454]. While Nameprep is a Stringprep > profile specific to IDNA, Stringprep is used by a number of other > protocols. Were Stringprep to have been modified by IDNA2008, those > changes to improve the handling of IDNs could cause problems for non- > DNS uses, most notably if they affected identification and > authentication protocols. Several elements of IDNA2008 give > interpretations to strings prohibited under IDNA2003 or prohibit > strings that IDNA2003 permitted. Those elements include the proposed > new inclusion tables [IDNA2008-Tables], the reduction in the number > of characters permitted as input for registration or lookup > (Section 3), and even the proposed changes in handling of right to > left strings [IDNA2008-Bidi]. IDNA2008 does not use Nameprep or > Stringprep at all, so there are no side-effect changes to other > protocols. > > It is particularly important to keep IDNA processing separate from > processing for various security protocols because some of the > constraints that are necessary for smooth and comprehensible use of > IDNs may be unwanted or undesirable in other contexts. For example, > the criteria for good passwords or passphrases are very different > from those for desirable IDNs: passwords should be hard to guess, > while domain names should normally be easily memorable. Similarly, > internationalized SCSI identifiers and other protocol components are > likely to have different requirements than IDNs. Yes, I would recommend that everyone on this list read all the IDNA2008 specs but it's a lot of work, which is why I hope to condense the issues down to a mail that I can send to this list. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms010203060308070406060508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNTIxMDU0NlowIwYJKoZIhvcNAQkEMRYEFPInf/+7KV+iPp0+L3y/ 1YqR9bnrMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAb2bwW2Bn7H0bS4avj8BfJ97OofDp9udjtgUYhG2b zKbDB9xgtxfr76HZapQyo9PR5tm3jnAqcZpDmkNCpE1ZW/h0poaCId6Rdxc0QN71ZxL1ljwm jKFnAmPm9ytp7lticWldDCCZIhpG2IReaTstMQpgwbxu7lKHeR1n5KQwGEjHQLBxzpaAOCs9 qRR2CtGNdiWU7Sw9Nj+IThV+DUKb2QQ3mJ6RbhjgRoh+XVC1WWruUtVHMhvgDu46k9P0Opse nGyWgMHGbk+3k1SVHU2t9/RVs29ECjefkykFbo0ZUrSRajGK7IY22MjifrJpEVXCJm4aun4V yluCE1fA4EXrdwAAAAAAAA== --------------ms010203060308070406060508-- From bernard.aboba@gmail.com Tue Dec 15 16:18:01 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 AD90E3A6A22 for ; Tue, 15 Dec 2009 16:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 QVPmg001UUVi for ; Tue, 15 Dec 2009 16:18:00 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 25B703A67F7 for ; Tue, 15 Dec 2009 16:18:00 -0800 (PST) Received: by pzk6 with SMTP id 6so281153pzk.29 for ; Tue, 15 Dec 2009 16:17:43 -0800 (PST) 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; bh=x/8ltw7DYtOcKID4UVR6reVf6Rcr2tfFjQD3p3F+X3M=; b=a/unFd2mqIL1LdKggmwFfDGpS50jH9e6vldDmf61kTpeE4xE+nUj8V0T5JkYG9dGZo WcRfBy5E3Pzcuu54mFa1OOOVwdT7disVhTaxy8GlOAh9cSA1NvvcbO2pdz7oXRMr/Gtk Mz0IcKv5cjO7aCwxLbO9NqEspxa3AF+mD8wnI= 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; b=l2z+l4Vhul6+pguu40lj2YdBMcoomA3ZvaDzX3NjA3lRi6jOwg5q4vL731GTkYQQI2 vuPZsXHzlIfW2WLZDaes20VRoe3eLASDEoRZCX5Of4LDnHeRLj1jk5DH8qsLod99u3R3 uwaKPp3VoU/rQNG1nO1aGcgbMT/IgM4dtm09w= MIME-Version: 1.0 Received: by 10.142.151.12 with SMTP id y12mr185637wfd.8.1260922663092; Tue, 15 Dec 2009 16:17:43 -0800 (PST) In-Reply-To: <4B27FA2A.4040208@stpeter.im> References: <223709240912150842v1b4429b2wf11928797e071838@mail.gmail.com> <4B27C4C2.8000407@stpeter.im> <223709240912151122x886cac1iee6ab9ba052bda93@mail.gmail.com> <223709240912151252l250cc64cm3ce708f3e8d1726d@mail.gmail.com> <4B27FA2A.4040208@stpeter.im> From: Bernard Aboba Date: Tue, 15 Dec 2009 16:17:23 -0800 Message-ID: <223709240912151617x5790449eu597d0f67ae573591@mail.gmail.com> To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=000e0cd313146c437a047acd6fd0 Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 3920bis and IDNA2008 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, 16 Dec 2009 00:18:01 -0000 --000e0cd313146c437a047acd6fd0 Content-Type: text/plain; charset=ISO-8859-1 > Agreed. However, the fact that IDNA is moving away from the stringprep > model might give us pause. There are important differences between > domain names and usernames (localpart) or device identifiers > (resourcepart), but I think the IDNA2008 work might lead us to at least > question some of our assumptions. Perhaps we'll draw the same conclusion > we drew before, but it doesn't hurt to think about it a bit more. > > Indeed, the move away from the stringprep model does raise a lot of questions -- after all, Appendix A (Nodeprep) and Appendix B (Resourceprep) both represent stringprep profiles. In those Appendices we see some of the same issues that arose with IDNA2003 (Unicode version independence, mapping, potential bidi issues, etc.). Unfortunately, an obvious path forward wasn't evident to me. Even given the pending completion of work on IDNA2008, it seems like some very substantial effort might be required. For example, the amount of work required to restructure the IDNA2003 document set (even setting aside documents such as [IDNA2008-Tables] and [IDNA2008-Bidi]) was very substantial. Is this something that could be helped by a bar/real Stringprep-bis BOF in Annaheim? --000e0cd313146c437a047acd6fd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agreed. However, the fact that IDNA is moving away from the strin= gprep
model might give us pause. There are important differences between
domain names and usernames (localpart) or device identifiers
(resourcepart), but I think the IDNA2008 work might lead us to at least
question some of our assumptions. Perhaps we'll draw the same conclusio= n
we drew before, but it doesn't hurt to think about it a bit more.

Indeed, the move away from the stringprep model doe= s raise a lot of questions -- after all, Appendix A (Nodeprep) and Appendix= B (Resourceprep) both represent stringprep profiles.=A0 In those Appendice= s we see some of the same issues that arose with IDNA2003 (Unicode version = independence, mapping, potential bidi issues, etc.).=A0

Unfortunately, an obvious path forward wasn't evident to me.=A0 Eve= n given the pending completion of work on IDNA2008, it seems like some very= substantial effort might be required.=A0 For example, the amount of work r= equired to restructure the IDNA2003 document set (even setting aside docume= nts such as [IDNA2008-Tables] and [IDNA2008-Bidi]) was very substantial.=A0=

Is this something that could be helped by a bar/real Stringprep-bis BOF= in Annaheim?=A0

--000e0cd313146c437a047acd6fd0-- From stpeter@stpeter.im Tue Dec 15 18:45:11 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 3F84D3A63EC for ; Tue, 15 Dec 2009 18:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 Vf73wD+Buwrq for ; Tue, 15 Dec 2009 18:45:10 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1D1403A6949 for ; Tue, 15 Dec 2009 18:45:09 -0800 (PST) Received: from squire.local (dsl-228-57.dynamic-dsl.frii.net [216.17.228.57]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A3DFA40352; Tue, 15 Dec 2009 19:44:55 -0700 (MST) Message-ID: <4B2849A6.9090501@stpeter.im> Date: Tue, 15 Dec 2009 19:44:54 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba References: <223709240912150842v1b4429b2wf11928797e071838@mail.gmail.com> <4B27C4C2.8000407@stpeter.im> <223709240912151122x886cac1iee6ab9ba052bda93@mail.gmail.com> <223709240912151252l250cc64cm3ce708f3e8d1726d@mail.gmail.com> <4B27FA2A.4040208@stpeter.im> <223709240912151617x5790449eu597d0f67ae573591@mail.gmail.com> In-Reply-To: <223709240912151617x5790449eu597d0f67ae573591@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030207010905090709010604" Cc: xmpp@ietf.org Subject: Re: [xmpp] RFC 3920bis and IDNA2008 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, 16 Dec 2009 02:45:11 -0000 This is a cryptographically signed message in MIME format. --------------ms030207010905090709010604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/15/09 5:17 PM, Bernard Aboba wrote: > > Agreed. However, the fact that IDNA is moving away from the stringprep > model might give us pause. There are important differences between > domain names and usernames (localpart) or device identifiers > (resourcepart), but I think the IDNA2008 work might lead us to at least > question some of our assumptions. Perhaps we'll draw the same conclusion > we drew before, but it doesn't hurt to think about it a bit more. > > > Indeed, the move away from the stringprep model does raise a lot of > questions -- after all, Appendix A (Nodeprep) and Appendix B > (Resourceprep) both represent stringprep profiles. In those Appendices > we see some of the same issues that arose with IDNA2003 (Unicode version > independence, mapping, potential bidi issues, etc.). > > Unfortunately, an obvious path forward wasn't evident to me. Even given > the pending completion of work on IDNA2008, it seems like some very > substantial effort might be required. For example, the amount of work > required to restructure the IDNA2003 document set (even setting aside > documents such as [IDNA2008-Tables] and [IDNA2008-Bidi]) was very > substantial. Indeed. You can see why we've been avoiding the issue. :) > Is this something that could be helped by a bar/real Stringprep-bis BOF > in Annaheim? My sense is that we'll have a real BoF about this in Anaheim, where by "we" I mean IETF participants who know and care about this topic. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030207010905090709010604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNjAyNDQ1NFowIwYJKoZIhvcNAQkEMRYEFEsTo9G3v5IcRJMKPyJp sy8h9M0DMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAGfjWU7pW6/thbnvh6yKsrnHO6YlqmWmp4yMd/oFh gBuxK4Db8CVJbQsSLA6PGnMz8Wgv7z7F+RwDaxrvuyc8Xv0M/24S50V2icEMhnM8Mxi1B9tS ewkybit0ayUIW+aSb+h4KENi8mJzgpkNZRuce7e7l3qPIBy94SX1X0iRxd+VWnsRfzkxLYAk Qk6aH1I/5Z9U20V54nKVGWH7M6f69hOox4o235P0HezzjZmAIoCc2rYH6TkoT6Rc7vnZGNct vQsooecuApeYsAlR4bijT9N+bMq1SpUnVJS6QU0swg+SQV2SG95ltoz2C+k42djW8bw+Vyvl d1Y78e28eRKdmgAAAAAAAA== --------------ms030207010905090709010604-- From mwild1@gmail.com Wed Dec 16 09:04: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 6C3F33A6A0B for ; Wed, 16 Dec 2009 09:04:30 -0800 (PST) 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 i9sAi8oDdhqE for ; Wed, 16 Dec 2009 09:04:29 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id A3F383A6A1A for ; Wed, 16 Dec 2009 09:04:28 -0800 (PST) Received: by bwz23 with SMTP id 23so919005bwz.29 for ; Wed, 16 Dec 2009 09:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=LiBSSWaUqAGHxC2121vZ/6cT45nH8pdOLqQ9mMX1KVg=; b=fVRyaQ/scK4SPMkdD06uy96gznYt9o4tCHLEfPCPLLzGOPFbNEoxZdLz1L2p9LvxcE EfwSCJYj7EycUXXmURRbAtMUKpIM9uOdAowEzSFhF6YbTQqwzFXN3euk6DY1A76728aN jV3VptXWqnB35G9amDPpqCJH+Wdq9pInNhC5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=QZLetXZWDQHjshG7ctjXANjpyLMt67S1GuT0q1g7SFKAfjs61S3WEVq3VRGTmunjY0 SLKNpCXoTSTTX78VuYEEgpkoofT/ab1+Xd8D8L1qmZTqwYrbqP3v4icNLda3Vk7pXm4V FmEgO+lwDjDJIdt60zN8R68ULJOFVgjDECICg= MIME-Version: 1.0 Received: by 10.204.154.213 with SMTP id p21mr640626bkw.163.1260983050786; Wed, 16 Dec 2009 09:04:10 -0800 (PST) From: Matthew Wild Date: Wed, 16 Dec 2009 17:03:50 +0000 Message-ID: <4db9cacb0912160903v46d1ffa6u245200717529ea25@mail.gmail.com> To: XMPP Working Group Content-Type: text/plain; charset=UTF-8 Subject: [xmpp] Client handling of stanzas with no 'from' attribute 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, 16 Dec 2009 17:04:30 -0000 Hi, This issue seems pretty clear-cut to me, but there seems to be some dispute over the specs, which I'm hoping we can resolve. The short backstory is that some of Prosody's users also use Process One's "OneTeam" client for the iPhone, but they are finding that they can't view avatars, either their own or of their contacts (thread: http://www.process-one.net/en/forum/viewthread/275/ ). It resulted in Prosody being blamed for the bug, and accused of not being XMPP compliant: http://www.process-one.net/en/forum/viewreply/1050/ This is apparently because it doesn't stamp the 'from' attribute on stanzas that are handled by the server on behalf of a user, such as, say... requesting one's own vcard. OneTeam not handling these stanzas has previously been filed as a bug here, which was argued against: https://support.process-one.net/browse/OTIP-135 The relevant part of the specifications appears to be 3920bis-04, section 9.1.2.1 point 3 ( http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-04#section-9.1.2.1 ) which says quite clearly (in my opinion): When the server generates a stanza from the server for delivery to the client on behalf of the account of the connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (a) not include a 'from' attribute or (b) include a 'from' attribute whose value is the account's bare JID (). Prosody opts for (a). Am I the one going mad here? :) Second opinions appreciated, Matthew From nverite.p1@gmail.com Wed Dec 16 09:20: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 078323A696B for ; Wed, 16 Dec 2009 09:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NxuRjA6nWkkF for ; Wed, 16 Dec 2009 09:20:16 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id A34693A6A10 for ; Wed, 16 Dec 2009 09:20:07 -0800 (PST) Received: by fxm7 with SMTP id 7so1157714fxm.29 for ; Wed, 16 Dec 2009 09:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=JPbcTvQU7eVnct8fS22qqcUw7SMOpJWos5ey30jWFnk=; b=tJ3cixjmwFAa8DgOdIWll9UMmoKdSxFFzJqCRvOswCODhrlHiUnKHFxLf3DuD0Giix UWO9VN31LGpjbmzzuzZVqjpVxPXJN3z0E8INZaw2AOcMEjRnqSoGp274tJGYVaJgUAVH zlL5ThnXbR6/JLaLoSxPdb2aPZNKA9Ehv9p1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=DkrUgdmYMcx6nLoZ/SQ6MDxgYM5zE4C/xmkIj+OxJN6odzxi9grBN2ShJV9P97od06 MCxmXnMn7sEAB/o/++tT/dPpqa//q4w2PNA+orlIeYEuTTApg1ZvGD9hEIKDxT7g7P1n wp5i54pMSowjYzAa/A6mUR72hkbwci0FyEMio= MIME-Version: 1.0 Sender: nverite.p1@gmail.com Received: by 10.239.162.129 with SMTP id l1mr106393hbd.201.1260983989155; Wed, 16 Dec 2009 09:19:49 -0800 (PST) In-Reply-To: <4db9cacb0912160903v46d1ffa6u245200717529ea25@mail.gmail.com> References: <4db9cacb0912160903v46d1ffa6u245200717529ea25@mail.gmail.com> From: =?ISO-8859-1?Q?Nicolas_V=E9rit=E9?= Date: Wed, 16 Dec 2009 18:19:29 +0100 X-Google-Sender-Auth: 651dce15d21f4f98 Message-ID: <984759bb0912160919l2a12550er2113517fcf544f5@mail.gmail.com> To: Matthew Wild Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: XMPP Working Group Subject: Re: [xmpp] Client handling of stanzas with no 'from' attribute 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, 16 Dec 2009 17:20:18 -0000 (Let alone the way Maranda is aggressive, but Matt you could have contacted us directly to resolve that issue between us silently) Your are pointing to the RFCbis, which is not accepted yet. In the RFC3920, accepted and widely deployed: =3D=3D When a server receives an XML stanza within the context of an authenticated stream qualified by the 'jabber:client' namespace, it MUST do one of the following: 1. validate that the value of the 'from' attribute provided by the client is that of a connected resource for the associated entity 2. add a 'from' address to the stanza whose value is the bare JID () or the full JID () determined by the server for the connected resource that generated the stanza (see Determination of Addresses (Determination of Addresses)) [...] When a server generates a stanza from the server itself for delivery to a connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (1) not include a 'from' attribute or (2) include a 'from' attribute whose value is the account's bare JID () or client's full JID (). A server MUST NOT send to the client a stanza without a 'from' attribute if the stanza was not generated by the server itself. [...] When a client receives a stanza that does not include a 'from' attribute, it MUST assume that the stanza is from the server to which the client is connected. =3D=3D Whatever, this is fixed in the code, and will be sent to the AppStore, and this will be available... who knows when? On Wed, Dec 16, 2009 at 18:03, Matthew Wild wrote: > Hi, > > This issue seems pretty clear-cut to me, but there seems to be some > dispute over the specs, which I'm hoping we can resolve. > > The short backstory is that some of Prosody's users also use Process > One's "OneTeam" client for the iPhone, but they are finding that they > can't view avatars, either their own or of their contacts (thread: > http://www.process-one.net/en/forum/viewthread/275/ ). > > It resulted in Prosody being blamed for the bug, and accused of not > being XMPP compliant: > http://www.process-one.net/en/forum/viewreply/1050/ > > This is apparently because it doesn't stamp the 'from' attribute on > stanzas that are handled by the server on behalf of a user, such as, > say... requesting one's own vcard. > > OneTeam not handling these stanzas has previously been filed as a bug > here, which was argued against: > https://support.process-one.net/browse/OTIP-135 > > The relevant part of the specifications appears to be 3920bis-04, > section 9.1.2.1 point 3 ( > http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-04#section-9.1.2.1 > ) which says quite clearly (in my opinion): > > When the server generates a stanza from the server for delivery > =A0 =A0 =A0 to the client on behalf of the account of the connected clien= t > =A0 =A0 =A0 (e.g., in the context of data storage services provided by th= e > =A0 =A0 =A0 server on behalf of the client), the stanza MUST either (a) n= ot > =A0 =A0 =A0 include a 'from' attribute or (b) include a 'from' attribute > =A0 =A0 =A0 whose value is the account's bare JID (). > > Prosody opts for (a). Am I the one going mad here? :) > > Second opinions appreciated, > Matthew > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --=20 Nicolas V=E9rit=E9 - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04 From mwild1@gmail.com Wed Dec 16 09:33: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 363A03A688B for ; Wed, 16 Dec 2009 09:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.315, 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 1T+ZsOElblHJ for ; Wed, 16 Dec 2009 09:33:08 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 3CDAF3A682C for ; Wed, 16 Dec 2009 09:33:08 -0800 (PST) Received: by bwz23 with SMTP id 23so949819bwz.29 for ; Wed, 16 Dec 2009 09:32:49 -0800 (PST) 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=hhMpG2pHg63PYZ/r6/p8cAqPhoae38tvsokPFNXuYto=; b=HyXQszozWiJjxVW10Lfp1Nump9nT6YFSCLEiZcPWJbIH5YApxYwsfUJlPldDVd4wyi myjeYsJoGpuIyFvXpVDGGQKVXEWB/AFPewC52uoMY6xuwA59yjHE5XPBMpVcfpiHLD0p OJsE1lTpXDmpB9yZEcwhkLUHjLcZecHbG1xKQ= 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=v8QvIuf80ZpqZrpyBP9N8qL7vnH6jjhfXlCJwNrzmf9l6It7nSx3t8Nf3JKslhH3vt HV80hrRZeXH/70mV3qXreE1W8lECadQnFXdwLNfvanaqeXgbP/O8miMdRp4FTU042eSN p8w7sH4RNpz9tmBAUTqyhEEok6BESIfuYpV4s= MIME-Version: 1.0 Received: by 10.204.20.143 with SMTP id f15mr706175bkb.49.1260984769134; Wed, 16 Dec 2009 09:32:49 -0800 (PST) In-Reply-To: <984759bb0912160919l2a12550er2113517fcf544f5@mail.gmail.com> References: <4db9cacb0912160903v46d1ffa6u245200717529ea25@mail.gmail.com> <984759bb0912160919l2a12550er2113517fcf544f5@mail.gmail.com> From: Matthew Wild Date: Wed, 16 Dec 2009 17:32:29 +0000 Message-ID: <4db9cacb0912160932s62ae72e0x4395d05ab8ab8964@mail.gmail.com> To: =?UTF-8?B?Tmljb2xhcyBWw6lyaXTDqQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: XMPP Working Group Subject: Re: [xmpp] Client handling of stanzas with no 'from' attribute 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, 16 Dec 2009 17:33:09 -0000 2009/12/16 Nicolas V=C3=A9rit=C3=A9 : > (Let alone the way Maranda is aggressive, but Matt you could have > contacted us directly to resolve that issue between us silently) > Hmm, why silently? The more opinions the better, we clearly disagree and between that thread and the bug report, P1 made clear its stance. This is an open protocol and open software, let's develop and improve it, openly :) > Your are pointing to the RFCbis, which is not accepted yet. > > In the RFC3920, accepted and widely deployed: > > =3D=3D > > When a server generates a stanza from the server itself for delivery > to a connected client (e.g., in the context of data storage services > provided by the server on behalf of the client), the stanza MUST > either (1) not include a 'from' attribute or (2) include a 'from' > attribute whose value is the account's bare JID () or > client's full JID (). A server MUST NOT send to > the client a stanza without a 'from' attribute if the stanza was not > generated by the server itself. > > When a client receives a stanza that does not include a 'from' > attribute, it MUST assume that the stanza is from the server to which > the client is connected. > > =3D=3D Ok, so your point is... it says exactly the same. So I guess you're saying you agree with my interpretation of the specs, and that what Prosody is doing is valid XMPP? > > Whatever, this is fixed in the code, and will be sent to the AppStore, > and this will be available... who knows when? > Excellent news, thanks. Matthew From stpeter@stpeter.im Wed Dec 16 19:23:42 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 7B8C53A684F for ; Wed, 16 Dec 2009 19:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 H7To6Rp0Tcqf for ; Wed, 16 Dec 2009 19:23:41 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 78E203A684D for ; Wed, 16 Dec 2009 19:23:41 -0800 (PST) Received: from squire.local (dsl-228-57.dynamic-dsl.frii.net [216.17.228.57]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9D23F40472; Wed, 16 Dec 2009 20:23:26 -0700 (MST) Message-ID: <4B29A420.6020801@stpeter.im> Date: Wed, 16 Dec 2009 20:23:12 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Matthew Wild References: <4db9cacb0912160903v46d1ffa6u245200717529ea25@mail.gmail.com> <984759bb0912160919l2a12550er2113517fcf544f5@mail.gmail.com> <4db9cacb0912160932s62ae72e0x4395d05ab8ab8964@mail.gmail.com> In-Reply-To: <4db9cacb0912160932s62ae72e0x4395d05ab8ab8964@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030907040706090307020000" Cc: XMPP Working Group Subject: Re: [xmpp] Client handling of stanzas with no 'from' attribute 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, 17 Dec 2009 03:23:42 -0000 This is a cryptographically signed message in MIME format. --------------ms030907040706090307020000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/16/09 10:32 AM, Matthew Wild wrote: > 2009/12/16 Nicolas V=C3=A9rit=C3=A9 : >=20 > >=20 >> When a server generates a stanza from the server itself for delivery >> to a connected client (e.g., in the context of data storage services >> provided by the server on behalf of the client), the stanza MUST >> either (1) not include a 'from' attribute or (2) include a 'from' >> attribute whose value is the account's bare JID () or >> client's full JID (). A server MUST NOT send to >> the client a stanza without a 'from' attribute if the stanza was not >> generated by the server itself. >> >=20 >> When a client receives a stanza that does not include a 'from' >> attribute, it MUST assume that the stanza is from the server to which >> the client is connected. >> >> =3D=3D >=20 > Ok, so your point is... it says exactly the same. As far as I can see there's no material difference between RFC 3920 and draft-ietf-xmpp-3920bis on this point. If you think that's wrong, please let me know. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030907040706090307020000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxNzAzMjMxMlowIwYJKoZIhvcNAQkEMRYEFJsW5esyCAv1qYrs708g aOUiToqBMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAkaFiD7rMVzuF6g1NNAg3RKQXZIpF2ZXMBJm3ibvX mcpr+5X55vJTOjtcY9w7cxljz45wVmscSDwhP240xX7CNOXv2MCaTin0qz3CpSKE8d0nuk/V 6zZsRVGElfxn10JNYeHmz4TxltlQoiLgYxwxoxrlY7CdSVYIpvkffLm9+2GGL+nQ5Tlb4sPc SdU2RX3K4cvr2tP98ISQnqfAouxI25QtSW07fzMCeyg5YztO6h81ishuCAtvawoSzXfVymol dSE76hhTw5kTKRMeKALPanbDqXXBQO7wJhrmHxBAHUGVXNhEOUSh8Ei1oSumriLmWVqT/Wpf onFx1LXlhVzeJAAAAAAAAA== --------------ms030907040706090307020000-- From stpeter@stpeter.im Fri Dec 18 11:21:24 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 E488428C110 for ; Fri, 18 Dec 2009 11:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 OhN9pJmZNcqx for ; Fri, 18 Dec 2009 11:21:22 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2CC2828C10E for ; Fri, 18 Dec 2009 11:21:22 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DEDF140332 for ; Fri, 18 Dec 2009 12:21:06 -0700 (MST) Message-ID: <4B2BD621.2030603@stpeter.im> Date: Fri, 18 Dec 2009 12:21:05 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: XMPP References: <4B03252A.5000409@stpeter.im> In-Reply-To: <4B03252A.5000409@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090707000000020901090409" Subject: Re: [xmpp] 3920bis: stream features 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, 18 Dec 2009 19:21:24 -0000 This is a cryptographically signed message in MIME format. --------------ms090707000000020901090409 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/17/09 3:35 PM, Peter Saint-Andre wrote: > At the WG meeting in Hiroshima, I mentioned two open issues regarding > stream features: >=20 > 1. Should we allow the receiving entity to resend stream features at an= y > time during the life of the stream? >=20 > 2. Should we allow the initiating entity to send stream features? I see no demand for either of those features, so I shall consider these two issues closed. > The motivation here is that we might have long-lived streams (especiall= y > for server-to-server federation) and it's possible that a server admin > might enable a feature while such a stream is live. Instead of forcing > the parties to close the stream and start a new stream negotiation, it > might be good to allow them to advertise and then negotiate only the > newly-enabled feature. However, the desire to have this method needs to= > be balanced against complexity (perhaps it's really not a big deal to > close the old stream and start a new one). In chatting about this with Jehan Pag=C3=A8s just now, we came to the conclusion that we'll need a new stream error condition to signal that the receiving entity is closing the stream because it has new features to offer or just needs to reset the stream context (this could also be used if certificates have expired or have been revoked during the life of the stream). Therefore I suggest that we add a new stream error , which means "Sorry, there really isn't a problem, but I need to reset the stream, please reconnect if you want to continue communicating with me." I shall adjust some related text in the next version of the spec. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090707000000020901090409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxODE5MjEwNVowIwYJKoZIhvcNAQkEMRYEFAMGHB3az0T12/73BHq0 /UkR3ivjMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJC5jnI0iTTJCgXO/wWnpEVERz8dmbhAUj2CFMj+o UHEfA3VTC+F9/H5yOxo5UrlYjYpp2AuSqaqhl57RxmMPwz6qTYHmaZYMpQbd52YOx/g/NJM0 yk3HvvXSq3b15DcLN9CKsp4XrsAMzBHUPYH2Dj8ofHGifBbmGDrKHUs5kuhxWBxEWsnpVtv6 0wEya1o7REDzKIxyN9hKwJreZwISjH459c+CRV1nvHIK4Z9qxU7fmFPWOLvr8XxUFyDEgw7a EbXKwDaaX4B0hYtJxEs9yjZM6I1suIeRbPon/d/FJvSyMIMyGIY4BkouN+n1eEHDuQiMvIpH e7NCUIo86uPGxAAAAAAAAA== --------------ms090707000000020901090409-- From stpeter@stpeter.im Fri Dec 18 15:49: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 572EB3A69C1 for ; Fri, 18 Dec 2009 15:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 SpctpNrzNISa for ; Fri, 18 Dec 2009 15:49:26 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0A42A3A69D9 for ; Fri, 18 Dec 2009 15:49:26 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 705D140332 for ; Fri, 18 Dec 2009 16:49:10 -0700 (MST) Message-ID: <4B2C14F5.2070408@stpeter.im> Date: Fri, 18 Dec 2009 16:49:09 -0700 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: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040504010106060503040800" Subject: [xmpp] 3920bis: authentication identity 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, 18 Dec 2009 23:49:27 -0000 This is a cryptographically signed message in MIME format. --------------ms040504010106060503040800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit RFC 3920 does not specify whether the authentication identity in XMPP's use of SASL is localpart or localpart@domain.tld. Someone reported to me earlier today that this has been interpreted differently by different XMPP software implementations. Both RFC 3920 and draft-ietf-xmpp-3920bis have examples only of localpart, however it is not clearly specified in the text -- and in the case of a server that provides virtual hosting one could argue that the authentication identity should be the bare JID localpart@domain.tld instead of just localpart. IMHO we need to clarify this in draft-ietf-xmpp-3920bis. The use of localpart instead of localpart@domain.tld seems to be consistent with the following SASL mechanisms: 1. DIGEST-MD5 (RFC 2831), where the field "username" is described as "the user's name in the specified realm". 2. CRAM-MD5 (draft-ietf-sasl-crammd5), which also specifies a "username" field. 3. SCRAM (draft-ietf-sasl-scram), which states that field "n" is "the name of the user whose password is used for authentication". The use of localpart@domain.tld seems to be consistent with the following SASL mechanism: 4. EXTERNAL (RFC 4422 and XEP-0178) given that id-on-xmppAddr in a client certificate is supposed to be a bare JID. By contrast, the SASL PLAIN mechanism (RFC 4616) is ambiguous, because the field "authcid" is described as "free-form" and we never clarified this in RFC 3920. The core SASL spec (RFC 4422) states that authentication identities are "mechanism specific" and also says: However, the precise form(s) of the authentication identities (used within the server in its verifications, or otherwise) and the precise form(s) of the authorization identities (used in making authorization decisions, or otherwise) are beyond the scope of SASL and this specification. In some circumstances, the precise identity forms used in some context outside of the SASL exchange may be dictated by other specifications. For instance, an identity assumption authorization (proxy authorization) policy specification may dictate how authentication and authorization identities are represented in policy statements. Some would argue that the exact domain name could be encapsulated in the "realm" but not all SASL mechanisms use "realm" (e.g., it is not part of PLAIN or SCRAM), so we can't depend on that. Another approach would be to take the domain from the 'to' address of the initial stream header that the server receives from the client, but that strikes me as a bit messy, especially in the case where the stream header is sent over an unencrypted stream. A third approach would be to say that the "username" in XMPP's use of SASL is always a bare JID. I think I would prefer that because we can make it consistent across all SASL mechanisms, but in practice many clients are probably sending a localpart only because that's what the examples show in RFC 3920 and draft-ietf-xmpp-3920bis. Feedback is welcome. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms040504010106060503040800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxODIzNDkwOVowIwYJKoZIhvcNAQkEMRYEFLStqw08rALNqPU7bNLb SYxDJ4UbMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJy49Efr0itN7sPuQXRSf70DJw9w2XWBHl6X7aKLB YW92ez1yeGudE6vrmRNIjoRupRk/71GbVaSkBxXeVHc9HmDJSLPaVQ3FUpj2oAf5M/AouD0B RILH2oPGrY8GZSCeMdtXAdZss6n3bV/yO1bAQbAxLyzhybqzO85MopcouSZSZ1LzoEi0PNO/ BZpYugMDSQRucGItg5aBMv7/QYFIuX2VNS6/j5NSs4IJ5MVykxpA+I2guj5ZWBkFGtKk5K1/ KVkAlWGhuPfYeSobi/gcPSyB+K7ONGhdxz8EypOs3LqVnvBwpMdsQZA4duzahAlkMZy9qg6k pSLfvBujV4uOoQAAAAAAAA== --------------ms040504010106060503040800-- From stpeter@stpeter.im Fri Dec 18 16:03: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 ACDCF3A68B7 for ; Fri, 18 Dec 2009 16:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 7rRKI5p8yYy0 for ; Fri, 18 Dec 2009 16:03:14 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AAA3F3A682F for ; Fri, 18 Dec 2009 16:03:14 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8BC3B40332 for ; Fri, 18 Dec 2009 17:02:59 -0700 (MST) Message-ID: <4B2C1832.3020100@stpeter.im> Date: Fri, 18 Dec 2009 17:02:58 -0700 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: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010009010700050300030408" Subject: [xmpp] [Fwd: Re: [TLS] Summarizing identity change discussion so far] 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, 19 Dec 2009 00:03:15 -0000 This is a cryptographically signed message in MIME format. --------------ms010009010700050300030408 Content-Type: multipart/mixed; boundary="------------080603080507050200040105" This is a multi-part message in MIME format. --------------080603080507050200040105 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI from the TLS list. I think we'll need to add some text about identity changes to section 14.2.2.3 of draft-ietf-xmpp-3920bis. --stpeter -------- Original Message -------- Subject: Re: [TLS] Summarizing identity change discussion so far Date: Thu, 17 Dec 2009 19:54:22 -0700 From: Peter Saint-Andre To: mrex@sap.com CC: tls@ietf.org References: <200912172347.nBHNlT3s026032@fs4113.wdf.sap.corp> On 12/17/09 4:47 PM, Martin Rex wrote: > If a design expects certificate renewal to be necessary > (either short lived-certs or long-lived connections) then it is > imperative that the application performs a full re-authentication > when the identity changes during renegotiation. Agreed. FWIW, our text about this in draft-ietf-xmpp-3920bis currently reads as follows (this does not yet talk about identity changes, so we'll need to address that case as well -- e.g., the certificate might have been replaced by a new one before the old one expired, but the data in the cert might be different): ### 14.2.2.3. Checking of Certificates in Long-Lived Streams Because XMPP uses long-lived XML streams, it is possible that a certificate presented during stream negotiation might expire or be revoked while the stream is still live (this is especially relevant in the context of server-to-server streams). Therefore, each party to a long-lived stream SHOULD: 1. Cache the expiration date of the certificate presented by the other party and any certificates on which that certificate depends (such as a root or intermediate certificate for a certification authority), and terminate the stream when any such certificate expires. 2. Periodically query the Online Certificate Status Protocol [OCSP] responder listed in the Authority Information Access (AIA) extension of the certificate presented by the other party and any certificates on which that certificate depends (such as a root or intermediate certificate for a certification authority), and terminate the stream if any such certificate has been revoked. ### --------------080603080507050200040105 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1h aWxpbmcgbGlzdApUTFNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHMKCg== --------------080603080507050200040105-- --------------ms010009010700050300030408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIxOTAwMDI1OFowIwYJKoZIhvcNAQkEMRYEFM0bskKZ9KJUSW8b5iww Q84abX1dMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAfW4XdQM9a1pLAjVbRPoPwlpvg7r8OwBkowYNHqnB KLb5ZVDuVBNUPNBn5zHxbCfsiBOW/PIWMKZgACYQDC3bwnBKBDQaDwq7/GoWQL9gT6FL0Iu/ 7bexHHge2+wzW3ZMdzesYfE28XzBPmPWm0rVXjR2Agm0MdeUizlr6vIvkJrhWXR8QSjg3u7U 8nf83K9fMrJbwaFJBUh+7t0HNbagBWvQWYcJWDr/w015XItOSGuuIjf3zC3ogdnhnfqlGEzA x+yHEUfZfCSwsO5jWz3IVue5dvEdBPa9EYgVtZF1fv3DBs18V2PQNEn9fa+D3hQt4+a5x4NW JeibqXPeUDTdWAAAAAAAAA== --------------ms010009010700050300030408--