From stephen.farrell@cs.tcd.ie Tue May 1 00:47:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE8121F86CA for ; Tue, 1 May 2012 00:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIe+K-Pb8G7B for ; Tue, 1 May 2012 00:47:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18221F86C7 for ; Tue, 1 May 2012 00:47:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2D3251714F9; Tue, 1 May 2012 08:47:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1335858474; bh=hV1NM oiFFXd+s5zQnQHqxT0AGmN1c31SA1OuUh8IerI=; b=BEUCtKBi9iI9ObA2WThRV hcnfvzwDV9ly5+uzqQsKTvWrj920v0YhWKVptR/hNDlJ6KFQLy9AfS1mK4KaOqWs sMTtyyDb2Ist3jW5zasb7FAG4f+Gppxv1UtVRITZ/ECKBtlgtqGhRctg6iTQaDOH Kyf5Cw9/5nqgVSyxbqRu7A+IJ2X0sHTn4EeMnG0NJ/wKsZNMlDD9igFFtNFNM2Rp aXwkDvNt/w0oTy1DrWZvyjNMCGHPPHftVm9kg053YYedMGY/iXr8SHFmRg+VvJgf kZaAf2NWYpWhq4pf5SPWZS2QYUDplAXwAr3wz5fPI+4UFcmcqgAEkprx+SMkBn4e g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id M7nTHCHYyqRa; Tue, 1 May 2012 08:47:54 +0100 (IST) Received: from [10.52.174.216] (mobileinternet4.o2.ie [62.40.32.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C12501714F8; Tue, 1 May 2012 08:47:47 +0100 (IST) References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B176) From: Stephen Farrell Date: Tue, 1 May 2012 08:47:33 +0100 To: "Manger, James H" Cc: Apps Discuss Subject: Re: [apps-discuss] CRC vs check digit in draft-farrell-decade-ni X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 07:47:57 -0000 On 1 May 2012, at 03:17, "Manger, James H" = wrote: > A check digit would be more appropriate than an CRC for the human-readable= format in "Naming Things with Hashes" . The draft c= urrently has an optional 16-bit CRC, represented with 4 hex digits. CRCs are= really designed for detecting bit errors (or bursts of bit errors). Check d= igits, on the other hand, are designed to detect human errors (changing digi= ts, transposing digits etc). 1 or 2 check digits are sufficient, instead of 4= chars for a 16-bit CRC. >=20 > Most check digit algorithms work on decimal digits. This draft needs one f= or a string or at least for hex digits. Perhaps the Luhn mod N algorithm wou= ld be suitable ? Using N=3D= 16 and calculating the checksum over just the hex digits of the hash should w= ork well. Such a checksum doesn't "protect" the algorithm name, but it doesn= 't need to as there are only a handful of valid values anyway. Such a checks= um would also ignore the case of hex digits. It doesn't change if you switch= from an alg name to id (eg "sha-256-120" to "3"). Yeah that sounds good, I'll write up some text for it. Ari's the one who lik= ed the crc but he's on vacation, so might take a few days to resolve. >=20 > P.S. The examples in draft 05 all look correct now. Phew. I ended up adding a target to the Makefile to auto generate em since I= 'd mucked up so much:-) Ta S >=20 > -- > James Manger From julian.reschke@gmx.de Tue May 1 01:10:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856A521F84A2 for ; Tue, 1 May 2012 01:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.339 X-Spam-Level: X-Spam-Status: No, score=-103.339 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Em2TLXeR2h for ; Tue, 1 May 2012 01:10:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1DC2C21F844F for ; Tue, 1 May 2012 01:10:57 -0700 (PDT) Received: (qmail invoked by alias); 01 May 2012 08:10:55 -0000 Received: from p5DD973F3.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.115.243] by mail.gmx.net (mp027) with SMTP; 01 May 2012 10:10:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18wKG8a+nIwIMaLMduMSlWWAxyOLXmwIyaI7LLO17 2CY9KO+w3CP5Gp Message-ID: <4F9F9A8D.8080004@gmx.de> Date: Tue, 01 May 2012 10:10:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [websec] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 08:11:00 -0000 On 2012-05-01 04:55, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Monday, April 30, 2012 10:03 AM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-sec@tools.ietf.org >> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec >> >> On 2012-04-29 09:11, Murray S. Kucherawy wrote: >> > ... >>> Section 6.1.1: I think the "delta-seconds" should be: >>> >>> delta-seconds = 1*DIGIT >>> >>> ; defined in Section 3.3.2 of [RFC2616] ... >> >> That would copy the rule from RFC 2616 "by value". > > Why not just say "delta-seconds is defined in Section 3.3.2 of [RFC2616]" and leave out the restatement of the ABNF? Then it's truly only specified in one place. That's *exactly* what the prose ABNF rule is doing; except that it makes the in-spec ABNF complete. > ... Best regards, Julian From stephen.farrell@cs.tcd.ie Tue May 1 01:46:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCF721F86C9; Tue, 1 May 2012 01:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPXBPPiQ4nK8; Tue, 1 May 2012 01:46:55 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7709921F856C; Tue, 1 May 2012 01:46:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DF4351714F9; Tue, 1 May 2012 09:46:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335862014; bh=5rZc4uaxrqcmIs xeUhnBNw4i3SkvVq0PUVGTsTTVrGg=; b=FLmLOsyxV8N7e2qJ0kg/WmTr4eCThO jyHkjFDeJtcQsQlcbPSArvmIbk/cyTcNfWgmPFLB1oc5MKPURNZROGnLXeezGb25 bJnFqcjONhX46XiIG/jz2gYioK3I5hWEo/djOQlPIBtuek/FrY1Y9RN7xCxNwPoc n3wYsgRLTI2Z5hX61KH+RcFmr0Ckv9w7J61N2Tzw/mb1CJX2LlG7hTd+ikSh0HfX BSne85gmSEUKGqzupclvgLJQIDKlgkP7z3e5OhPQZ4kCDk7rDNZGc4KtwYiMSAA1 w/uFsJtkSnxWtICaqHPd7+/IbFcdl69pGiaHGkUsh+X9syKfnsWyUTfw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id caHBGNFQXWCr; Tue, 1 May 2012 09:46:54 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 49C181714F7; Tue, 1 May 2012 09:46:52 +0100 (IST) Message-ID: <4F9FA2FC.7050402@cs.tcd.ie> Date: Tue, 01 May 2012 09:46:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Ned Freed References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> <01OEY4K69WQE0006TF@mauve.mrochek.com> In-Reply-To: <01OEY4K69WQE0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 08:46:57 -0000 Hi Ned, On 05/01/2012 07:30 AM, Ned Freed wrote: >> On 4/30/12 6:52 PM, Ned Freed wrote: >>> >>>>> Again, I'm not taking any position on the interaction of TLSA records and >>>>> services that use SRV or SRV-like mechanisms. That said, I think most of the >>>>> comments are essentially saying that not discussing how TLSA records would >>>>> interact with such services at all - even if that discussion is simply to say >>>>> that those services need to specify how they are going to use TLSA records - >>>>> is a mistake. And I have to say that is a pretty compelling argument. >>> >>>> Could well be. What changes to the text in 1.3 of -20 do you think >>>> are needed if any? >>> >>>> " Note that this document does not cover how to associate >>>> certificates with domain names for application protocols that depend >>>> on SRV, NAPTR, and similar DNS resource records; it is expected that >>>> later updates to this document might cover methods for making those >>>> associations." >>> >>> Well, to be blunt, I think that by trying to avoid solving the problem now >>> while not giving up control over future solutions this ends up being >>> unacceptable to everyone. >>> >>> What if a service comes along that uses SRV records and wants to specify how >>> TLSA records are used to secure them? According to this text, it can't - the >>> clear implication here is that this has to be done by revising the DANE >>> specification itself. >>> >>> And what about existing services like email where it is arguably the case that >>> simply using TLSA records to secure the A/AAAA targets MX records is >>> sufficient? A very short "secure email transport" specification could >>> be writte that refers to the DANE specification, but this would also seem >>> to forbid that. >>> >>> I would much rather see a note that simply refers to future specification work >>> being needed, not specifically to a DANE revision being needed. > >> I had the same concern but then I realized that "later updates to this >> document might cover methods for making those associations" could be >> construed as referring to add-on documents that would officially update >> the DANE-RFC-to-be, not as saying that such changes would need to be >> made in the single DANEbis document that would cover all possible uses >> of the TLSA RR. > > That doesn't fix the problem. Anything that says "updates RFC FOO" is > effectively the same as a DANEbis spec. What I want is for other specification > to be able define how to use TLSA records to secure protocols that use more > elaborate DNS record mechanisms *without* having to update DANE. So I don't get the sensitivity here at all. There is, afaik, no plan for the DANE WG to be gatekeeper for anything, and nor is there any plan for the DANE WG to have a very long lifetime. I don't think is there a definite need e.g. for something that says how to use DANE with XMPP or SMTP to update the TLSA RFC - that might or might not be needed but we won't know until its being done. Nevertheless, how about if it said: "Note that this document does not cover how to associate certificates with domain names for application protocols that depend on SRV, NAPTR, and similar DNS resource records. It is expected that future documents will cover methods for making those associations. Those documents may or may not need to update this one." As Paul said, I don't think there's any problem if you've a better wording for that, so please do suggest some specific text if the above doesn't work. Cheers, S. From stephen.farrell@cs.tcd.ie Tue May 1 02:14:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB58821F86EE for ; Tue, 1 May 2012 02:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaCPSsepkj8H for ; Tue, 1 May 2012 02:14:09 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D576721F874F for ; Tue, 1 May 2012 02:14:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4BC7F1714F9 for ; Tue, 1 May 2012 10:14:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335863647; bh=Ub1jdutcSlnUbH 0IgLN00O0mq3HvwiSG+kORjNZ/v/k=; b=k15mF+moRT+pR72Ip2Mp5ux/diaOfN ou9nVbUfpe4ieNNyQsJ7Vu2xvjjCVbbX6f3MTmr3h/nw5Rg4hnYktNarkJ65CKQT YmNmC171aA7gi+1PxMZmxiryhAt8Mb+GdjQIM1J7jJzFCy9CP6zgFMBNA71ktNxv 9ZXxqNvhOSoSrKr7ljhGlzkezxguvMPAgp/SlumIRgC6X62z4e/XMnYEZZSJR9DU jdBgYBjJuHYGvnR6C6l3D1ScwdHpKHeqlrY/JX90y2yR5YpJocH5kDR3s03xA0M0 fJfoxMKjyM3b4Bys2nOL2Uar8xcgNs1PauYQScc6mgSDppeZ34kQX5kQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id yIjmHQ6FvdZX for ; Tue, 1 May 2012 10:14:07 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B194E171471 for ; Tue, 1 May 2012 10:14:07 +0100 (IST) Message-ID: <4F9FA95F.1080709@cs.tcd.ie> Date: Tue, 01 May 2012 10:14:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Apps Discuss References: <4F9FA90B.9090607@cs.tcd.ie> In-Reply-To: <4F9FA90B.9090607@cs.tcd.ie> X-Enigmail-Version: 1.4.1 X-Forwarded-Message-Id: <4F9FA90B.9090607@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: [dane] DANE IETF LC state of play X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 09:14:10 -0000 FYI. There's been a bunch of mail on this list about this so here's my summary of the state of play just sent to the DANE list. Please feel free to correct me if I've gotten something wrong. Cheers, S. -------- Original Message -------- Subject: [dane] DANE IETF LC state of play Date: Tue, 01 May 2012 10:12:43 +0100 From: Stephen Farrell To: dane Hi all, Well that's been a busy IETF LC. I think that shows that this is an important spec and the editors and chairs have done a great job so far on handling IETF LC comments, but I think there is a bit more work to do to be sure we're done and we may as well get that done now before the IESG are let loose on it:-) I went through the DANE WG archive of all the IETF LC comments and found the following ones where its not crystal clear from the archive that they're sorted. Notes: a) they might be just fine, e.g. if just one person comments and nobody else thought it important, then doing nothing is probably right. these just weren't clear from the archive so I wanna check; b) I only had time to scan the WG archive, if there are mails that were only to ietf@ietf.org or apps-discsuss that resolved these then I missed them, so just tell me about that, so I'll forward this to the other lists to check as well. So here's the list: 1) Jeff Hodges http://www.ietf.org/mail-archive/web/dane/current/msg04695.html http://www.ietf.org/mail-archive/web/dane/current/msg04713.html I mailed Jeff to see if -20 is ok. Silence can be taken to mean yes I think but since he had a bunch of things its hard to be sure. 2) PSA http://www.ietf.org/mail-archive/web/dane/current/msg04702.html http://www.ietf.org/mail-archive/web/dane/current/msg04790.html There are a few more small things still open in the last mail from earlier today. 3) Dave Cridland http://www.ietf.org/mail-archive/web/dane/current/msg04624.html I think there are still some occurrences of "certificate type" in section 8, (e.g. 3rd para, p18) so those weren't all fixed. I think that's the only remaining thing from Dave's review. 4) John Gilmore, http://www.ietf.org/mail-archive/web/dane/current/msg04635.html A.1 only has CA examples, what about non CA uses? I didn't see any reaction to that and it seems like a fair comment. 5) John Gilmore http://www.ietf.org/mail-archive/web/dane/current/msg04637.html John thinks there's a bias in sections 8/8.1, but I didn't see any reaction to that (other than mine, which just said "please do the right thing, whatever that is") 6) Mark Andrews http://www.ietf.org/mail-archive/web/dane/current/msg04657.html Again, not sure if there was follow-up. 7) PHB http://www.ietf.org/mail-archive/web/dane/current/msg04709.html Don't mandate client security policy (hardfail). I didn't see an obvious conclusion reached to make a change or not make a change. 8) Various on SRV http://www.ietf.org/mail-archive/web/dane/current/msg04793.html I think this might need a tweak to the SRV language in 1.3 (and just suggested one). Cheers, Stephen. _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From ben@velocix.com Mon Apr 30 13:04:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D7D21F866A for ; Mon, 30 Apr 2012 13:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XretJThhQTpT for ; Mon, 30 Apr 2012 13:04:00 -0700 (PDT) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id EB98821F8623 for ; Mon, 30 Apr 2012 13:03:57 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.29]) by EXC00CAM.corp.velocix.com ([172.16.16.130]) with mapi id 14.02.0247.003; Mon, 30 Apr 2012 21:03:56 +0100 From: Ben Niven-Jenkins To: Francois Le Faucheur , "Vijay K. Gurbani" , "draft-ietf-cdni-problem-statement@tools.ietf.org" Thread-Topic: Review of draft-ietf-cdni-problem-statement-04 Thread-Index: AQHNG+cer4GdE7vO4U27vgStEHbNLJar22sAgAgFfAA= Date: Mon, 30 Apr 2012 20:03:55 +0000 Message-ID: In-Reply-To: <8CD8D5FA-CCA8-4A3F-B7C5-62F91B311002@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [86.14.227.47] Content-Type: multipart/mixed; boundary="_002_CBC4A8C0343C5benvelocixcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 01 May 2012 02:28:34 -0700 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-cdni-problem-statement-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 20:04:06 -0000 --_002_CBC4A8C0343C5benvelocixcom_ Content-Type: text/plain; charset="utf-8" Content-ID: <61D6B4A0B94BF14B97FA1EB15E9B18FA@velocix.com> Content-Transfer-Encoding: base64 RnJhbmNvaXMsIFZpamF5LA0KDQpTZWUgYmVsb3cgZm9yIHJlc3BvbnNlcy9jb21tZW50cyBhbmQg c2VlIGF0dGFjaGVkIGZvciB0aGUgY3VycmVudCB3b3JraW5nDQp0ZXh0Lg0KDQpGcmFuY29pcyAt IGxldCBtZSBrbm93IGlmIHlvdSB3YW50IG1lIHRvIHB1Ymxpc2ggLTA1IGZyb20gdGhpcyB3b3Jr aW5nDQp0ZXh0IG9yIG5vdC4NCg0KDQpPbiAyNS8wNC8yMDEyIDE5OjM0LCAiRnJhbmNvaXMgTGUg RmF1Y2hldXIiIDxmbGVmYXVjaEBjaXNjby5jb20+IHdyb3RlOg0KDQo+VmlqYXksIEJlbiwgTmFi aWwsIGFsbCwNCj4NCj5PbiAxNiBBcHIgMjAxMiwgYXQgMTc6NDQsIFZpamF5IEsuIEd1cmJhbmkg d3JvdGU6DQo+DQo+DQo+TWFqb3IgSXNzdWVzOg0KPi0gUzY6IEkgYmVsaWV2ZSB0aGF0IGV4cGFu ZGluZyB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIGVhY2gNCj4gQ0ROSSBpbnRlcmZh Y2Ugd2lsbCBoZWxwIGluIHRoZSBsb25nIHJ1bi4NCj4NCj4NCj4NCj5GTEY6IEJlbG93IGlzIGFu IGVkaXRlZC9leHBhbmRlZCB2ZXJzaW9uIG9mIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0K PnNlY3Rpb24gdGhhdCBpbnRlZ3JhdGVzIFZpamF5J3MgY29tbWVudCBhbmQgYWxzbyBjYXB0dXJl cyBhIGNvdXBsZSBvZg0KPmhpZ2gtbGV2ZWwgcG9pbnRzIGZyb20gdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIHNlY3Rpb24gb2YgdGhlDQo+Y2RuaS1mcmFtZXdvcmsuIENhbiB5b3UgZ3V5cyBy ZXZpZXcgYW5kIHJlZmluZSBpZiBuZWVkZWQ/DQoNCkkgaW5jbHVkZWQgdGhlIG1ham9yaXR5IG9m IHlvdXIgc3VnZ2VzdGVkIHRleHQgdmVyYmF0aW0gYnV0IEkgZGlkIGEgZmV3DQptaW5vciB0d2Vh a3MgbWFpbmx5IGZvciBncmFtbWFyLiBSYXRoZXIgdGhhbiBxdW90ZSB0aGUgd2hvbGUgc2VjdGlv biBoZXJlDQotIHNlZSBhdHRhY2hlZCBmb3IgdGhlIGN1cnJlbnQgd29ya2luZyB0ZXh0IG9mIC0w NSB3aXRoIHRoZSBuZXcgc2VjdXJpdHkNCnNlY3Rpb24uDQoNCj4tIFMxOiBZb3VyIHByb2JsZW0g c3RhdGVtZW50IGVzc2VudGlhbGx5IGlzIGFuIGludGVycGxheSBiZXR3ZWVuDQo+IGZvdXIgbG9n aWNhbCBlbnRpdGllczogZW5kIHVzZXIsIENTUCwgQ0ROLCBhbmQgTlNQLiAgSSB0aGluayB0aGlz DQo+IGludGVycGxheSBuZWVkcyB0byBiZSBsYWlkIG91dCBhIGJpdCBtb3JlIGV4cGxpY2l0bHku ICBJdCBzZWVtcyB0byBtZQ0KPiB0aGF0IHlvdXIgbW9kZWwgaXMgdGhhdCBhIHVzZXIgaXMgc3Vi c2NyaWJlZCB0byBhIENTUC4gICBUaGUgQ1NQIGhhcw0KPiBhcnJhbmdlbWVudHMgd2l0aCB2YXJp b3VzIENETiBwcm92aWRlcnMgdG8gZGlzdHJpYnV0ZSBjb250ZW50LiAgVGhlDQo+IHVzZXIsIGF0 IGEgY2VydGFpbiBwb2ludCBpbiB0aW1lLCBpcyBpbiBhIG5ldHdvcmsgb3duZWQgYnkgYSBOU1Ag dGhhdA0KPiB1c2VzIGEgQ0ROIHRoYXQgZG9lcyBub3QgaGF2ZSByZWNlaXZlIGNvbnRlbnQgZnJv bSBDU1AuICBUaHVzIENTUCBpcw0KPiBhdCBhIGRpc2FkdmFudGFnZSBzaW5jZSBpdCB3aWxsIGhh dmUgdG8gc2VydmUgdGhlIHVzZXIgZnJvbSBhIENETiB0aGF0DQo+IGlzIG5vdCBuZWNlc3Nhcmls eSBjbG9zZSB0byB0aGUgdXNlciwgdGhlcmVieSBpbnRyb2R1Y2luZyBhIHJlZHVjZWQNCj4gcXVh bGl0eSBvZiBleHBlcmllbmNlIGZvciB0aGUgdXNlci4NCj4NCj4gV2hhdCBDRE5JIGRvZXMgaXMg ZW5hYmxlIHRoZSBDU1AgdG8gY29udHJhY3Qgd2l0aCBhbiAiYXV0aG9yaXRhdGl2ZSINCj4gQ0RO IHByb3ZpZGVyIGZvciB0aGUgZGVsaXZlcnkgb2YgY29udGVudCBhbmQgdGhhdCB0aGF0DQo+IGF1 dGhvcml0YXRpdmUgQ0ROIFByb3ZpZGVyIGNvdWxkIGNvbnRyYWN0IHdpdGggb25lIG9yIG1vcmUg ZG93bnN0cmVhbQ0KPiBDRE4gUHJvdmlkZXIocykgdG8gZGlzdHJpYnV0ZSBhbmQgZGVsaXZlciBz b21lIG9yIGFsbCBvZiB0aGUgY29udGVudA0KPiBvbiBiZWhhbGYgb2YgdGhlIGF1dGhvcml0YXRp dmUgQ0ROIFByb3ZpZGVyLiAgQmVjYXVzZSB0aGUgZG93bnN0cmVhbQ0KPiBDRE4gUHJvdmlkZXIo cykgd2lsbCBiZSBjbG9zZXIgdG8gdGhlIHVzZXIsIHRoZSB1c2VyIGlzIHN1YmplY3RlZCB0bw0K PiBhIGJldHRlciB2aWV3aW5nIGV4cGVyaWVuY2UgdGhhbiBoZSBvciBzaGUgd291bGQgYmUgaGFk IHRoZSBjb250ZW50DQo+IGJlZW4gZGVsaXZlcmVkIGZyb20gYSBmYXJ0aGVyIENETi4NCj4NCj4g SSB0aGluayB0aGF0IGxheWluZyBvdXQgdGhlIGludGVycGxheSBiZXR3ZWVuIHRoZSBmb3VyIGVu dGl0aWVzIGluDQo+IHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mIFMxIG1vcmUgZXhwbGljaXRseSBt YXkgcHJvdmlkZSBiZXR0ZXIgY29udGV4dA0KPiB0byB0aGUgcmVhZGVyIHdobyBpcyBub3QgYWxy ZWFkeSB3ZWxsIHZlcnNlZCB3aXRoIENETnMuDQoNClRoaXMgaXMgcXVpdGUgZGlmZmljdWx0IHRv IGRvIGluIGEgZ2VuZXJhbGlzZWQgd2F5IGJlY2F1c2UgdGhlIGludGVycGxheXMNCmNhbiB2YXJ5 IHF1aXRlIGEgbG90LCB0aGlzIGlzIHdoYXQgSSBjYW1lIHVwIHdpdGgsIGRvZXMgaXQgYWRkcmVz cyB5b3VyDQpjb21tZW50Pw0KDQogICBBIHR5cGljYWwgY29udGVudCBkZWxpdmVyeSBzY2VuYXJp byBpbnZvbHZlcyBhbiBFbmQgVXNlciByZXF1ZXN0aW5nIGENCiAgIGdpdmVuIGNvbnRlbnQgaXRl bSBmcm9tIGEgQ29udGVudCBTZXJ2aWNlIFByb3ZpZGVyIChDU1ApIHdobw0KICAgY29udHJhY3Rz IGEgQ0ROIHRvIHBlcmZvcm0gZGVsaXZlcnkgb24gdGhlIGNvbnRlbnQgb24gYmVoYWxmIG9mIHRo ZQ0KICAgQ1NQLiAgQ29udGVudCBkZWxpdmVyZWQgYnkgdGhlIENETiBtYXkgdHJhdmVyc2Ugb25l IG9yIG1vcmUgTlNQDQogICBuZXR3b3JrcyBpbiBvcmRlciB0byByZWFjaCB0aGUgRW5kIFVzZXIu ICBUaGUgQ1NQLCBDRE4gYW5kIE5TUCByb2xlcw0KICAgbWF5IGJlIHBsYXllZCBieSBzZXBhcmF0 ZSBlbnRpdGllcyBvciBhIHNpbmdsZSBlbnRvdHkgbWF5IHBsYXkgbW9yZQ0KICAgdGhhbiBvbmUg cm9sZS4gIEZvciBleGFtcGxlIGFuIE5TUCBtYXkgYWxzbyBoYXZlIGEgQ0ROIHRoYXQgM3JkIHBh cnR5DQogICBDU1BzIGNhbiBjb250cmFjdCBmb3IgdGhlIGRlbGl2ZXJ5IG9mIHRoZWlyIGNvbnRl bnQsIG9yIHRoZSBOU1AgbWF5DQogICBvZmZlciB2aWRlbyBzZXJ2aWNlcyBkaXJlY3RseSB0byB0 aGVpciBzdWJzY3JpYmVycyBhbmQgdGhlcmVmb3JlIGFsc28NCiAgIHBsYXkgdGhlIHJvbGUgb2Yg Q1NQIHdoaWxlIGNvbnRyYWN0aW5nIHRoZSBkZWxpdmVyeSBvZiB0aGUgY29udGVudCB0bw0KICAg YSAzcmQgcGFydHkgQ0ROLiAgRXRjLg0KDQoNCg0KPi0gUzE6IEkgd291bGQgYWR2aXNlIHRvIG9y ZGVyIHRoZSB0ZXJtcyBkZWZpbmVkIGJ5IGFuIGFscGhhYmV0aWNhbA0KPiBvcmRlciAoaWYgcG9z c2libGUpLg0KDQpUaGUgaWRlYSBvZiB0aGUgb3JkZXJpbmcgd2FzIHRoYXQgZm9yd2FyZCByZWZl cmVuY2VzIGFyZSBtaW5pbWlzZWQsIHNvIHRoZQ0KZGVmaW5pdGlvbiBvZiBhIGdpdmVuIHRlcm0g aXMgb25seSBkZXBlbmRlbnQgb24gdGhlIHByZWNlZGluZyBkZWZpbml0aW9ucy4NCkkgc3VnZ2Vz dCB3ZSBsZWF2ZSBpdCB0byB0aGUgUkZDIEVkaXRvciB0byBhbGlnbiB3aXRoIHRoZWlyIHByZWZl cnJlZA0Kb3JkZXJpbmcuDQoNCj4tIFMzLCBsYXN0IHBhcmFncmFwaDogVGhlIHRlcm0gIndoZXJl IHRvIGdvIiBpcyByYXRoZXIgYW1iaWd1b3VzLg0KPiBEbyB5b3UgbWVhbiwgIndoaWNoIHVwc3Ry ZWFtIENETiB0byBhY3F1aXJlIGNvbnRlbnQgZnJvbSI/ICBPcg0KPiBzb21ldGhpbmcgZWxzZT8g IEl0IHdpbGwgaGVscCB0byBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdC4NCg0KUmVwbGFjZWQgd2l0 aCAidGhlIHBhcmFtZXRlcnMgdG8gdXNlIHRvIHJldHJpZXZlIHRoZSBjb250ZW50IGZvciBleGFt cGxlDQp0aGUgSVAgYWRkcmVzcy9ob3N0bmFtZSB0byBjb25uZWN0IHRvLCB3aGF0IHByb3RvY29s IHRvIHVzZSB0byByZXRyaWV2ZQ0KdGhlIGNvbnRlbnQsIGV0Yy4iDQoNCg0KPi0gUzQsIGxhc3Qg cGFyYWdyYXBoOiBpdCBpcyBzdGF0ZWQgdGhhdCAid2UgYXNzdW1lIHRoYXQgdGhpcyBbZGV2ZWxv cGluZw0KPiBhIG5ldyBwcm90b2NvbF0gaXMgdW5uZWNlc3NhcnkiLiAgQmFzZWQgb24gdGhlIGNv bnRlbnRzIG9mIFM0LjEtDQo+IFM0LjQsIEkgYmVsaWV2ZSB5b3UgZG8gbW9yZSB0aGFuICJhc3N1 bWUiLiAgWW91IGNsZWFybHkgZW51bmNpYXRlIGENCj4gbGlzdCBvZiBwcm90b2NvbHMgdGhhdCBj YW4gYmUgdXNlZCBmb3IgdGhlIHZhcmlvdXMgaW50ZXJmYWNlcywgdGh1cw0KPiBwcm92aWRpbmcg YSBmaXJzdCBvcmRlciByZWFzb25pbmcgZm9yIHdoeSBhIG5ldyBwcm90b2NvbCBmb3IgQ0ROSQ0K PiBpcyBub3QgbmVlZGVkLg0KPg0KPiBUaGVyZWZvcmUsIEkgd291bGQgZXhob3J0IHlvdSB0byB1 c2UgYSBzdHJvbmdlciB3b3JkIHRoYW4gImFzc3VtZSI7DQo+IHNvbWV0aGluZyBsaWtlOg0KPg0K PiAgIFNlY29uZGx5LCBhbHRob3VnaCBhIG5ldyBhcHBsaWNhdGlvbiBwcm90b2NvbCBjb3VsZCBi ZSBkZXNpZ25lZA0KPiAgIHNwZWNpZmljYWxseSBmb3IgQ0ROSSwgb3VyIGFuYWx5c2lzIGJlbG93 IHNob3dzIHRoYXQgdGhpcyBpcw0KPiAgIHVubmVjZXNzYXJ5IC4uLg0KDQpEb25lLg0KDQo+LSBT NC4zOiBBcmUgdGhlc2UgImxvZyBsaW5lcyIgb3IgImxvZyByZWNvcmRzIj8gIFByZXN1bWFibHks IG9uZSBvcg0KPiBtb3JlIGxpbmVzIHdpbGwgYWdncmVnYXRlIHRvIG9uZSBsb2cgcmVjb3JkLiAg SXQgc2VlbXMgYXBwcm9wcmlhdGUNCj4gaW4gdGhpcyBkb2N1bWVudCB0byB0YWxrIGFib3V0ICJs b2cgcmVjb3JkcyIgaW5zdGVhZCBvZiAibG9nIGxpbmVzIi4NCj4gVGhlIENETkkgbG9nZ2luZyBp bnRlcmZhY2UgZHJhZnQgY2FuIHRlYXNlIG91dCBtb3JlIHByZWNpc2VseSBob3cNCj4gbWFueSBs aW5lcyBjb21wcmlzZSBhIHJlY29yZCwgZXRjLg0KDQpBZ3JlZWQuIEkndmUgcmVwbGFjZWQgYWxs IGluc3RhbmNlcyBvZiBsb2cgbGluZSB3aXRoIGxvZyByZWNvcmQuDQoNCg0KPiBTZWN1cmUgZnRw IGFuZCBzZWN1cmUgY29weWluZyAoc2NwKSBhcHBlYXJzIHRvIGJlIG1pc3NpbmcgaW4gdGhlIGxp c3QNCj4gb2YgcHJvdG9jb2xzLiAgSSB3b3VsZCBzdXNwZWN0IHRoYXQgc2Z0cCB3b3VsZCBiZSBw cmVmZXJyZWQgb3Zlcg0KPiBub3JtYWwgZnRwLg0KDQpUaGUgbGlzdCB3YXNuJ3QgaW50ZW5kZWQg dG8gYmUgZXhoYXVzdGl2ZSBidXQgSSBhZGRlZCB5b3VyIGV4YW1wbGVzIGluLg0KDQoNCj5OaXRz Og0KPg0KPi0gR2xvYmFsOiBJbiB0aGUgQWJzdHJhY3QgYW5kIFMxLCAiRW5kIFVzZXJzIiBpcyBl bXBsb3llZCBtdWx0aXBsZQ0KPiB0aW1lcy4gIEVuZCBVc2VycyBpcyBkZWZpbmVkIGluIHRoZSBU ZXJtaW5vbG9neSBzZWN0aW9uIGFzIGENCj4gZGVmaW5pdGlvbi4gIEkgd291bGQgcHJvcG9zZSB0 aGF0IGF0dGFjaCB0aGUgYWNyb255bSAiRVUiIG9uDQo+IHRoZSBmaXJzdCBlbmNvdW50ZXIgb2Yg IkVuZCBVc2VyIiBpbiB0aGUgQWJzdHJhY3QgYW5kIFMxLA0KPiBhbmQgZnJvbSB0aGVuIG9uIHNp bXBseSB1c2UgIkVVIi4NCg0KSSBjaGFuZ2VkIGluIHNlY3Rpb24gMS4gSSdsbCBsZWF2ZSB0aGUg YWJzdHJhY3QgdG8gdGhlIFJGQyBFZGl0b3IgYXMgdGhleQ0KaGF2ZSBzb21lIHJ1bGVzIG92ZXIg d2hhdCB0aGV5IGxpa2UgZXhwYW5kZWQvbm90IGV4cGFuZGVkIGluIHRoZSBhYnN0cmFjdA0KdGhh dCBJIGNhbiBuZXZlciByZW1lbWJlci4NCg0KPi0gUzEsIHNlY29uZCBwYXJhZ3JhcGg6ICJhdHRh Y2htZW50IG5ldHdvcmsiIHNvdW5kcyBpbmNvbXBsZXRlLg0KPiBNYXliZSB5b3UgbWVhbnQgImF0 dGFjaG1lbnQgdG8gdGhlIG5ldHdvcmsiPw0KDQpJJ3ZlIGNoYW5nZWQgdG8gInJlZ2FyZGxlc3Mg b2YgdGhhdCBFVSdzIGxvY2F0aW9uIG9yIHRoZSBuZXR3b3JrIHRoZXkgYXJlDQphdHRhY2hlZCB0 byIgZG9lcyB0aGF0IG1ha2UgdGhlIGludGVudCBjbGVhcmVyPw0KDQoNCj4tIFMzOiBzL2V4aXN0 aW5nIHByb3RvY29sczogdGhpcyBpcy9leGlzdGluZyBwcm90b2NvbHM7IHRoaXMgaXMvDQoNCkRv bmUuDQoNCj4NCj4tIFM0LjEsIGxhc3QgcGFyYWdyYXBoOiBNYXkgYmUgZ29vZCB0byBnaXZlIGEg cmVmZXJlbmNlIHRvIEFMVE8uDQoNCkRvbmUuDQoNCkJlbg0KDQo+DQo+VGhhbmtzLA0KPg0KPi0g dmlqYXkNCj4tLSANCj5WaWpheSBLLiBHdXJiYW5pLCBCZWxsIExhYm9yYXRvcmllcywgQWxjYXRl bC1MdWNlbnQNCj4xOTYwIEx1Y2VudCBMYW5lLCBSbS4gOUMtNTMzLCBOYXBlcnZpbGxlLCBJbGxp bm9pcyA2MDU2MyAoVVNBKQ0KPkVtYWlsOiB2a2dAe2JlbGwtbGFicy5jb20sYWNtLm9yZyA8aHR0 cDovL2FjbS5vcmc+fSAvDQo+dmlqYXkuZ3VyYmFuaUBhbGNhdGVsLWx1Y2VudC5jb20NCj5XZWI6 ICAgaHR0cDovL2VjdC5iZWxsLWxhYnMuY29tL3doby92a2cvDQo+DQo+DQo+DQo+DQo+DQo+DQo+ DQo+RnJhbmNvaXMgTGUgRmF1Y2hldXINCj5EaXN0aW5ndWlzaGVkIEVuZ2luZWVyDQo+U2Vydmlj ZSBQcm92aWRlciBWaWRlbyBUZWNobm9sb2d5IEdyb3VwDQo+ZmxlZmF1Y2hAY2lzY28uY29tDQo+ UGhvbmU6ICszMyA0OSA3MjMgMjYxOQ0KPk1vYmlsZTogKzMzIDYgMTkgOTggNTAgOTANCj4NCj4N Cj4NCj5DaXNjbyBTeXN0ZW1zIEZyYW5jZQ0KPkdyZWVuc2lkZQ0KPjQwMCBBdmUgZGUgUm91bWFu aWxsZQ0KPjA2NDEwIFNvcGhpYSBBbnRpcG9saXMNCj5GcmFuY2UNCj5DaXNjby5jb20gPGh0dHA6 Ly93d3cuY2lzY28uY29tPg0KPg0KPg0KPiANCj4NCj4gVGhpbmsgYmVmb3JlIHlvdSBwcmludC4N Cj5UaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRl cmlhbCBmb3IgdGhlIHNvbGUNCj51c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJl dmlldywgdXNlLCBkaXN0cmlidXRpb24gb3INCj5kaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj5yZWNpcGllbnQg KG9yIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250 YWN0DQo+dGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2Yg dGhpcyBtZXNzYWdlLg0KPg0KPkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVz cG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlDQo+RGVzbW91bGlucyDigJMgSW1tIEF0 bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMNCj5Nb3VsaW5lYXV4 LCBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJDUyBOYW50ZXJyZSwgRGly ZWN0ZXVyDQo+ZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUuDQo+DQo+ Rm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCj5odHRwOi8vd3d3LmNpc2Nv LmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCj4NCj4N Cj4NCj4NCg0K --_002_CBC4A8C0343C5benvelocixcom_ Content-Type: text/plain; name="draft-ietf-cdni-problem-statement-05-v1.txt" Content-Description: draft-ietf-cdni-problem-statement-05-v1.txt Content-Disposition: attachment; filename="draft-ietf-cdni-problem-statement-05-v1.txt"; size=95204; creation-date="Mon, 30 Apr 2012 20:03:55 GMT"; modification-date="Mon, 30 Apr 2012 20:03:55 GMT" Content-ID: <73B02AF920F45C4B8246F816B9BCF4F0@velocix.com> Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBCLiBOaXZlbi1KZW5raW5zCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFZlbG9jaXggKEFsY2F0ZWwtTHVjZW50KQpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgRi4gTGUgRmF1Y2hldXIKRXhwaXJl czogTm92ZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIENpc2NvCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOLiBCaXRhcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZlcml6b24KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDMwLCAyMDEy CgoKIENvbnRlbnQgRGlzdHJpYnV0aW9uIE5ldHdvcmsgSW50ZXJjb25uZWN0aW9uIChDRE5JKSBQ cm9ibGVtIFN0YXRlbWVudAogICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWNkbmktcHJvYmxl bS1zdGF0ZW1lbnQtMDUKCkFic3RyYWN0CgogICBDb250ZW50IERlbGl2ZXJ5IE5ldHdvcmtzIChD RE5zKSBwcm92aWRlIG51bWVyb3VzIGJlbmVmaXRzOiByZWR1Y2VkCiAgIGRlbGl2ZXJ5IGNvc3Qg Zm9yIGNhY2hlYWJsZSBjb250ZW50LCBpbXByb3ZlZCBxdWFsaXR5IG9mIGV4cGVyaWVuY2UKICAg Zm9yIEVuZCBVc2VycyBhbmQgaW5jcmVhc2VkIHJvYnVzdG5lc3Mgb2YgZGVsaXZlcnkuICBGb3Ig dGhlc2UKICAgcmVhc29ucyB0aGV5IGFyZSBmcmVxdWVudGx5IHVzZWQgZm9yIGxhcmdlLXNjYWxl IGNvbnRlbnQgZGVsaXZlcnkuCiAgIEFzIGEgcmVzdWx0LCBleGlzdGluZyBDRE4gUHJvdmlkZXJz IGFyZSBzY2FsaW5nIHVwIHRoZWlyCiAgIGluZnJhc3RydWN0dXJlIGFuZCBtYW55IE5ldHdvcmsg U2VydmljZSBQcm92aWRlcnMgKE5TUHMpIGFyZQogICBkZXBsb3lpbmcgdGhlaXIgb3duIENETnMu ICBJdCBpcyBnZW5lcmFsbHkgZGVzaXJhYmxlIHRoYXQgYSBnaXZlbgogICBjb250ZW50IGl0ZW0g Y2FuIGJlIGRlbGl2ZXJlZCB0byBhbiBFbmQgVXNlciByZWdhcmRsZXNzIG9mIHRoYXQgRW5kCiAg IFVzZXIncyBsb2NhdGlvbiBvciBhdHRhY2htZW50IG5ldHdvcmsuICBUaGlzIGlzIHRoZSBtb3Rp dmF0aW9uIGZvcgogICBpbnRlcmNvbm5lY3Rpbmcgc3RhbmRhbG9uZSBDRE5zIHNvIHRoZXkgY2Fu IGludGVyb3BlcmF0ZSBhcyBhbiBvcGVuCiAgIGNvbnRlbnQgZGVsaXZlcnkgaW5mcmFzdHJ1Y3R1 cmUgZm9yIHRoZSBlbmQtdG8tZW5kIGRlbGl2ZXJ5IG9mCiAgIGNvbnRlbnQgZnJvbSBDb250ZW50 IFNlcnZpY2UgUHJvdmlkZXJzIChDU1BzKSB0byBFbmQgVXNlcnMuICBIb3dldmVyLAogICBubyBz dGFuZGFyZHMgb3Igb3BlbiBzcGVjaWZpY2F0aW9ucyBjdXJyZW50bHkgZXhpc3QgdG8gZmFjaWxp dGF0ZQogICBzdWNoIENETiBpbnRlcmNvbm5lY3Rpb24uCgogICBUaGUgZ29hbCBvZiB0aGlzIGRv Y3VtZW50IGlzIHRvIG91dGxpbmUgdGhlIHByb2JsZW0gYXJlYSBvZiBDRE4KICAgaW50ZXJjb25u ZWN0aW9uIGZvciB0aGUgSUVURiBDRE5JIChDRE4gSW50ZXJjb25uZWN0aW9uKSB3b3JraW5nCiAg IGdyb3VwLgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJD UCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50 cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3Rl IHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAg RHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8u CgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhp bXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKCgoKTml2ZW4t SmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAg IFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVt IFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBOb3ZlbWJlciAxLCAyMDEyLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJp Z2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl CiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQ cm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNh dGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAg Y2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMg d2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFj dGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVn YWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVz Y3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgIEV4cGlyZXMgTm92ZW1iZXIg MSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgIENETiBJ bnRlcmNvbm5lY3Rpb24gUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgQXByaWwgMjAxMgoKClRhYmxl IG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICAxLjEuICBUZXJtaW5vbG9neSAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgICAgMS4yLiAg Q0ROIEJhY2tncm91bmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMAogICAyLiAgQ0ROIEludGVyY29ubmVjdGlvbiBVc2UgQ2FzZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgMy4gIENETiBJbnRlcmNvbm5lY3Rpb24gTW9kZWwgJiBQ cm9ibGVtIEFyZWEgZm9yIElFVEYgIC4gLiAuIC4gLiAuIDExCiAgIDQuICBTY29waW5nIHRoZSBD RE5JIFByb2JsZW0gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICAg IDQuMS4gIENETkkgUmVxdWVzdCBSb3V0aW5nIEludGVyZmFjZSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTYKICAgICA0LjIuICBDRE5JIE1ldGFkYXRhIEludGVyZmFjZSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgNC4zLiAgQ0ROSSBMb2dnaW5nIEludGVy ZmFjZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAgIDQuNC4gIENE TkkgQ29udHJvbCBJbnRlcmZhY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTcKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE3CiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAgIDYuMS4gIFNlY3VyaXR5IG9m IHRoZSBDRE5JIENvbnRyb2wgaW50ZXJmYWNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKICAgICA2 LjIuICBTZWN1cml0eSBvZiB0aGUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcgSW50ZXJmYWNlIC4gLiAu IC4gLiAuIDE4CiAgICAgNi4zLiAgU2VjdXJpdHkgb2YgdGhlIENETkkgTWV0YWRhdGEgaW50ZXJm YWNlICAuIC4gLiAuIC4gLiAuIC4gLiAxOAogICAgIDYuNC4gIFNlY3VyaXR5IG9mIHRoZSBDRE5J IExvZ2dpbmcgaW50ZXJmYWNlIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkKICAgNy4gIEFja25vd2xl ZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5 CiAgIDguICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxOQogICAgIDguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkKICAgICA4LjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5CiAgIEFwcGVu ZGl4IEEuICBEZXNpZ24gY29uc2lkZXJhdGlvbnMgZm9yIHJlYWxpemluZyB0aGUgQ0ROSQogICAg ICAgICAgICAgICAgSW50ZXJmYWNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjIKICAgICBBLjEuICBDRE5JIFJlcXVlc3QgUm91dGluZyBJbnRlcmZhY2UgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyCiAgICAgQS4yLiAgQ0ROSSBNZXRhZGF0YSBJbnRl cmZhY2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNAogICAgIEEuMy4gIENE TkkgTG9nZ2luZyBJbnRlcmZhY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjUKICAgICBBLjQuICBDRE5JIENvbnRyb2wgSW50ZXJmYWNlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDI2CiAgIEFwcGVuZGl4IEIuICBBZGRpdGlvbmFsIE1hdGVyaWFsIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNgogICAgIEIuMS4gIE5vbi1Hb2FscyBm b3IgSUVURiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjYKICAgICBC LjIuICBSZWxhdGVkIHN0YW5kYXJkaXphdGlvbiBhY3Rpdml0ZXMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDI4CiAgICAgICBCLjIuMS4gIElFVEYgQ0RJIFdvcmtpbmcgR3JvdXAgKENvbmNsdWRl ZCkgLiAuIC4gLiAuIC4gLiAuIC4gLiAyOQogICAgICAgQi4yLjIuICAzR1BQIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjkKICAgICAgIEIuMi4zLiAg SVNPIE1QRUcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMw CiAgICAgICBCLjIuNC4gIEFUSVMgSUlGIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAzMQogICAgICAgQi4yLjUuICBDYWJsZUxhYnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzEKICAgICAgIEIuMi42LiAgRVRTSSBNQ0Qg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMxCiAgICAgICBC LjIuNy4gIEVUU0kgVElTUEFOICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzMQogICAgICAgQi4yLjguICBJVFUtVCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMzIKICAgICAgIEIuMi45LiAgT3BlbiBJUFRWIEZvcnVtIChP SVBGKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyCiAgICAgICBCLjIuMTAuIFRW LUFueXRpbWUgRm9ydW0gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMgog ICAgICAgQi4yLjExLiBTTklBIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzMKICAgICAgIEIuMi4xMi4gU3VtbWFyeSBvZiBleGlzdGluZyBzdGFuYXJk aXphdGlvbiB3b3JrICAuIC4gLiAuIC4gLiAuIDMzCiAgICAgQi4zLiAgUmVsYXRlZCBSZXNlYXJj aCBQcm9qZWN0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNQogICAgICAgQi4z LjEuICBJUlRGIFAyUCBSZXNlYXJjaCBHcm91cCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMzUKICAgICAgIEIuMy4yLiAgT0NFQU4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDM1CiAgICAgICBCLjMuMy4gIEV1cmVzY29tIFAxOTU1IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNQogICAgIEIuNC4gIFJlbGF0aW9u c2hpcCB0byByZWxldmFudCBJRVRGIFdvcmtpbmcgR3JvdXBzIC4gLiAuIC4gLiAuIC4gMzYKCgoK Tml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAg ICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQ cm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgICAgIEIuNC4xLiAgQUxUTyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM2CiAgICAg ICBCLjQuMi4gIERFQ0FERSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzNgogICAgICAgQi40LjMuICBQUFNQIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzgKICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM4CgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAg RXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJu ZXQtRHJhZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBB cHJpbCAyMDEyCgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhlIHZvbHVtZSBvZiB2aWRlbyBhbmQg bXVsdGltZWRpYSBjb250ZW50IGRlbGl2ZXJlZCBvdmVyIHRoZQogICBJbnRlcm5ldCBpcyByYXBp ZGx5IGluY3JlYXNpbmcgYW5kIGV4cGVjdGVkIHRvIGNvbnRpbnVlIGRvaW5nIHNvIGluCiAgIHRo ZSBmdXR1cmUuICBJbiB0aGUgZmFjZSBvZiB0aGlzIGdyb3d0aCwgQ29udGVudCBEZWxpdmVyeSBO ZXR3b3JrcwogICAoQ0ROcykgcHJvdmlkZSBudW1lcm91cyBiZW5lZml0czogcmVkdWNlZCBkZWxp dmVyeSBjb3N0IGZvciBjYWNoZWFibGUKICAgY29udGVudCwgaW1wcm92ZWQgcXVhbGl0eSBvZiBl eHBlcmllbmNlIGZvciBFbmQgVXNlcnMgKEVVcykgYW5kCiAgIGluY3JlYXNlZCByb2J1c3RuZXNz IG9mIGRlbGl2ZXJ5LiAgRm9yIHRoZXNlIHJlYXNvbnMgQ0ROcyBhcmUKICAgZnJlcXVlbnRseSB1 c2VkIGZvciBsYXJnZS1zY2FsZSBjb250ZW50IGRlbGl2ZXJ5LiAgQXMgYSByZXN1bHQsCiAgIGV4 aXN0aW5nIENETiBQcm92aWRlcnMgYXJlIHNjYWxpbmcgdXAgdGhlaXIgaW5mcmFzdHJ1Y3R1cmUg YW5kIG1hbnkKICAgTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVycyAoTlNQcykgYXJlIGRlcGxveWlu ZyB0aGVpciBvd24gQ0ROcy4KCiAgIEEgdHlwaWNhbCBjb250ZW50IGRlbGl2ZXJ5IHNjZW5hcmlv IGludm9sdmVzIGFuIEVVIHJlcXVlc3RpbmcgYSBnaXZlbgogICBjb250ZW50IGl0ZW0gZnJvbSBh IENvbnRlbnQgU2VydmljZSBQcm92aWRlciAoQ1NQKSB3aG8gY29udHJhY3RzIGEKICAgQ0ROIHRv IHBlcmZvcm0gZGVsaXZlcnkgb24gdGhlIGNvbnRlbnQgb24gYmVoYWxmIG9mIHRoZSBDU1AuICBD b250ZW50CiAgIGRlbGl2ZXJlZCBieSB0aGUgQ0ROIG1heSB0cmF2ZXJzZSBvbmUgb3IgbW9yZSBO U1AgbmV0d29ya3MgaW4gb3JkZXIKICAgdG8gcmVhY2ggdGhlIEVVLiAgVGhlIENTUCwgQ0ROIGFu ZCBOU1Agcm9sZXMgbWF5IGJlIHBsYXllZCBieQogICBzZXBhcmF0ZSBlbnRpdGllcyBvciBhIHNp bmdsZSBlbnRpdHkgbWF5IHBsYXkgbW9yZSB0aGFuIG9uZSByb2xlLgogICBGb3IgZXhhbXBsZSBh biBOU1AgbWF5IGFsc28gaGF2ZSBhIENETiB0aGF0IDNyZCBwYXJ0eSBDU1BzIGNhbgogICBjb250 cmFjdCBmb3IgdGhlIGRlbGl2ZXJ5IG9mIHRoZWlyIGNvbnRlbnQsIG9yIHRoZSBOU1AgbWF5IG9m ZmVyCiAgIHZpZGVvIHNlcnZpY2VzIGRpcmVjdGx5IHRvIHRoZWlyIHN1YnNjcmliZXJzIGFuZCB0 aGVyZWZvcmUgYWxzbyBwbGF5CiAgIHRoZSByb2xlIG9mIENTUCB3aGlsZSBjb250cmFjdGluZyB0 aGUgZGVsaXZlcnkgb2YgdGhlIGNvbnRlbnQgdG8gYQogICAzcmQgcGFydHkgQ0ROLiAgRXRjLgoK ICAgSXQgaXMgZ2VuZXJhbGx5IGRlc2lyYWJsZSB0aGF0IGEgZ2l2ZW4gY29udGVudCBpdGVtIGNh biBiZSBkZWxpdmVyZWQKICAgdG8gYW4gRVUgcmVnYXJkbGVzcyBvZiB0aGF0IEVVJ3MgbG9jYXRp b24gb3IgdGhlIG5ldHdvcmsgdGhleSBhcmUKICAgYXR0YWNoZWQgdG8uICBIb3dldmVyLCBhIGdp dmVuIENETiBpbiBjaGFyZ2Ugb2YgZGVsaXZlcmluZyBhIGdpdmVuCiAgIGNvbnRlbnQgbWF5IG5v dCBoYXZlIGEgZm9vdHByaW50IHRoYXQgZXhwYW5kcyBjbG9zZSBlbm91Z2ggdG8gdGhlCiAgIEVV J3MgY3VycmVudCBsb2NhdGlvbiBvciBhdHRhY2htZW50IG5ldHdvcmssIG9yIG1heSBub3QgaGF2 ZSB0aGUKICAgbmVjZXNzYXJ5IHJlc291cmNlcywgdG8gcmVhbGl6ZSB0aGUgdXNlciBleHBlcmll bmNlIGFuZCBjb3N0IGJlbmVmaXQKICAgdGhhdCBhIG1vcmUgZGlzdHJpYnV0ZWQgQ0ROIGluZnJh c3RydWN0dXJlIHdvdWxkIGFsbG93LiAgVGhpcyBpcyB0aGUKICAgbW90aXZhdGlvbiBmb3IgaW50 ZXJjb25uZWN0aW5nIHN0YW5kYWxvbmUgQ0ROcyBzbyB0aGF0IHRoZWlyCiAgIGNvbGxlY3RpdmUg Q0ROIGZvb3RwcmludCBhbmQgcmVzb3VyY2VzIGNhbiBiZSBsZXZlcmFnZWQgZm9yIHRoZSBlbmQt CiAgIHRvLWVuZCBkZWxpdmVyeSBvZiBjb250ZW50IGZyb20gQ1NQcyB0byBFVXMuICBBcyBhbiBl eGFtcGxlLCBhIENTUAogICBjb3VsZCBjb250cmFjdCB3aXRoIGFuICJhdXRob3JpdGF0aXZlIiBD RE4gUHJvdmlkZXIgZm9yIHRoZSBkZWxpdmVyeQogICBvZiBjb250ZW50IGFuZCB0aGF0IGF1dGhv cml0YXRpdmUgQ0ROIFByb3ZpZGVyIGNvdWxkIGNvbnRyYWN0IHdpdGgKICAgb25lIG9yIG1vcmUg ZG93bnN0cmVhbSBDRE4gUHJvdmlkZXIocykgdG8gZGlzdHJpYnV0ZSBhbmQgZGVsaXZlciBzb21l CiAgIG9yIGFsbCBvZiB0aGUgY29udGVudCBvbiBiZWhhbGYgb2YgdGhlIGF1dGhvcml0YXRpdmUg Q0ROIFByb3ZpZGVyLgogICBUaGUgZm9ybWF0aW9uIGFuZCBkZXRhaWxzIG9mIGFueSBidXNpbmVz cyByZWxhdGlvbnNoaXBzIGJldHdlZW4gYSBDU1AKICAgYW5kIGEgQ0ROIFByb3ZpZGVyIGFuZCBi ZXR3ZWVuIG9uZSBDRE4gUHJvdmlkZXIgYW5kIGFub3RoZXIgQ0ROCiAgIFByb3ZpZGVyIGFyZSBv dXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEhvd2V2ZXIsIG5vIHN0YW5kYXJkcyBvcgog ICBvcGVuIHNwZWNpZmljYXRpb25zIGN1cnJlbnRseSBleGlzdCB0byBmYWNpbGl0YXRlIHN1Y2gg Q0ROCiAgIGludGVyY29ubmVjdGlvbi4KCiAgIFRoZSBnb2FsIG9mIHRoaXMgZG9jdW1lbnQgaXMg dG8gb3V0bGluZSB0aGUgcHJvYmxlbSBhcmVhIG9mIENETgogICBpbnRlcmNvbm5lY3Rpb24uICBT ZWN0aW9uIDIgZGlzY3Vzc2VzIHRoZSB1c2UgY2FzZXMgZm9yIENETgogICBpbnRlcmNvbm5lY3Rp b24uICBTZWN0aW9uIDMgcHJlc2VudHMgdGhlIENETkkgbW9kZWwgYW5kIHByb2JsZW0gYXJlYQog ICBiZWluZyBjb25zaWRlcmVkIGJ5IHRoZSBJRVRGLiAgU2VjdGlvbiA0IGRlc2NyaWJlcyBlYWNo IENETkkKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIEludGVyY29u bmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgaW50ZXJmYWNl IGluZGl2aWR1YWxseSBhbmQgaGlnaGxpZ2h0cyBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMK ICAgdGhhdCBjb3VsZCBiZSBjb25zaWRlcmVkIGZvciByZXVzZSBvciBsZXZlcmFnaW5nIHRvIGlt cGxlbWVudCB0aGUKICAgQ0ROSSBpbnRlcmZhY2VzLiAgQXBwZW5kaXggQi4yIGRpc2N1c3NlcyB0 aGUgcmVsZXZhbnQgd29yayBvZiBvdGhlcgogICBzdGFuZGFyZHMgb3JnYW5pemF0aW9ucy4gIEFw cGVuZGl4IEIuNCBkZXNjcmliZXMgdGhlIHJlbGF0aW9uc2hpcHMKICAgYmV0d2VlbiB0aGUgQ0RO SSBwcm9ibGVtIHNwYWNlIGFuZCBvdGhlciByZWxldmFudCBJRVRGIFdvcmtpbmcKICAgR3JvdXBz LgoKMS4xLiAgVGVybWlub2xvZ3kKCiAgIFRoaXMgZG9jdW1lbnQgdXNlcyB0aGUgZm9sbG93aW5n IHRlcm1zOgoKICAgQ29udGVudDogQW55IGZvcm0gb2YgZGlnaXRhbCBkYXRhLiAgT25lIGltcG9y dGFudCBmb3JtIG9mIENvbnRlbnQKICAgd2l0aCBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9uIGRp c3RyaWJ1dGlvbiBhbmQgZGVsaXZlcnkgaXMKICAgY29udGludW91cyBtZWRpYSAoaS5lLiB3aGVy ZSB0aGVyZSBpcyBhIHRpbWluZyByZWxhdGlvbnNoaXAgYmV0d2VlbgogICBzb3VyY2UgYW5kIHNp bmspLgoKICAgTWV0YWRhdGE6IE1ldGFkYXRhIGluIGdlbmVyYWwgaXMgZGF0YSBhYm91dCBkYXRh LgoKICAgQ29udGVudCBNZXRhZGF0YTogVGhpcyBpcyBtZXRhZGF0YSBhYm91dCBDb250ZW50LiAg Q29udGVudCBNZXRhZGF0YQogICBjb21wcmlzZXM6CgogICAxLiAgTWV0YWRhdGEgdGhhdCBpcyBy ZWxldmFudCB0byB0aGUgZGlzdHJpYnV0aW9uIG9mIHRoZSBjb250ZW50IChhbmQKICAgICAgIHRo ZXJlZm9yZSByZWxldmFudCB0byBhIENETiBpbnZvbHZlZCBpbiB0aGUgZGVsaXZlcnkgb2YgdGhh dAogICAgICAgY29udGVudCkuICBXZSByZWZlciB0byB0aGlzIHR5cGUgb2YgbWV0YWRhdGEgYXMg IkNvbnRlbnQKICAgICAgIERpc3RyaWJ1dGlvbiBNZXRhZGF0YSIuICBTZWUgYWxzbyB0aGUgZGVm aW5pdGlvbiBvZiBDb250ZW50CiAgICAgICBEaXN0cmlidXRpb24gTWV0YWRhdGEuCiAgIDIuICBN ZXRhZGF0YSB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWN0dWFsIENvbnRlbnQgb3IgY29u dGVudAogICAgICAgcmVwcmVzZW50YXRpb24sIGFuZCBub3QgZGlyZWN0bHkgcmVsZXZhbnQgdG8g dGhlIGRpc3RyaWJ1dGlvbiBvZgogICAgICAgdGhhdCBDb250ZW50LiAgRm9yIGV4YW1wbGUsIHN1 Y2ggbWV0YWRhdGEgbWF5IGluY2x1ZGUgaW5mb3JtYXRpb24KICAgICAgIHBlcnRhaW5pbmcgdG8g dGhlIENvbnRlbnQncyBnZW5yZSwgY2FzdCwgcmF0aW5nLCBldGMgYXMgd2VsbCBhcwogICAgICAg aW5mb3JtYXRpb24gcGVydGFpbmluZyB0byB0aGUgQ29udGVudCByZXByZXNlbnRhdGlvbidzCiAg ICAgICByZXNvbHV0aW9uLCBhc3BlY3QgcmF0aW8sIGV0Yy4KCiAgIENvbnRlbnQgRGlzdHJpYnV0 aW9uIE1ldGFkYXRhOiBUaGUgc3Vic2V0IG9mIENvbnRlbnQgTWV0YWRhdGEgdGhhdCBpcwogICBy ZWxldmFudCB0byB0aGUgZGlzdHJpYnV0aW9uIG9mIHRoZSBjb250ZW50LiAgVGhpcyBpcyB0aGUg bWV0YWRhdGEKICAgcmVxdWlyZWQgYnkgYSBDRE4gaW4gb3JkZXIgdG8gZW5hYmxlIGFuZCBjb250 cm9sIGNvbnRlbnQgZGlzdHJpYnV0aW9uCiAgIGFuZCBkZWxpdmVyeSBieSB0aGUgQ0ROLiAgSW4g YSBDRE4gSW50ZXJjb25uZWN0aW9uIGVudmlyb25tZW50LCBzb21lCiAgIG9mIHRoZSBDb250ZW50 IERpc3RyaWJ1dGlvbiBNZXRhZGF0YSBtYXkgaGF2ZSBhbiBpbnRyYS1DRE4gc2NvcGUgKGFuZAog ICB0aGVyZWZvcmUgbmVlZCBub3QgYmUgY29tbXVuaWNhdGVkIGJldHdlZW4gQ0ROcyksIHdoaWxl IHNvbWUgb2YgdGhlCiAgIENvbnRlbnQgRGlzdHJpYnV0aW9uIE1ldGFkYXRhIG1heSBoYXZlIGFu IGludGVyLUNETiBzY29wZSAoYW5kCiAgIHRoZXJlZm9yZSBuZWVkcyB0byBiZSBjb21tdW5pY2F0 ZWQgYmV0d2VlbiBDRE5zKS4KCiAgIENETkkgTWV0YWRhdGE6IENvbnRlbnQgRGlzdHJpYnV0aW9u IE1ldGFkYXRhIHdpdGggaW50ZXItQ0ROIHNjb3BlLgogICBGb3IgZXhhbXBsZSwgQ0ROSSBNZXRh ZGF0YSBtYXkgaW5jbHVkZSBnZW8tYmxvY2tpbmcgaW5mb3JtYXRpb24gKGkuZS4KICAgaW5mb3Jt YXRpb24gZGVmaW5pbmcgZ2VvZ3JhcGhpY2FsIGFyZWFzIHdoZXJlIHRoZSBjb250ZW50IGlzIHRv IGJlCiAgIG1hZGUgYXZhaWxhYmxlIG9yIGJsb2NrZWQpLCBhdmFpbGFiaWxpdHkgd2luZG93cyAo aS5lLiBpbmZvcm1hdGlvbgogICBkZWZpbmluZyB0aW1lIHdpbmRvd3MgZHVyaW5nIHdoaWNoIHRo ZSBjb250ZW50IGlzIHRvIGJlIG1hZGUKICAgYXZhaWxhYmxlIG9yIGJsb2NrZWQpIGFuZCBhY2Nl c3MgY29udHJvbCBtZWNoYW5pc21zIHRvIGJlIGVuZm9yY2VkCgoKCk5pdmVuLUplbmtpbnMsIGV0 IGFsLiAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSA2XQoM CkludGVybmV0LURyYWZ0ICAgIENETiBJbnRlcmNvbm5lY3Rpb24gUHJvYmxlbSBTdGF0ZW1lbnQg ICAgICAgQXByaWwgMjAxMgoKCiAgIChlLmcuICBVUkkgc2lnbmF0dXJlIHZhbGlkYXRpb24pLiAg Q0ROSSBNZXRhZGF0YSBtYXkgYWxzbyBpbmNsdWRlCiAgIGluZm9ybWF0aW9uIGFib3V0IGRlc2ly ZWQgZGlzdHJpYnV0aW9uIHBvbGljeSAoZS5nLiBwcmVwb3NpdGlvbmVkIHZzCiAgIGR5bmFtaWMg YWNxdWlzaXRpb24pIGFuZCBhYm91dCB3aGVyZS9ob3cgYSBDRE4gY2FuIGFjcXVpcmUgdGhlCiAg IGNvbnRlbnQuICBDRE5JIE1ldGFkYXRhIG1heSBhbHNvIGluY2x1ZGUgY29udGVudCBtYW5hZ2Vt ZW50CiAgIGluZm9ybWF0aW9uIChlLmcuIHJlcXVlc3QgZm9yIGRlbGV0aW9uIG9mIENvbnRlbnQg ZnJvbSBTdXJyb2dhdGVzKQogICBhY3Jvc3MgaW50ZXJjb25uZWN0ZWQgQ0ROcy4KCiAgIER5bmFt aWMgY29udGVudCBhY3F1aXNpdGlvbjogRHluYW1pYyBjb250ZW50IGFjcXVpc2l0aW9uIGlzIHdo ZXJlIGEKICAgQ0ROIGFjcXVpcmVzIGNvbnRlbnQgZnJvbSB0aGUgY29udGVudCBzb3VyY2UgaW4g cmVzcG9uc2UgdG8gYW4gRW5kCiAgIFVzZXIgcmVxdWVzdGluZyB0aGF0IGNvbnRlbnQgZnJvbSB0 aGUgQ0ROLiAgSW4gdGhlIGNvbnRleHQgb2YgQ0ROCiAgIEludGVyY29ubmVjdGlvbiwgZHluYW1p YyBhY3F1aXNpdGlvbiBtZWFucyB0aGF0IGEgZG93bnN0cmVhbSBDRE4KICAgYWNxdWlyZXMgdGhl IGNvbnRlbnQgZnJvbSBjb250ZW50IHNvdXJjZXMgKGluY2x1ZGluZyB1cHN0cmVhbSBDRE5zKQog ICBhdCBzb21lIHBvaW50IGluIHRpbWUgYWZ0ZXIgYSByZXF1ZXN0IGZvciB0aGF0IGNvbnRlbnQg aXMgZGVsZWdhdGVkCiAgIHRvIHRoZSBkb3duc3RyZWFtIENETiBieSBhbiBVcHN0cmVhbSBDRE4g KGFuZCB0aGF0IHNwZWNpZmljIGNvbnRlbnQKICAgaXMgbm90IHlldCBhdmFpbGFibGUgaW4gdGhl IGRvd25zdHJlYW0gQ0ROKS4KCiAgIER5bmFtaWMgQ0ROSSBtZXRhZGF0YSBhY3F1aXNpdGlvbjog SW4gdGhlIGNvbnRleHQgb2YgQ0ROCiAgIEludGVyY29ubmVjdGlvbiwgZHluYW1pYyBDRE5JIG1l dGFkYXRhIGFjcXVpc2l0aW9uIG1lYW5zIHRoYXQgYQogICBkb3duc3RyZWFtIENETiBhY3F1aXJl cyBDRE5JIG1ldGFkYXRhIGZvciBjb250ZW50IGZyb20gdGhlIHVwc3RyZWFtCiAgIENETiBhdCBz b21lIHBvaW50IGluIHRpbWUgYWZ0ZXIgYSByZXF1ZXN0IGZvciB0aGF0IGNvbnRlbnQgaXMKICAg ZGVsZWdhdGVkIHRvIHRoZSBkb3duc3RyZWFtIENETiBieSBhbiBVcHN0cmVhbSBDRE4gKGFuZCB0 aGF0IHNwZWNpZmljCiAgIENETkkgbWV0YWRhdGEgaXMgbm90IHlldCBhdmFpbGFibGUgaW4gdGhl IGRvd25zdHJlYW0gQ0ROKS4KCiAgIFByZS1wb3NpdGlvbmVkIGNvbnRlbnQgYWNxdWlzaXRpb246 IENvbnRlbnQgUHJlLXBvc2l0aW9uaW5nIGlzIHdoZXJlCiAgIGEgQ0ROIGFjcXVpcmVzIGNvbnRl bnQgZnJvbSB0aGUgY29udGVudCBzb3VyY2UgcHJpb3IgdG8sIG9yCiAgIGluZGVwZW5kZW50bHkg b2YsIGFueSBFbmQgVXNlciByZXF1ZXN0aW5nIHRoYXQgY29udGVudCBmcm9tIHRoZSBDRE4uCiAg IEluIHRoZSBjb250ZXh0IG9mIENETiBpbnRlcmNvbm5lY3Rpb24gdGhlIFVwc3RyZWFtIENETiBp bnN0cnVjdHMgdGhlCiAgIERvd25zdHJlYW0gQ0ROIHRvIGFjcXVpcmUgdGhlIGNvbnRlbnQgZnJv bSBjb250ZW50IHNvdXJjZXMgKGluY2x1ZGluZwogICB1cHN0cmVhbSBDRE5zKSBpbiBhZHZhbmNl IG9mIG9yIGluZGVwZW5kZW50IG9mIGFueSBFbmQgVXNlcgogICByZXF1ZXN0aW5nIGl0LgoKICAg UHJlLXBvc2l0aW9uZWQgQ0ROSSBNZXRhZGF0YSBhY3F1aXNpdGlvbjogSW4gdGhlIGNvbnRleHQg b2YgQ0ROCiAgIEludGVyY29ubmVjdGlvbiwgQ0ROSSBNZXRhZGF0YSBwcmUtcG9zaXRpb25pbmcg aXMgd2hlcmUgdGhlCiAgIERvd25zdHJlYW0gQ0ROIGFjcXVpcmVzIENETkkgbWV0YWRhdGEgZm9y IGNvbnRlbnQgcHJpb3IgdG8gb3IKICAgaW5kZXBlbmRlbnQgb2YgYW55IEVuZCBVc2VyIHJlcXVl c3RpbmcgdGhhdCBjb250ZW50IGZyb20gdGhlCiAgIERvd25zdHJlYW0gQ0ROLgoKICAgRW5kIFVz ZXIgKEVVKTogVGhlICdyZWFsJyB1c2VyIG9mIHRoZSBzeXN0ZW0sIHR5cGljYWxseSBhIGh1bWFu IGJ1dAogICBtYXliZSBzb21lIGNvbWJpbmF0aW9uIG9mIGhhcmR3YXJlIGFuZC9vciBzb2Z0d2Fy ZSBlbXVsYXRpbmcgYSBodW1hbgogICAoZS5nLiBmb3IgYXV0b21hdGVkIHF1YWxpdHkgbW9uaXRv cmluZyBldGMuKQoKICAgVXNlciBBZ2VudCAoVUEpOiBTb2Z0d2FyZSAob3IgYSBjb21iaW5hdGlv biBvZiBoYXJkd2FyZSBhbmQgc29mdHdhcmUpCiAgIHRocm91Z2ggd2hpY2ggdGhlIEVuZCBVc2Vy IGludGVyYWN0cyB3aXRoIGEgQ29udGVudCBTZXJ2aWNlLiAgVGhlCiAgIFVzZXIgQWdlbnQgd2ls bCBjb21tdW5pY2F0ZSB3aXRoIGEgQ29udGVudCBTZXJ2aWNlIGZvciB0aGUgc2VsZWN0aW9uCiAg IG9mIGNvbnRlbnQgYW5kIG9uZSBvciBtb3JlIENETnMgZm9yIHRoZSBkZWxpdmVyeSBvZiB0aGUg Q29udGVudC4KICAgU3VjaCBjb21tdW5pY2F0aW9uIGlzIG5vdCByZXN0cmljdGVkIHRvIEhUVFAg YW5kIG1heSBiZSB2aWEgYSB2YXJpZXR5CiAgIG9mIHByb3RvY29scy4gIEV4YW1wbGVzIG9mIFVz ZXIgQWdlbnRzIChub24tZXhoYXVzdGl2ZSkgYXJlOgogICBCcm93c2VycywgU2V0IFRvcCBCb3hl cyAoU1RCcyksIGRlZGljYXRlZCBjb250ZW50IGFwcGxpY2F0aW9ucyAoZS5nLgoKCgpOaXZlbi1K ZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMTIgICAgICAgICAgICAgICAg W1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4gSW50ZXJjb25uZWN0aW9uIFByb2JsZW0g U3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgogICBtZWRpYSBwbGF5ZXJzKSwgZXRjLgoKICAg TmV0d29yayBTZXJ2aWNlIFByb3ZpZGVyIChOU1ApOiBQcm92aWRlcyBuZXR3b3JrLWJhc2VkIGNv bm5lY3Rpdml0eS8KICAgc2VydmljZXMgdG8gRW5kIFVzZXJzLgoKICAgQ29udGVudCBTZXJ2aWNl IFByb3ZpZGVyIChDU1ApOiBQcm92aWRlcyBhIENvbnRlbnQgU2VydmljZSB0byBFbmQKICAgVXNl cnMgKHdoaWNoIHRoZXkgYWNjZXNzIHZpYSBhIFVzZXIgQWdlbnQpLiAgQSBDU1AgbWF5IG93biB0 aGUKICAgQ29udGVudCBtYWRlIGF2YWlsYWJsZSBhcyBwYXJ0IG9mIHRoZSBDb250ZW50IFNlcnZp Y2UsIG9yIG1heSBsaWNlbnNlCiAgIGNvbnRlbnQgcmlnaHRzIGZyb20gYW5vdGhlciBwYXJ0eS4K CiAgIENvbnRlbnQgU2VydmljZTogVGhlIHNlcnZpY2Ugb2ZmZXJlZCBieSBhIENvbnRlbnQgU2Vy dmljZSBQcm92aWRlci4KICAgVGhlIENvbnRlbnQgU2VydmljZSBlbmNvbXBhc3NlcyB0aGUgY29t cGxldGUgc2VydmljZSB3aGljaCBtYXkgYmUKICAgd2lkZXIgdGhhbiBqdXN0IHByb3ZpZGluZyBh Y2Nlc3MgdG8gaXRlbXMgb2YgQ29udGVudCwgZS5nLiB0aGUKICAgQ29udGVudCBTZXJ2aWNlIGFs c28gaW5jbHVkZXMgYW55IG1pZGRsZXdhcmUsIGtleSBkaXN0cmlidXRpb24sCiAgIHByb2dyYW0g Z3VpZGUsIGV0Yy4gd2hpY2ggbWF5IG5vdCByZXF1aXJlIGFueSBkaXJlY3QgaW50ZXJhY3Rpb24g d2l0aAogICB0aGUgQ0ROLCBvciBDRE5zLCBpbnZvbHZlZCBpbiB0aGUgZGlzdHJpYnV0aW9uIGFu ZCBkZWxpdmVyeSBvZiB0aGUKICAgY29udGVudC4KCiAgIENvbnRlbnQgRGlzdHJpYnV0aW9uIE5l dHdvcmsgKENETikgLyBDb250ZW50IERlbGl2ZXJ5IE5ldHdvcmsgKENETik6CiAgIE5ldHdvcmsg aW5mcmFzdHJ1Y3R1cmUgaW4gd2hpY2ggdGhlIG5ldHdvcmsgZWxlbWVudHMgY29vcGVyYXRlIGF0 CiAgIGxheWVycyA0IHRocm91Z2ggbGF5ZXIgNyBmb3IgbW9yZSBlZmZlY3RpdmUgZGVsaXZlcnkg b2YgQ29udGVudCB0bwogICBVc2VyIEFnZW50cy4gIFR5cGljYWxseSBhIENETiBjb25zaXN0cyBv ZiBhIFJlcXVlc3QgUm91dGluZyBzeXN0ZW0sIGEKICAgRGlzdHJpYnV0aW9uIFN5c3RlbSAodGhh dCBpbmNsdWRlcyBhIHNldCBvZiBTdXJyb2dhdGVzKSwgYSBMb2dnaW5nCiAgIFN5c3RlbSBhbmQg YSBDRE4gY29udHJvbCBzeXN0ZW0uCgogICBDRE4gUHJvdmlkZXI6IFRoZSBzZXJ2aWNlIHByb3Zp ZGVyIHdobyBvcGVyYXRlcyBhIENETiBhbmQgb2ZmZXJzIGEKICAgc2VydmljZSBvZiBjb250ZW50 IGRlbGl2ZXJ5LCB0eXBpY2FsbHkgdXNlZCBieSBhIENvbnRlbnQgU2VydmljZQogICBQcm92aWRl ciBvciBhbm90aGVyIENETiBQcm92aWRlci4gIE5vdGUgdGhhdCBhIGdpdmVuIGVudGl0eSBtYXkK ICAgb3BlcmF0ZSBpbiBtb3JlIHRoYW4gb25lIHJvbGUuICBGb3IgZXhhbXBsZSwgYSBjb21wYW55 IG1heQogICBzaW11bHRhbmVvdXNseSBvcGVyYXRlIGFzIGEgQ29udGVudCBTZXJ2aWNlIFByb3Zp ZGVyLCBhIE5ldHdvcmsKICAgU2VydmljZSBQcm92aWRlciBhbmQgYSBDRE4gUHJvdmlkZXIuCgog ICBDRE4gSW50ZXJjb25uZWN0aW9uIChDRE5JKTogQSByZWxhdGlvbnNoaXAgYmV0d2VlbiBhIHBh aXIgb2YgQ0ROcwogICB0aGF0IGVuYWJsZXMgb25lIENETiB0byBwcm92aWRlIGNvbnRlbnQgZGVs aXZlcnkgc2VydmljZXMgb24gYmVoYWxmCiAgIG9mIGFub3RoZXIgQ0ROLiAgQSBDRE4gSW50ZXJj b25uZWN0aW9uIG1heSBiZSB3aG9sbHkgb3IgcGFydGlhbGx5CiAgIHJlYWxpemVkIHRocm91Z2gg YSBzZXQgb2YgaW50ZXJmYWNlcyBvdmVyIHdoaWNoIGEgcGFpciBvZiBDRE5zCiAgIGNvbW11bmlj YXRlIHdpdGggZWFjaCBvdGhlciBpbiBvcmRlciB0byBhY2hpZXZlIHRoZSBkZWxpdmVyeSBvZgog ICBjb250ZW50IHRvIFVzZXIgQWdlbnRzIGJ5IFN1cnJvZ2F0ZXMgaW4gb25lIENETiAodGhlIGRv d25zdHJlYW0gQ0ROKQogICBvbiBiZWhhbGYgb2YgYW5vdGhlciBDRE4gKHRoZSB1cHN0cmVhbSBD RE4pLgoKICAgQXV0aG9yaXRhdGl2ZSBDRE46IEEgQ0ROIHdoaWNoIGhhcyBhIGRpcmVjdCByZWxh dGlvbnNoaXAgd2l0aCBhIENTUAogICBmb3IgdGhlIGRpc3RyaWJ1dGlvbiAmIGRlbGl2ZXJ5IG9m IHRoYXQgQ1NQJ3MgY29udGVudCBieSB0aGUKICAgYXV0aG9yaXRhdGl2ZSBDRE4gb3IgYnkgZG93 bnN0cmVhbSBDRE5zIG9mIHRoZSBhdXRob3JpdGF0aXZlIENETi4KCiAgIFVwc3RyZWFtIENETjog Rm9yIGEgZ2l2ZW4gRW5kIFVzZXIgcmVxdWVzdCwgdGhlIENETiAod2l0aGluIGEgcGFpciBvZgog ICBkaXJlY3RseSBpbnRlcmNvbm5lY3RlZCBDRE5zKSB0aGF0IHJlZGlyZWN0cyB0aGUgcmVxdWVz dCB0byB0aGUgb3RoZXIKICAgQ0ROLgoKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJl cyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJh ZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAy MDEyCgoKICAgRG93bnN0cmVhbSBDRE46IEZvciBhIGdpdmVuIEVuZCBVc2VyIHJlcXVlc3QsIHRo ZSBDRE4gKHdpdGhpbiBhIHBhaXIKICAgb2YgZGlyZWN0bHkgaW50ZXJjb25uZWN0ZWQgQ0ROcykg dG8gd2hpY2ggdGhlIHJlcXVlc3QgaXMgcmVkaXJlY3RlZAogICBieSB0aGUgb3RoZXIgQ0ROICh0 aGUgVXBzdHJlYW0gQ0ROKS4gIE5vdGUgdGhhdCBpbiB0aGUgY2FzZSBvZgogICBzdWNjZXNzaXZl IHJlZGlyZWN0aW9ucyAoZS5nLiAgQ0ROMS0tPkNETjItLT5DRE4zKSBhIGdpdmVuIENETiAoZS5n LgogICBDRE4yKSBtYXkgYWN0IGFzIHRoZSBEb3duc3RyZWFtIENETiBmb3IgYSByZWRpcmVjdGlv biAoZS5nLgogICBDRE4xLS0+Q0ROMikgYW5kIGFzIHRoZSBVcHN0cmVhbSBDRE4gZm9yIHRoZSBz dWJzZXF1ZW50IHJlZGlyZWN0aW9uCiAgIG9mIHRoZSBzYW1lIHJlcXVlc3QgKGUuZy4gIENETjIt LT5DRE4zKS4KCiAgIE92ZXItdGhlLXRvcCAoT1RUKTogQSBzZXJ2aWNlLCBlLmcuIGNvbnRlbnQg ZGVsaXZlcnkgdXNpbmcgYSBDRE4sCiAgIG9wZXJhdGVkIGJ5IGEgZGlmZmVyZW50IG9wZXJhdG9y IHRoYW4gdGhlIE5TUCB0byB3aGljaCB0aGUgdXNlcnMgb2YKICAgdGhhdCBzZXJ2aWNlIGFyZSBh dHRhY2hlZC4KCiAgIFN1cnJvZ2F0ZTogQSBkZXZpY2UvZnVuY3Rpb24gKG9mdGVuIGNhbGxlZCBh IGNhY2hlKSB0aGF0IGludGVyYWN0cwogICB3aXRoIG90aGVyIGVsZW1lbnRzIG9mIHRoZSBDRE4g Zm9yIHRoZSBjb250cm9sIGFuZCBkaXN0cmlidXRpb24gb2YKICAgQ29udGVudCB3aXRoaW4gdGhl IENETiBhbmQgaW50ZXJhY3RzIHdpdGggVXNlciBBZ2VudHMgZm9yIHRoZQogICBkZWxpdmVyeSBv ZiB0aGUgQ29udGVudC4KCiAgIFJlcXVlc3QgUm91dGluZyBTeXN0ZW06IFRoZSBmdW5jdGlvbiB3 aXRoaW4gYSBDRE4gcmVzcG9uc2libGUgZm9yCiAgIHJlY2VpdmluZyBhIGNvbnRlbnQgcmVxdWVz dCBmcm9tIGEgVXNlciBBZ2VudCwgb2J0YWluaW5nIGFuZAogICBtYWludGFpbmluZyBuZWNlc3Nh cnkgaW5mb3JtYXRpb24gYWJvdXQgYSBzZXQgb2YgY2FuZGlkYXRlIHN1cnJvZ2F0ZXMKICAgb3Ig Y2FuZGlkYXRlIENETnMsIGFuZCBmb3Igc2VsZWN0aW5nIGFuZCByZWRpcmVjdGluZyB0aGUgdXNl ciB0byB0aGUKICAgYXBwcm9wcmlhdGUgc3Vycm9nYXRlIG9yIENETi4gIFRvIGVuYWJsZSBDRE4g SW50ZXJjb25uZWN0aW9uLCB0aGUKICAgUmVxdWVzdCBSb3V0aW5nIFN5c3RlbSBtdXN0IGFsc28g YmUgY2FwYWJsZSBvZiBoYW5kbGluZyBVc2VyIEFnZW50CiAgIGNvbnRlbnQgcmVxdWVzdHMgcGFz c2VkIHRvIGl0IGJ5IGFub3RoZXIgQ0ROLgoKICAgRGlzdHJpYnV0aW9uIFN5c3RlbTogVGhlIGZ1 bmN0aW9uIHdpdGhpbiBhIENETiByZXNwb25zaWJsZSBmb3IKICAgZGlzdHJpYnV0aW5nIENvbnRl bnQgRGlzdHJpYnV0aW9uIE1ldGFkYXRhIGFzIHdlbGwgYXMgdGhlIENvbnRlbnQKICAgaXRzZWxm IGluc2lkZSB0aGUgQ0ROIChlLmcuIGRvd24gdG8gdGhlIHN1cnJvZ2F0ZXMpLgoKICAgRGVsaXZl cnk6IFRoZSBmdW5jdGlvbiB3aXRoaW4gQ0ROIHN1cnJvZ2F0ZXMgcmVzcG9uc2libGUgZm9yCiAg IGRlbGl2ZXJpbmcgYSBwaWVjZSBvZiBjb250ZW50IHRvIHRoZSBVc2VyIEFnZW50LiAgRm9yIGV4 YW1wbGUsCiAgIGRlbGl2ZXJ5IG1heSBiZSBiYXNlZCBvbiBIVFRQIHByb2dyZXNzaXZlIGRvd25s b2FkIG9yIEhUVFAgYWRhcHRpdmUKICAgc3RyZWFtaW5nLgoKICAgTG9nZ2luZyBTeXN0ZW06IFRo ZSBmdW5jdGlvbiB3aXRoaW4gYSBDRE4gcmVzcG9uc2libGUgZm9yIGNvbGxlY3RpbmcKICAgdGhl IG1lYXN1cmVtZW50IGFuZCByZWNvcmRpbmcgb2YgZGlzdHJpYnV0aW9uIGFuZCBkZWxpdmVyeQog ICBhY3Rpdml0aWVzLiAgVGhlIGluZm9ybWF0aW9uIHJlY29yZGVkIGJ5IHRoZSBsb2dnaW5nIHN5 c3RlbSBtYXkgYmUKICAgdXNlZCBmb3IgdmFyaW91cyBwdXJwb3NlcyBpbmNsdWRpbmcgY2hhcmdp bmcgKGUuZy4gb2YgdGhlIENTUCksCiAgIGFuYWx5dGljcyBhbmQgbW9uaXRvcmluZy4KCiAgIENv bnRyb2wgU3lzdGVtOiBUaGUgZnVuY3Rpb24gd2l0aGluIGEgQ0ROIHJlc3BvbnNpYmxlIGZvcgog ICBib290c3RyYXBwaW5nIGFuZCBjb250cm9sbGluZyB0aGUgb3RoZXIgY29tcG9uZW50cyBvZiB0 aGUgQ0ROIGFzIHdlbGwKICAgYXMgZm9yIGhhbmRsaW5nIGludGVyYWN0aW9ucyB3aXRoIGV4dGVy bmFsIHN5c3RlbXMgKGUuZy4gaGFuZGxpbmcKICAgZGVsaXZlcnkgc2VydmljZSBjcmVhdGlvbi91 cGRhdGUvcmVtb3ZhbCByZXF1ZXN0cywgb3Igc3BlY2lmaWMKICAgc2VydmljZSBwcm92aXNpb25p bmcgcmVxdWVzdHMpLgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVt YmVyIDEsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICBD RE4gSW50ZXJjb25uZWN0aW9uIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgox LjIuICBDRE4gQmFja2dyb3VuZAoKICAgUmVhZGVycyBhcmUgYXNzdW1lZCB0byBiZSBmYW1pbGlh ciB3aXRoIHRoZSBhcmNoaXRlY3R1cmUsIGZlYXR1cmVzCiAgIGFuZCBvcGVyYXRpb24gb2YgQ0RO cy4gIEZvciByZWFkZXJzIGxlc3MgZmFtaWxpYXIgd2l0aCB0aGUgb3BlcmF0aW9uCiAgIG9mIENE TnMsIHRoZSBmb2xsb3dpbmcgcmVzb3VyY2VzIG1heSBiZSB1c2VmdWw6CgogICBvICBSRkMgMzA0 MCBbUkZDMzA0MF0gZGVzY3JpYmVzIG1hbnkgb2YgdGhlIGNvbXBvbmVudCB0ZWNobm9sb2dpZXMK ICAgICAgdGhhdCBhcmUgdXNlZCBpbiB0aGUgY29uc3RydWN0aW9uIG9mIGEgQ0ROLgogICBvICBU YXhvbm9teSBbVEFYT05PTVldIGNvbXBhcmVzIHRoZSBhcmNoaXRlY3R1cmUgb2YgYSBudW1iZXIg b2YgQ0ROcy4KICAgbyAgUkZDIDM0NjYgW1JGQzM0NjZdIGFuZCBSRkMgMzU3MCBbUkZDMzU3MF0g YXJlIHRoZSBvdXRwdXQgb2YgdGhlCiAgICAgIElFVEYgQ29udGVudCBEZWxpdmVyeSBJbnRlcm5l dHdvcmtpbmcgKENESSkgd29ya2luZyBncm91cCB3aGljaAogICAgICB3YXMgY2xvc2VkIGluIDIw MDMuCgogICBOb3RlOiBTb21lIG9mIHRoZSB0ZXJtcyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgYXJl IHNpbWlsYXIgdG8gdGVybXMKICAgdXNlZCB0aGUgYWJvdmUgcmVmZXJlbmNlZCBkb2N1bWVudHMu ICBXaGVuIHJlYWRpbmcgdGhpcyBkb2N1bWVudAogICB0ZXJtcyBzaG91bGQgYmUgaW50ZXJwcmV0 ZWQgYXMgaGF2aW5nIHRoZSBkZWZpbml0aW9ucyBwcm92aWRlZCBpbgogICBTZWN0aW9uIDEuMS4K CgoyLiAgQ0ROIEludGVyY29ubmVjdGlvbiBVc2UgQ2FzZXMKCiAgIEFuIGluY3JlYXNpbmcgbnVt YmVyIG9mIE5TUHMgYXJlIGRlcGxveWluZyBDRE5zIGluIG9yZGVyIHRvIGRlYWwKICAgY29zdC1l ZmZlY3RpdmVseSB3aXRoIHRoZSBncm93aW5nIHVzYWdlIG9mIG9uLWRlbWFuZCB2aWRlbyBzZXJ2 aWNlcwogICBhbmQgb3RoZXIgY29udGVudCBkZWxpdmVyeSBhcHBsaWNhdGlvbnMuCgogICBDRE5z IGFsbG93IGNhY2hpbmcgb2YgY29udGVudCBjbG9zZXIgdG8gdGhlIGVkZ2Ugb2YgYSBuZXR3b3Jr IHNvIHRoYXQKICAgYSBnaXZlbiBpdGVtIG9mIGNvbnRlbnQgY2FuIGJlIGRlbGl2ZXJlZCBieSBh IENETiBTdXJyb2dhdGUgKGkuZS4gYQogICBjYWNoZSkgdG8gbXVsdGlwbGUgVXNlciBBZ2VudHMg KGFuZCB0aGVpciBFbmQgVXNlcnMpIHdpdGhvdXQKICAgdHJhbnNpdGluZyBtdWx0aXBsZSB0aW1l cyB0aHJvdWdoIHRoZSBuZXR3b3JrIGNvcmUgKGkuZSBmcm9tIHRoZQogICBjb250ZW50IG9yaWdp biB0byB0aGUgc3Vycm9nYXRlKS4gIFRoaXMgY29udHJpYnV0ZXMgdG8gYmFuZHdpZHRoIGNvc3QK ICAgcmVkdWN0aW9ucyBmb3IgdGhlIE5TUCBhbmQgdG8gaW1wcm92ZWQgcXVhbGl0eSBvZiBleHBl cmllbmNlIGZvciB0aGUKICAgRW5kIFVzZXJzLiAgQ0ROcyBhbHNvIGVuYWJsZSByZXBsaWNhdGlv biBvZiBwb3B1bGFyIGNvbnRlbnQgYWNyb3NzCiAgIG1hbnkgc3Vycm9nYXRlcywgd2hpY2ggZW5h YmxlcyBjb250ZW50IHRvIGJlIHNlcnZlZCB0byBsYXJnZSBudW1iZXJzCiAgIG9mIFVzZXIgQWdl bnRzIGNvbmN1cnJlbnRseS4gIFRoaXMgYWxzbyBoZWxwcyBkZWFsaW5nIHdpdGggc2l0dWF0aW9u cwogICBzdWNoIGFzIGZsYXNoIGNyb3dkcyBhbmQgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrcy4K CiAgIFRoZSBDRE5zIGRlcGxveWVkIGJ5IE5TUHMgYXJlIG5vdCBqdXN0IHJlc3RyaWN0ZWQgdG8g dGhlIGRlbGl2ZXJ5IG9mCiAgIGNvbnRlbnQgdG8gc3VwcG9ydCB0aGUgTmV0d29yayBTZXJ2aWNl IFByb3ZpZGVyJ3Mgb3duICd3YWxsZWQgZ2FyZGVuJwogICBzZXJ2aWNlcywgc3VjaCBhcyBJUCBk ZWxpdmVyeSBvZiB0ZWxldmlzaW9uIHNlcnZpY2VzIHRvIFNldCBUb3AKICAgQm94ZXMsIGJ1dCBh cmUgYWxzbyB1c2VkIGZvciBkZWxpdmVyeSBvZiBjb250ZW50IHRvIG90aGVyIGRldmljZXMKICAg aW5jbHVkaW5nIFBDcywgdGFibGV0cywgbW9iaWxlIHBob25lcyBldGMuCgogICBTb21lIHNlcnZp Y2UgcHJvdmlkZXJzIG9wZXJhdGUgb3ZlciBtdWx0aXBsZSBnZW9ncmFwaGllcyBhbmQgZmVkZXJh dGUKICAgbXVsdGlwbGUgYWZmaWxpYXRlIE5TUHMuICBUaGVzZSBOU1BzIHR5cGljYWxseSBvcGVy YXRlIGluZGVwZW5kZW50CiAgIENETnMuICBBcyB0aGV5IGV2b2x2ZSB0aGVpciBzZXJ2aWNlcyAo ZS5nLiBmb3Igc2VhbWxlc3Mgc3VwcG9ydCBvZgogICBjb250ZW50IHNlcnZpY2VzIHRvIG5vbWFk aWMgdXNlcnMgYWNyb3NzIGFmZmlsaWF0ZSBOU1BzKSB0aGVyZSBpcyBhCiAgIG5lZWQgZm9yIGlu dGVyY29ubmVjdGlvbiBvZiB0aGVzZSBDRE5zLCB0aGF0IHJlcHJlc2VudHMgYSBmaXJzdCB1c2UK ICAgY2FzZSBmb3IgQ0ROSS4gIEhvd2V2ZXIgdGhlcmUgYXJlIG5vIG9wZW4gc3BlY2lmaWNhdGlv bnMsIG5vciBjb21tb24KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJl ciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0RO IEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAg YmVzdCBwcmFjdGljZXMsIGRlZmluaW5nIGhvdyB0byBhY2hpZXZlIHN1Y2ggQ0ROIGludGVyY29u bmVjdGlvbi4KCiAgIENTUHMgaGF2ZSBhIGRlc2lyZSB0byBiZSBhYmxlIHRvIGdldCAoc29tZSBv ZikgdGhlaXIgY29udGVudCB0byB2ZXJ5CiAgIGxhcmdlIG51bWJlcnMgb2YgRW5kIFVzZXJzLCB3 aG8gYXJlIG9mdGVuIGRpc3RyaWJ1dGVkIGFjcm9zcyBhIG51bWJlcgogICBvZiBnZW9ncmFwaGll cywgd2hpbGUgbWFpbnRhaW5pbmcgYSBoaWdoIHF1YWxpdHkgb2YgZXhwZXJpZW5jZSwgYWxsCiAg IHdpdGhvdXQgaGF2aW5nIHRvIG1haW50YWluIGRpcmVjdCBidXNpbmVzcyByZWxhdGlvbnNoaXBz IHdpdGggbWFueQogICBkaWZmZXJlbnQgQ0ROIFByb3ZpZGVycyAob3IgaGF2aW5nIHRvIGV4dGVu ZCB0aGVpciBvd24gQ0ROIHRvIGEgbGFyZ2UKICAgbnVtYmVyIG9mIGxvY2F0aW9ucykuICBTb21l IE5TUHMgYXJlIGNvbnNpZGVyaW5nIGludGVyY29ubmVjdGluZwogICB0aGVpciByZXNwZWN0aXZl IENETnMgKGFzIHdlbGwgYXMgcG9zc2libHkgb3Zlci10aGUtdG9wIENETnMpIHNvIHRoYXQKICAg dGhpcyBjb2xsZWN0aXZlIGluZnJhc3RydWN0dXJlIGNhbiBhZGRyZXNzIHRoZSByZXF1aXJlbWVu dHMgb2YgQ1NQcwogICBpbiBhIGNvc3QgZWZmZWN0aXZlIG1hbm5lci4gIFRoaXMgcmVwcmVzZW50 cyBhIHNlY29uZCB1c2UgY2FzZSBmb3IKICAgQ0ROSS4gIEluIHBhcnRpY3VsYXIsIHRoaXMgd291 bGQgZW5hYmxlIHRoZSBDU1BzIHRvIGJlbmVmaXQgZnJvbSBvbi0KICAgbmV0IGRlbGl2ZXJ5IChp LmUuIHdpdGhpbiB0aGUgTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVyJ3Mgb3duIG5ldHdvcmsvCiAg IENETiBmb290cHJpbnQpIHdoZW5ldmVyIHBvc3NpYmxlIGFuZCBvZmYtbmV0IGRlbGl2ZXJ5IG90 aGVyd2lzZSwKICAgd2l0aG91dCByZXF1aXJpbmcgdGhlIENTUHMgdG8gbWFpbnRhaW4gZGlyZWN0 IGJ1c2luZXNzIHJlbGF0aW9uc2hpcHMKICAgd2l0aCBhbGwgdGhlIENETnMgaW52b2x2ZWQgaW4g dGhlIGRlbGl2ZXJ5LiAgQWdhaW4sIENETiBQcm92aWRlcnMKICAgKE5TUHMgb3Igb3Zlci10aGUt dG9wIENETiBvcGVyYXRvcnMpIGFyZSBmYWNlZCB3aXRoIGEgbGFjayBvZiBvcGVuCiAgIHNwZWNp ZmljYXRpb25zIGFuZCBiZXN0IHByYWN0aWNlcy4KCiAgIE5TUHMgaGF2ZSBvZnRlbiBkZXBsb3ll ZCBDRE5zIGFzIHNwZWNpYWxpemVkIGNvc3QtcmVkdWN0aW9uIHByb2plY3RzCiAgIHdpdGhpbiB0 aGUgY29udGV4dCBvZiBhIHBhcnRpY3VsYXIgc2VydmljZSBvciBlbnZpcm9ubWVudC4gIFNvbWUg TlNQcwogICBvcGVyYXRlIHNlcGFyYXRlIENETnMgZm9yIHNlcGFyYXRlIHNlcnZpY2VzLiAgRm9y IGV4YW1wbGUsIHRoZXJlIG1heQogICBiZSBhIENETiBmb3IgbWFuYWdlZCBJUFRWIHNlcnZpY2Ug ZGVsaXZlcnksIGEgQ0ROIGZvciB3ZWItVFYgZGVsaXZlcnkKICAgYW5kIGEgQ0ROIGZvciB2aWRl byBkZWxpdmVyeSB0byBNb2JpbGUgdGVybWluYWxzLiAgQXMgTlNQcyBpbnRlZ3JhdGUKICAgdGhl aXIgc2VydmljZSBwb3J0Zm9saW8sIHRoZXJlIGlzIGEgbmVlZCBmb3IgaW50ZXJjb25uZWN0aW5n IHRoZXNlCiAgIENETnMsIHJlcHJlc2VudGluZyBhIHRoaXJkIHVzZSBjYXNlIGZvciBDRE5JLiAg QWdhaW4sIE5TUHMgZmFjZSB0aGUKICAgcHJvYmxlbSBvZiBsYWNrIG9mIG9wZW4gaW50ZXJmYWNl cyBmb3IgQ0ROIGludGVyY29ubmVjdGlvbi4KCiAgIEZvciBvcGVyYXRpb25hbCByZWFzb25zIChl LmcuIGRpc2FzdGVyLCBmbGFzaCBjcm93ZCkgb3IgY29tbWVyY2lhbAogICByZWFzb25zLCBhbiBv dmVyLXRoZS10b3AgQ0ROIG1heSBlbGVjdCB0byBtYWtlIHVzZSBvZiBhbm90aGVyIENETgogICAo ZS5nLiBhbiBOU1AgQ0ROIHdpdGggb24tbmV0IFN1cnJvZ2F0ZXMgZm9yIGEgZ2l2ZW4gZm9vdHBy aW50KSBmb3IKICAgc2VydmluZyBhIHN1YnNldCBvZiB0aGUgdXNlciByZXF1ZXN0cyAoZS5nLiBy ZXF1ZXN0cyBmcm9tIHVzZXJzCiAgIGF0dGFjaGVkIHRvIHRoYXQgTlNQKSwgd2hpY2ggcmVzdWx0 cyBpbiBhIGZvdXJ0aCB1c2UgY2FzZSBmb3IgQ0ROSQogICBiZWNhdXNlIENETiBQcm92aWRlcnMg KG92ZXItdGhlLXRvcCBDRE4gUHJvdmlkZXJzIG9yIE5TUHMpIGFyZSBmYWNlZAogICB3aXRoIGEg bGFjayBvZiBvcGVuIHNwZWNpZmljYXRpb25zIGFuZCBiZXN0IHByYWN0aWNlcy4KCiAgIFVzZSBj YXNlcyBmb3IgQ0ROIEludGVyY29ubmVjdGlvbiBhcmUgZnVydGhlciBkaXNjdXNzZWQgaW4KICAg W0ktRC5pZXRmLWNkbmktdXNlLWNhc2VzXS4KCgozLiAgQ0ROIEludGVyY29ubmVjdGlvbiBNb2Rl bCAmIFByb2JsZW0gQXJlYSBmb3IgSUVURgoKICAgVGhpcyBzZWN0aW9uIGRpc2N1c3NlcyB0aGUg cHJvYmxlbSBhcmVhIGZvciB0aGUgSUVURiB3b3JrIG9uIENETgogICBJbnRlcmNvbm5lY3Rpb24u CgogICBJbnRlcmNvbm5lY3RpbmcgQ0ROcyBpbnZvbHZlcyBpbnRlcmFjdGlvbnMgYW1vbmcgbXVs dGlwbGUgZGlmZmVyZW50CiAgIGZ1bmN0aW9ucyBhbmQgY29tcG9uZW50cyB0aGF0IGZvcm0gZWFj aCBDRE4uICBPbmx5IHNvbWUgb2YgdGhvc2UKICAgcmVxdWlyZSBzdGFuZGFyZGl6YXRpb24uCgoK Ck5pdmVuLUplbmtpbnMsIGV0IGFsLiAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAxMiAgICAgICAg ICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAgIENETiBJbnRlcmNvbm5lY3Rpb24g UHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgQXByaWwgMjAxMgoKCiAgIFNvbWUgTlNQcyBoYXZlIHN0 YXJ0ZWQgdG8gcGVyZm9ybSBleHBlcmltZW50cyB0byBleHBsb3JlIHdoZXRoZXIKICAgdGhlaXIg Q0ROIHVzZSBjYXNlcyBjYW4gYWxyZWFkeSBiZSBhZGRyZXNzZWQgd2l0aCBleGlzdGluZyBDRE4K ICAgaW1wbGVtZW50YXRpb25zLiAgT25lIHNldCBvZiBzdWNoIGV4cGVyaW1lbnRzIGlzIGRvY3Vt ZW50ZWQgaW4KICAgW0ktRC5iZXJ0cmFuZC1jZG5pLWV4cGVyaW1lbnRzXS4gIFRoZSBjb25jbHVz aW9ucyBvZiB0aG9zZQogICBleHBlcmltZW50cyBhcmUgdGhhdCB3aGlsZSBzb21lIGJhc2ljIGxp bWl0ZWQgQ0ROIEludGVyY29ubmVjdGlvbgogICBmdW5jdGlvbmFsaXR5IGNhbiBiZSBhY2hpZXZl ZCB3aXRoIGV4aXN0aW5nIENETiB0ZWNobm9sb2d5LCB0aGUKICAgY3VycmVudCBsYWNrIG9mIGFu eSBzdGFuZGFyZGl6ZWQgQ0ROSSBpbnRlcmZhY2VzIHdpdGggdGhlIG5lY2Vzc2FyeQogICBsZXZl bCBvZiBmdW5jdGlvbmFsaXR5IHN1Y2ggYXMgdGhvc2UgZGlzY3Vzc2VkIGluIHRoaXMgZG9jdW1l bnQgaXMKICAgcHJldmVudGluZyB0aGUgZGVwbG95bWVudCBvZiBDRE4gSW50ZXJjb25uZWN0aW9u LgoKICAgTGlzdGVkIGJlbG93IGFyZSB0aGUgZm91ciBpbnRlcmZhY2VzIHJlcXVpcmVkIHRvIGlu dGVyY29ubmVjdCBhIHBhaXIKICAgb2YgQ0ROcyBhbmQgdGhhdCBjb25zdGl0dXRlIHRoZSBwcm9i bGVtIHNwYWNlIG9mIENETiBJbnRlcmNvbm5lY3Rpb24KICAgYWxvbmcgd2l0aCB0aGUgcmVxdWly ZWQgZnVuY3Rpb25hbGl0eSBvZiBlYWNoIGludGVyZmFjZSBmb3Igd2hpY2gKICAgc3RhbmRhcmRz IGRvIG5vdCBjdXJyZW50bHkgZXhpc3QuICBBcyBwYXJ0IG9mIHRoZSBkZXZlbG9wbWVudCBvZiB0 aGUKICAgQ0ROSSBpbnRlcmZhY2VzIGl0IHdpbGwgYWxzbyBiZSBuZWNlc3NhcnkgdG8gYWdyZWUg b24gY29tbW9uCiAgIG1lY2hhbmlzbXMgZm9yIGhvdyB0byBpZGVudGlmeSBhbmQgbmFtZSB0aGUg ZGF0YSBvYmplY3RzIHRoYXQgYXJlIHRvCiAgIGJlIGludGVyY2hhbmdlZCBiZXR3ZWVuIGludGVy Y29ubmVjdGVkIENETnMuCgogICBUaGUgdXNlIG9mIHRoZSB0ZXJtICJpbnRlcmZhY2UiIGlzIG1l YW50IHRvIGVuY29tcGFzcyB0aGUgcHJvdG9jb2wKICAgb3ZlciB3aGljaCBDRE5JIGRhdGEgcmVw cmVzZW50YXRpb25zIChlLmcuICBDRE5JIE1ldGFkYXRhIG9iamVjdHMpCiAgIGFyZSBleGNoYW5n ZWQgYXMgd2VsbCBhcyB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgZGF0YQogICByZXByZXNlbnRh dGlvbnMgdGhlbXNlbHZlcyAoaS5lLiB3aGF0IHByb3BlcnRpZXMvZmllbGRzIGVhY2ggb2JqZWN0 CiAgIGNvbnRhaW5zLCBpdHMgc3RydWN0dXJlLCBldGMuKS4KCiAgIG8gIENETkkgQ29udHJvbCBp bnRlcmZhY2U6IFRoaXMgaW50ZXJmYWNlIGFsbG93cyB0aGUgIkNETkkgQ29udHJvbCIKICAgICAg c3lzdGVtIGluIGludGVyY29ubmVjdGVkIENETnMgdG8gY29tbXVuaWNhdGUuICBUaGlzIGludGVy ZmFjZSBtYXkKICAgICAgc3VwcG9ydCB0aGUgZm9sbG93aW5nOgogICAgICAqICBBbGxvdyBib290 c3RyYXBwaW5nIG9mIHRoZSBvdGhlciBDRE5JIGludGVyZmFjZXMgKGUuZy4KICAgICAgICAgaW50 ZXJmYWNlIGFkZHJlc3MvVVJMIGRpc2NvdmVyeSBhbmQgZXN0YWJsaXNobWVudCBvZiBzZWN1cml0 eQogICAgICAgICBhc3NvY2lhdGlvbnMpLgogICAgICAqICBBbGxvdyBjb25maWd1cmF0aW9uIG9m IHRoZSBvdGhlciBDRE5JIGludGVyZmFjZXMgKGUuZy4KICAgICAgICAgVXBzdHJlYW0gQ0ROIHNw ZWNpZmllcyBpbmZvcm1hdGlvbiB0byBiZSByZXBvcnRlZCB0aHJvdWdoIHRoZQogICAgICAgICBD RE5JIExvZ2dpbmcgaW50ZXJmYWNlKS4KICAgICAgKiAgQWxsb3cgdGhlIGRvd25zdHJlYW0gQ0RO IHRvIGNvbW11bmljYXRlIHN0YXRpYyAob3IgZmFpcmx5CiAgICAgICAgIHN0YXRpYykgaW5mb3Jt YXRpb24gYWJvdXQgaXRzIGRlbGl2ZXJ5IGNhcGFiaWxpdGllcyBhbmQKICAgICAgICAgcG9saWNp ZXMuCiAgICAgICogIEFsbG93IGJvb3RzdHJhcHBpbmcgb2YgdGhlIGludGVyZmFjZSBiZXR3ZWVu IENETnMgZm9yIGNvbnRlbnQKICAgICAgICAgYWNxdWlzaXRpb24gKGV2ZW4gaWYgdGhhdCBpbnRl cmZhY2UgaXRzZWxmIGlzIG91dHNpZGUgdGhlIHNjb3BlCiAgICAgICAgIG9mIHRoZSBDRE5JIHdv cmspLgogICAgICAqICBBbGxvdyBhbiB1cHN0cmVhbSBDRE4gdG8gaW5pdGlhdGUgb3IgcmVxdWVz dCBzcGVjaWZpYyBhY3Rpb25zCiAgICAgICAgIHRvIGJlIHVuZGVydGFrZW4gaW4gdGhlIGRvd25z dHJlYW0gQ0ROLiAgRm9yIGV4YW1wbGUsIHRvIGFsbG93CiAgICAgICAgIGFuIHVwc3RyZWFtIENE TiB0byBpbml0aWF0ZSBjb250ZW50IG9yIENETkkgTWV0YWRhdGEKICAgICAgICAgYWNxdWlzaXRp b24gKHByZS1wb3NpdGlvbmluZykgb3IgdG8gcmVxdWVzdCB0aGUgaW52YWxpZGF0aW9uIG9yCiAg ICAgICAgIHB1cmdpbmcgb2YgY29udGVudCBmaWxlcyBhbmQvb3IgQ0ROSSBNZXRhZGF0YSBpbiBh IGRvd25zdHJlYW0KICAgICAgICAgQ0ROLgogICBvICBDRE5JIFJlcXVlc3QgUm91dGluZyBpbnRl cmZhY2U6IFRoaXMgaW50ZXJmYWNlIGFsbG93cyB0aGUgUmVxdWVzdAogICAgICBSb3V0aW5nIHN5 c3RlbXMgaW4gaW50ZXJjb25uZWN0ZWQgQ0ROcyB0byBjb21tdW5pY2F0ZSB0byBlbnN1cmUKICAg ICAgdGhhdCBhbiBFbmQgVXNlciByZXF1ZXN0IGNhbiBiZSAocmUpZGlyZWN0ZWQgZnJvbSBhbiB1 cHN0cmVhbSBDRE4KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAx LCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIElu dGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgICAg dG8gYSBzdXJyb2dhdGUgaW4gdGhlIGRvd25zdHJlYW0gQ0ROLCBpbiBwYXJ0aWN1bGFyIHdoZXJl CiAgICAgIHNlbGVjdGlvbiByZXNwb25zaWJpbGl0aWVzIG1heSBiZSBzcGxpdCBhY3Jvc3MgQ0RO cyAoZm9yIGV4YW1wbGUKICAgICAgdGhlIHVwc3RyZWFtIENETiBtYXkgYmUgcmVzcG9uc2libGUg Zm9yIHNlbGVjdGluZyB0aGUgZG93bnN0cmVhbQogICAgICBDRE4gd2hpbGUgdGhlIGRvd25zdHJl YW0gQ0ROIG1heSBiZSByZXNwb25zaWJsZSBmb3Igc2VsZWN0aW5nIHRoZQogICAgICBhY3R1YWwg c3Vycm9nYXRlIHdpdGhpbiB0aGF0IGRvd25zdHJlYW0gQ0ROKS4gIEluIHBhcnRpY3VsYXIsIHRo ZQogICAgICBDRE4gUmVxdWVzdCBSb3V0aW5nIGludGVyZmFjZSwgbWF5IHN1cHBvcnQgdGhlIGZv bGxvd2luZzoKICAgICAgKiAgQWxsb3cgdGhlIHVwc3RyZWFtIENETiB0byBxdWVyeSB0aGUgZG93 bnN0cmVhbSBDRE4gYXQgcmVxdWVzdAogICAgICAgICByb3V0aW5nIHRpbWUgYmVmb3JlIHJlZGly ZWN0aW5nIHRoZSByZXF1ZXN0IHRvIHRoZSBkb3duc3RyZWFtCiAgICAgICAgIENETi4KICAgICAg KiAgQWxsb3cgdGhlIGRvd25zdHJlYW0gQ0ROIHRvIHByb3ZpZGUgdG8gdGhlIHVwc3RyZWFtIENE TiAoc3RhdGljCiAgICAgICAgIG9yIGR5bmFtaWMpIGluZm9ybWF0aW9uIChlLmcuIHJlc291cmNl cywgZm9vdHByaW50LCBsb2FkKSB0bwogICAgICAgICBmYWNpbGl0YXRlIHNlbGVjdGlvbiBvZiB0 aGUgZG93bnN0cmVhbSBDRE4gYnkgdGhlIHVwc3RyZWFtIENETgogICAgICAgICByZXF1ZXN0IHJv dXRpbmcgc3lzdGVtIHdoZW4gcHJvY2Vzc2luZyBzdWJzZXF1ZW50IGNvbnRlbnQKICAgICAgICAg cmVxdWVzdHMgZnJvbSBVc2VyIEFnZW50cy4KICAgbyAgQ0ROSSBNZXRhZGF0YSBkaXN0cmlidXRp b24gaW50ZXJmYWNlOiBUaGlzIGludGVyZmFjZSBhbGxvd3MgdGhlCiAgICAgIERpc3RyaWJ1dGlv biBzeXN0ZW0gaW4gaW50ZXJjb25uZWN0ZWQgQ0ROcyB0byBjb21tdW5pY2F0ZSB0bwogICAgICBl bnN1cmUgQ0ROSSBNZXRhZGF0YSBjYW4gYmUgZXhjaGFuZ2VkIGFjcm9zcyBDRE5zLiAgU2VlCiAg ICAgIFNlY3Rpb24gMS4xIGZvciBkZWZpbml0aW9uIGFuZCBleGFtcGxlcyBvZiBDRE5JIE1ldGFk YXRhLgogICBvICBDRE5JIExvZ2dpbmcgaW50ZXJmYWNlOiBUaGlzIGludGVyZmFjZSBhbGxvd3Mg dGhlIExvZ2dpbmcgc3lzdGVtCiAgICAgIGluIGludGVyY29ubmVjdGVkIENETnMgdG8gY29tbXVu aWNhdGUgdGhlIHJlbGV2YW50IGFjdGl2aXR5IGxvZ3MKICAgICAgaW4gb3JkZXIgdG8gYWxsb3cg bG9nIGNvbnN1bWluZyBhcHBsaWNhdGlvbnMgdG8gb3BlcmF0ZSBpbiBhCiAgICAgIG11bHRpLUNE TiBlbnZpcm9ubWVudHMuICBGb3IgZXhhbXBsZSwgYW4gdXBzdHJlYW0gQ0ROIG1heSBjb2xsZWN0 CiAgICAgIGRlbGl2ZXJ5IGxvZ3MgZnJvbSBhIGRvd25zdHJlYW0gQ0ROIGluIG9yZGVyIHRvIHBl cmZvcm0KICAgICAgY29uc29saWRhdGVkIGNoYXJnaW5nIG9mIHRoZSBDU1Agb3IgZm9yIHNldHRs ZW1lbnQgcHVycG9zZXMgYWNyb3NzCiAgICAgIENETnMuICBTaW1pbGFybHksIGFuIHVwc3RyZWFt IENETiBtYXkgY29sbGVjdCBkZWxpdmVyeSBsb2dzIGZyb20gYQogICAgICBkb3duc3RyZWFtIENE TiBpbiBvcmRlciB0byBwcm92aWRlIGNvbnNvbGlkYXRlZCByZXBvcnRpbmcgYW5kCiAgICAgIG1v bml0b3JpbmcgdG8gdGhlIENTUC4KCiAgIE5vdGUgdGhhdCB0aGUgYWN0dWFsIGdyb3VwaW5nIG9m IGZ1bmN0aW9uYWxpdGllcyB1bmRlciB0aGVzZSBmb3VyCiAgIGludGVyZmFjZXMgaXMgY29uc2lk ZXJlZCB0ZW50YXRpdmUgYXQgdGhpcyBzdGFnZSBhbmQgbWF5IGJlIGNoYW5nZWQKICAgYWZ0ZXIg ZnVydGhlciBzdHVkeSAoZS5nLiBzb21lIHN1YnNldCBvZiBmdW5jdGlvbmFsaXR5IGJlIG1vdmVk IGZyb20KICAgb25lIGludGVyZmFjZSBpbnRvIGFub3RoZXIpLgoKICAgVGhlIGFib3ZlIGxpc3Qg Y292ZXJzIGEgc2lnbmlmaWNhbnQgcG90ZW50aWFsIHByb2JsZW0gc3BhY2UsIGluIHBhcnQKICAg YmVjYXVzZSBpbiBvcmRlciB0byBpbnRlcmNvbm5lY3QgdHdvIENETnMgdGhlcmUgYXJlIHNldmVy YWwgJ3RvdWNoCiAgIHBvaW50cycgdGhhdCByZXF1aXJlIHN0YW5kYXJkaXphdGlvbi4gIEhvd2V2 ZXIsIGl0IGlzIGV4cGVjdGVkIHRoYXQKICAgdGhlIENETkkgaW50ZXJmYWNlcyBuZWVkIG5vdCBi ZSBkZWZpbmVkIGZyb20gc2NyYXRjaCBhbmQgaW5zdGVhZCBjYW4KICAgdmVyeSBzaWduaWZpY2Fu dGx5IHJldXNlIG9yIGxldmVyYWdlIGV4aXN0aW5nIHByb3RvY29sczsgdGhpcyBpcwogICBkaXNj dXNzZWQgZnVydGhlciBpbiBTZWN0aW9uIDQuCgogICBUaGUgaW50ZXJmYWNlcyB0aGF0IGZvcm0g dGhlIENETkkgcHJvYmxlbSBhcmVhIGFyZSBpbGx1c3RyYXRlZCBpbgogICBGaWd1cmUgMS4KCgoK CgoKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEyICAg ICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIEludGVyY29ubmVj dGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgICAtLS0tLS0tLQog ICAgLyAgICAgICAgXAogICAgfCAgIENTUCAgfAogICAgXCAgICAgICAgLwogICAgIC0tLS0tLS0t CiAgICAgICAgICoKICAgICAgICAgKgogICAgICAgICAqICAgICAgICAgICAgICAgICAgICAgICAg IC9cCiAgICAgICAgICogICAgICAgICAgICAgICAgICAgICAgICAvICBcCiAgICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSAgICAgIHxDRE5JfCAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQog ICAgLyAgICAgVXBzdHJlYW0gQ0ROICAgICBcICAgICB8ICAgIHwgICAgICAgLyAgICBEb3duc3Ry ZWFtIENETiAgICBcCiAgICB8ICAgICAgKy0tLS0tLS0tLS0tLS0rIHwgQ29udHJvbCBJbnRlcmZh Y2V8ICstLS0tLS0tLS0tLS0tKyAgICAgIHwKICAgIHwqKioqKioqICAgQ29udHJvbCAgIHw8PT09 PT09fD09PT18PT09PT09PT0+fCAgIENvbnRyb2wgICAqKioqKioqfAogICAgfCogICAgICstLS0t LS0qLS0tLSotKyB8ICAgICB8ICAgIHwgICAgICAgfCArLSotLS0tKi0tLS0tLSsgICAgICp8CiAg ICB8KiAgICAgICAgICAgICogICAgKiAgIHwgICAgIHwgICAgfCAgICAgICB8ICAgKiAgICAqICAg ICAgICAgICAgKnwKICAgIHwqICAgICArLS0tLS0tKi0tLS0tLSsgfCBMb2dnaW5nIEludGVyZmFj ZXwgKy0tLS0tLSotLS0tLS0rICAgICAqfAogICAgfCogKioqKiogICBMb2dnaW5nICAgfDw9PT09 PT18PT09PXw9PT09PT09PT58ICAgTG9nZ2luZyAgICoqKioqICp8CiAgICB8KiAqICAgKy0qLS0t LS0tLS0tLS0rIHwgICAgIHwgICAgfCAgICAgICB8ICstLS0tLS0tLS0tLSotKyAgICogKnwKICAg IHwqICogICAgICogICAgICAgICAqICAgfCBSZXF1ZXN0IFJvdXRpbmcgIHwgICAqICAgICAgICAg KiAgICAgKiAqfAogIC4uLi4uKi4uListKi0tLS0tLS0tLSotKyB8ICAgIEludGVyZmFjZSAgICAg fCArLSotLS0tLS0tLS0qLSsuLi4qLiouLi4KICAuIHwqICogKioqIFJlcS1Sb3V0aW5nIHw8PT09 PT09fD09PT18PT09PT09PT0+fCBSZXEtUm91dGluZyAqKiogKiAqfCAuCiAgLiB8KiAqICogKy0t LS0tLS0tLS0tLS0rLnwgICAgIHwgICAgfCAgICAgICB8ICstLS0tLS0tLS0tLS0tKyAqICogKnwg LgogIC4gfCogKiAqICAgICAgICAgICAgICAgICAuICBDRE5JIE1ldGFkYXRhICAgfCAgICAgICAg ICAgICAgICAgKiAqICp8IC4KICAuIHwqICogKiArLS0tLS0tLS0tLS0tLSsgfC4gICBJbnRlcmZh Y2UgICAgIHwgKy0tLS0tLS0tLS0tLS0rICogKiAqfCAuCiAgLiB8KiAqICogfCBEaXN0cmlidXRp b258PD09Lj09PXw9PT09fD09PT09PT09PnwgRGlzdHJpYnV0aW9ufCAqICogKnwgLgogIC4gfCog KiAqIHwgICAgICAgICAgICAgfCB8ICAuICAgXCAgLyAgICAgICAgfCB8ICAgICAgICAgICAgIHwg KiAqICp8IC4KICAuIHwqICogKiB8Ky0tLS0tLS0tLSsgIHwgfCAgIC4gICBcLyAgICAgICAgIHwg fCAgKy0tLS0tLS0tLSt8ICogKiAqfCAuCiAgLiB8KiAqICoqKnwgKy0tLS0tLS0tLSt8IHwgICAg Li4uLlJlcXVlc3QuLi4uLi4rLS0tLS0tLS0tKyB8KioqICogKnwgLgogIC4gfCogKioqKiorLXxT dXJyb2dhdGV8KioqKioqKioqKioqKioqKioqKioqKioqfFN1cnJvZ2F0ZXwtKyoqKioqICp8IC4K ICAuIHwqKioqKioqICArLS0tLS0tLS0tK3wgfCAgIEFjcXVpc2l0aW9uICAgIHwgfCstLS0tLS0t LS0tKyAqKioqKioqfCAuCiAgLiB8ICAgICAgKy0tLS0tLS0tLS0tLS0rIHwgICAgICAgICAgICAg ICAgICB8ICstLS0tLS0tKi0tLS0tKyAgICAgIHwgLgogIC4gXCAgICAgICAgICAgICAgICAgICAg ICAvICAgICAgICAgICAgICAgICAgXCAgICAgICAgICogICAgICAgICAgICAvIC4KICAuICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0qLS0tLS0tLS0t LS0tICAuCiAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKiAgICAgICAgICAgICAgLgogIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICogRGVsaXZlcnkgICAgIC4KICAuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqICAgICAgICAgICAgICAuCiAg LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tKi0t LSsgICAgICAgICAgLgogIC4uLi4uLi4uLi4uLi4uLlJlcXVlc3QuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLnwgVXNlciB8Li5SZXF1ZXN0Li4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IEFnZW50fAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rCgogIDw9PT4gIGludGVyZmFj ZXMgaW5zaWRlIHRoZSBzY29wZSBvZiBDRE5JCiAgKioqKiAgaW50ZXJmYWNlcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiBDRE5JCiAgLi4uLiAgaW50ZXJmYWNlcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBD RE5JCgogICAgICAgICAgICAgICAgRmlndXJlIDE6IEEgTW9kZWwgZm9yIHRoZSBDRE5JIFByb2Js ZW0gQXJlYQoKICAgQXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDEsIHRoZSBhY3F1aXNpdGlvbiBv ZiBjb250ZW50IGJldHdlZW4KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3Zl bWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAg Q0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoK ICAgaW50ZXJjb25uZWN0ZWQgQ0ROcyBpcyBvdXQgb2Ygc2NvcGUgZm9yIENETkksIHdoaWNoIGRl c2VydmVzIHNvbWUKICAgYWRkaXRpb25hbCBleHBsYW5hdGlvbi4gIFRoZSBjb25zZXF1ZW5jZSBv ZiBzdWNoIGEgZGVjaXNpb24gaXMgdGhhdAogICB0aGUgQ0ROSSBwcm9ibGVtIHNwYWNlIGRlc2Ny aWJlZCBpbiB0aGlzIGRvY3VtZW50IGlzIGZvY3Vzc2VkIG9uIG9ubHkKICAgZGVmaW5pbmcgdGhl IGNvbnRyb2wgcGxhbmUgZm9yIENETkk7IGFuZCB0aGUgQ0ROSSBkYXRhIHBsYW5lIChpLmUuCiAg IHRoZSBhY3F1aXNpdGlvbiAmIGRpc3RyaWJ1dGlvbiBvZiB0aGUgYWN0dWFsIGNvbnRlbnQgb2Jq ZWN0cykgaXMgb3V0CiAgIG9mIHNjb3BlLiAgVGhlIHJhdGlvbmFsZSBmb3Igc3VjaCBhIGRlY2lz aW9uIGlzIHRoYXQgQ0ROcyB0b2RheQogICB0eXBpY2FsbHkgYWxyZWFkeSB1c2Ugc3RhbmRhcmRp emVkIHByb3RvY29scyBzdWNoIGFzIEhUVFAsIEZUUCwKICAgcnN5bmMsIGV0Yy4gdG8gYWNxdWly ZSBjb250ZW50IGZyb20gdGhlaXIgQ1NQIGN1c3RvbWVycyBhbmQgaXQgaXMKICAgZXhwZWN0ZWQg dGhhdCB0aGUgc2FtZSBwcm90b2NvbHMgY291bGQgYmUgdXNlZCBmb3IgYWNxdWlzaXRpb24KICAg YmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zLiAgVGhlcmVmb3JlIHRoZSBwcm9ibGVtIG9mIGNv bnRlbnQKICAgYWNxdWlzaXRpb24gaXMgY29uc2lkZXJlZCBhbHJlYWR5IHNvbHZlZCBhbmQgYWxs IHRoYXQgaXMgcmVxdWlyZWQKICAgZnJvbSBzcGVjaWZpY2F0aW9ucyBkZXZlbG9wZWQgYnkgdGhl IENETkkgd29ya2luZyBncm91cCBpcyB0bwogICBkZXNjcmliZSB3aXRoaW4gdGhlIENETkkgTWV0 YWRhdGEgdGhlIHBhcmFtZXRlcnMgdG8gdXNlIHRvIHJldHJpZXZlCiAgIHRoZSBjb250ZW50IGZv ciBleGFtcGxlIHRoZSBJUCBhZGRyZXNzL2hvc3RuYW1lIHRvIGNvbm5lY3QgdG8sIHdoYXQKICAg cHJvdG9jb2wgdG8gdXNlIHRvIHJldHJpZXZlIHRoZSBjb250ZW50LCBldGMuCgoKNC4gIFNjb3Bp bmcgdGhlIENETkkgUHJvYmxlbQoKICAgVGhpcyBzZWN0aW9uIG91dGxpbmVzIGhvdyB0aGUgc2Nv cGUgb2Ygd29yayBhZGRyZXNzaW5nIHRoZSBDRE5JCiAgIHByb2JsZW0gc3BhY2UgY2FuIGJlIGNv bnN0cmFpbmVkIHRocm91Z2ggcmV1c2Ugb3IgbGV2ZXJhZ2luZyBvZgogICBleGlzdGluZyBwcm90 b2NvbHMgdG8gaW1wbGVtZW50IHRoZSBDRE5JIGludGVyZmFjZXMuICBUaGlzIGRpc2N1c3Npb24K ICAgaXMgbm90IGludGVuZGVkIHRvIHByZS1lbXB0IGFueSB3b3JraW5nIGdyb3VwIGRlY2lzaW9u IGFzIHRvIHRoZSBtb3N0CiAgIGFwcHJvcHJpYXRlIHByb3RvY29scywgdGVjaG5vbG9naWVzIGFu ZCBzb2x1dGlvbnMgdG8gc2VsZWN0IHRvCiAgIHJlYWxpemUgdGhlIENETkkgaW50ZXJmYWNlcyBi dXQgaXMgaW50ZW5kZWQgYXMgYW4gaWxsdXN0cmF0aW9uIG9mIHRoZQogICBmYWN0IHRoYXQgdGhl IENETkkgaW50ZXJmYWNlcyBuZWVkIG5vdCBiZSBjcmVhdGVkIGluIGEgdmFjdXVtIGFuZAogICB0 aGF0IHJldXNlIG9yIGxldmVyYWdlIG9mIGV4aXN0aW5nIHByb3RvY29scyBpcyBsaWtlbHkgcG9z c2libGUuCgogICBUaGUgZm91ciBDRE5JIGludGVyZmFjZXMgKENETkkgQ29udHJvbCBpbnRlcmZh Y2UsIENETkkgUmVxdWVzdAogICBSb3V0aW5nIGludGVyZmFjZSwgQ0ROSSBNZXRhZGF0YSBpbnRl cmZhY2UsIENETkkgTG9nZ2luZyBpbnRlcmZhY2UpCiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMg d2l0aGluIHRoZSBDRE5JIHByb2JsZW0gYXJlYSBhcmUgYWxsIGNvbnRyb2wKICAgcGxhbmUgaW50 ZXJmYWNlcyBvcGVyYXRpbmcgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIChMYXllciA3IGluIHRo ZQogICBPU0kgbmV0d29yayBtb2RlbCkuICBGaXJzdGx5LCBzaW5jZSBpdCBpcyBub3QgZXhwZWN0 ZWQgdGhhdCB0aGVzZQogICBpbnRlcmZhY2VzIHdvdWxkIGV4aGliaXQgdW5pcXVlIHNlc3Npb24s IHRyYW5zcG9ydCBvciBuZXR3b3JrCiAgIHJlcXVpcmVtZW50cyBhcyBjb21wYXJlZCB0byB0aGUg bWFueSBvdGhlciBleGlzdGluZyBhcHBsaWNhdGlvbnMgaW4KICAgdGhlIEludGVybmV0LCBpdCBp cyBleHBlY3RlZCB0aGF0IHRoZSBDRE5JIGludGVyZmFjZXMgd2lsbCBiZSBkZWZpbmVkCiAgIG9u IHRvcCBvZiBleGlzdGluZyBzZXNzaW9uLCB0cmFuc3BvcnQgYW5kIG5ldHdvcmsgcHJvdG9jb2xz LgoKICAgU2Vjb25kbHksIGFsdGhvdWdoIGEgbmV3IGFwcGxpY2F0aW9uIHByb3RvY29sIGNvdWxk IGJlIGRlc2lnbmVkCiAgIHNwZWNpZmljYWxseSBmb3IgQ0ROSSBvdXIgYW5hbHlzaXMgYmVsb3cg c2hvd3MgdGhhdCB0aGlzIGlzCiAgIHVubmVjZXNzYXJ5IGFuZCBpdCBpcyByZWNvbW1lbmRlZCB0 aGF0IGV4aXN0aW5nIGFwcGxpY2F0aW9uIHByb3RvY29scwogICBiZSByZXVzZWQgb3IgbGV2ZXJh Z2VkIChIVFRQIFtSRkMyNjE2XSwgQXRvbSBQdWJsaXNoaW5nIFByb3RvY29sCiAgIFtSRkM1MDIz XSwgWE1QUCBbUkZDNjEyMF0sIGZvciBleGFtcGxlKSB0byByZWFsaXplIHRoZSBDRE5JCiAgIGlu dGVyZmFjZXMuCgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVy IDEsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4g SW50ZXJjb25uZWN0aW9uIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgo0LjEu ICBDRE5JIFJlcXVlc3QgUm91dGluZyBJbnRlcmZhY2UKCiAgIFRoZSBDRE5JIFJlcXVlc3QgUm91 dGluZyBpbnRlcmZhY2UgZW5hYmxlcyBhIFJlcXVlc3QgUm91dGluZyBmdW5jdGlvbgogICBpbiBh biB1cHN0cmVhbSBDRE4gdG8gcXVlcnkgYSBSZXF1ZXN0IFJvdXRpbmcgZnVuY3Rpb24gaW4gYQog ICBkb3duc3RyZWFtIENETiB0byBkZXRlcm1pbmUgaWYgdGhlIGRvd25zdHJlYW0gQ0ROIGlzIGFi bGUgKGFuZAogICB3aWxsaW5nKSB0byBhY2NlcHQgdGhlIGRlbGVnYXRlZCBjb250ZW50IHJlcXVl c3QgYW5kIHRvIGFsbG93IHRoZQogICBkb3duc3RyZWFtIENETiB0byBjb250cm9sIHdoYXQgdGhl IHVwc3RyZWFtIFJlcXVlc3QgUm91dGluZyBmdW5jdGlvbgogICBzaG91bGQgcmV0dXJuIHRvIHRo ZSBVc2VyIEFnZW50IGluIHRoZSByZWRpcmVjdGlvbiBtZXNzYWdlLgoKICAgVGhlIENETkkgUmVx dWVzdCBSb3V0aW5nIGludGVyZmFjZSBpcyB0aGVyZWZvcmUgYSBmYWlybHkKICAgc3RyYWlnaHRm b3J3YXJkIHJlcXVlc3QvcmVzcG9uc2UgaW50ZXJmYWNlIGFuZCBjb3VsZCBiZSBpbXBsZW1lbnRl ZAogICBvdmVyIGFueSBudW1iZXIgb2YgcmVxdWVzdC9yZXNwb25zZSBwcm90b2NvbHMuICBGb3Ig ZXhhbXBsZSwgaXQgbWF5CiAgIGJlIGltcGxlbWVudGVkIGFzIGEgV2ViU2VydmljZSB1c2luZyBv bmUgb2YgdGhlIGNvbW1vbiBXZWJTZXJ2aWNlcwogICBtZXRob2RvbG9naWVzIChYTUwtUlBDLCBI VFRQIHF1ZXJ5IHRvIGEga25vd24gVVJJLCBldGMuKS4gIFRoaXMKICAgcmVtb3ZlcyB0aGUgbmVl ZCBmb3IgdGhlIENETkkgd29ya2luZyBncm91cCB0byBkZWZpbmUgYSBuZXcgcHJvdG9jb2wKICAg Zm9yIHRoZSByZXF1ZXN0L3Jlc3BvbnNlIGVsZW1lbnQgb2YgdGhlIENETkkgUmVxdWVzdCBSb3V0 aW5nCiAgIGludGVyZmFjZS4KCiAgIEFkZGl0aW9uYWxseSwgYXMgZGlzY3Vzc2VkIGluIFNlY3Rp b24gMywgdGhlIENETkkgUmVxdWVzdCBSb3V0aW5nCiAgIGludGVyZmFjZSBpcyBhbHNvIGV4cGVj dGVkIHRvIGVuYWJsZSBhIGRvd25zdHJlYW0gQ0ROIHRvIHByb3ZpZGUgdG8KICAgdGhlIHVwc3Ry ZWFtIENETiAoc3RhdGljIG9yIGR5bmFtaWMpIGluZm9ybWF0aW9uIChlLmcuIHJlc291cmNlcywK ICAgZm9vdHByaW50LCBsb2FkKSB0byBmYWNpbGl0YXRlIHNlbGVjdGlvbiBvZiB0aGUgZG93bnN0 cmVhbSBDRE4gYnkgdGhlCiAgIHVwc3RyZWFtIENETiByZXF1ZXN0IHJvdXRpbmcgc3lzdGVtIHdo ZW4gcHJvY2Vzc2luZyBzdWJzZXF1ZW50CiAgIGNvbnRlbnQgcmVxdWVzdHMgZnJvbSBVc2VyIEFn ZW50cy4gIEl0IGlzIGV4cGVjdGVkIHRoYXQgc3VjaAogICBmdW5jdGlvbmFsaXR5IG9mIHRoZSBD RE5JIHJlcXVlc3QgUm91dGluZyBjb3VsZCBiZSBzcGVjaWZpZWQgYnkgdGhlCiAgIENETkkgd29y a2luZyBncm91cCB3aXRoIHNpZ25pZmljYW50IGxldmVyYWdpbmcgb2YgZXhpc3RpbmcgSUVURgog ICBwcm90b2NvbHMgc3VwcG9ydGluZyB0aGUgZHluYW1pYyBkaXN0cmlidXRpb24gb2YgcmVhY2hh YmlsaXR5CiAgIGluZm9ybWF0aW9uIChmb3IgZXhhbXBsZSBieSBsZXZlcmFnaW5nIGV4aXN0aW5n IHJvdXRpbmcgcHJvdG9jb2xzKSBvcgogICBzdXBwb3J0aW5nIGFwcGxpY2F0aW9uIGxldmVsIHF1 ZXJpZXMgZm9yIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIChmb3IKICAgZXhhbXBsZSBieSBsZXZl cmFnaW5nIEFMVE8gW0FMVE8tQ2hhcnRlcl0pLgoKNC4yLiAgQ0ROSSBNZXRhZGF0YSBJbnRlcmZh Y2UKCiAgIFRoZSBDRE5JIE1ldGFkYXRhIGludGVyZmFjZSBlbmFibGVzIHRoZSBEaXN0cmlidXRp b24gU3lzdGVtIGluIGEKICAgZG93bnN0cmVhbSBDRE4gdG8gcmVxdWVzdCBDRE5JIE1ldGFkYXRh IGZyb20gYW4gdXBzdHJlYW0gQ0ROIHNvIHRoYXQKICAgdGhlIGRvd25zdHJlYW0gQ0ROIGNhbiBw cm9wZXJseSBwcm9jZXNzIGFuZCByZXNwb25kIHRvIHJlZGlyZWN0aW9uCiAgIHJlcXVlc3RzIHJl Y2VpdmVkIG92ZXIgdGhlIENETkkgUmVxdWVzdCBSb3V0aW5nIGludGVyZmFjZSBhbmQgQ29udGVu dAogICBSZXF1ZXN0cyByZWNlaXZlZCBkaXJlY3RseSBmcm9tIFVzZXIgQWdlbnRzLgoKICAgVGhl IENETkkgTWV0YWRhdGEgaW50ZXJmYWNlIGlzIHRoZXJlZm9yZSBzaW1pbGFyIHRvIHRoZSBDRE5J IFJlcXVlc3QKICAgUm91dGluZyBpbnRlcmZhY2UgYmVjYXVzZSBpdCBpcyBhIHJlcXVlc3QvcmVz cG9uc2UgaW50ZXJmYWNlIHdpdGggdGhlCiAgIHBvdGVudGlhbCBhZGRpdGlvbiB0aGF0IENETkkg TWV0YWRhdGEgc2VhcmNoIG1heSBoYXZlIG1vcmUgY29tcGxleAogICBzZW1hbnRpY3MgdGhhbiBh IHN0cmFpZ2h0Zm9yd2FyZCBSZXF1ZXN0IFJvdXRpbmcgcmVkaXJlY3Rpb24gcmVxdWVzdC4KICAg VGhlcmVmb3JlLCBsaWtlIHRoZSBDRE5JIFJlcXVlc3QgUm91dGluZyBpbnRlcmZhY2UsIHRoZSBD RE5JIE1ldGFkYXRhCiAgIGludGVyZmFjZSBtYXkgYmUgaW1wbGVtZW50ZWQgYXMgYSBXZWJTZXJ2 aWNlIHVzaW5nIG9uZSBvZiB0aGUgY29tbW9uCiAgIFdlYlNlcnZpY2VzIG1ldGhvZG9sb2dpZXMg KFhNTC1SUEMsIEhUVFAgcXVlcnkgdG8gYSBrbm93biBVUkksIGV0Yy4pCiAgIG9yIHBvc3NpYmx5 IHVzaW5nIG90aGVyIGV4aXN0aW5nIHByb3RvY29scyBzdWNoIGFzIFhNUFAgW1JGQzYxMjBdLgog ICBUaGlzIHJlbW92ZXMgdGhlIG5lZWQgZm9yIHRoZSBDRE5JIHdvcmtpbmcgZ3JvdXAgdG8gZGVm aW5lIGEgbmV3CgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgIEV4cGlyZXMgTm92ZW1iZXIgMSwg MjAxMiAgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgIENETiBJbnRl cmNvbm5lY3Rpb24gUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgQXByaWwgMjAxMgoKCiAgIHByb3Rv Y29sIGZvciB0aGUgcmVxdWVzdC9yZXNwb25zZSBlbGVtZW50IG9mIHRoZSBDRE5JIE1ldGFkYXRh CiAgIGludGVyZmFjZS4KCjQuMy4gIENETkkgTG9nZ2luZyBJbnRlcmZhY2UKCiAgIFRoZSBDRE5J IExvZ2dpbmcgaW50ZXJmYWNlIGVuYWJsZXMgZGV0YWlscyBvZiBsb2dzIG9yIGV2ZW50cyB0byBi ZQogICBleGNoYW5nZWQgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zLCB3aGVyZSBldmVudHMg Y291bGQgYmUgZm9yCiAgIGV4YW1wbGUgbG9nIHJlY29yZHMgcmVsYXRlZCB0byB0aGUgZGVsaXZl cnkgb2YgY29udGVudCAoc2ltaWxhciB0bwogICB0aGUgbG9nIHJlY29yZHMgcmVjb3JkZWQgaW4g YSB3ZWIgc2VydmVyJ3MgYWNjZXNzIGxvZykgYXMgd2VsbCBhcwogICByZWFsLXRpbWUgb3IgbmVh ci1yZWFsIHRpbWUgZXZlbnRzIGJlZm9yZSwgZHVyaW5nIG9yIGFmdGVyIGNvbnRlbnQKICAgZGVs aXZlcnkgYW5kIG9wZXJhdGlvbnMgYW5kIGRpYWdub3N0aWMgbWVzc2FnZXMuCgogICBTZXZlcmFs IHByb3RvY29scyBhbHJlYWR5IGV4aXN0IHRoYXQgY291bGQgcG90ZW50aWFsbHkgYmUgdXNlZCB0 bwogICBleGNoYW5nZSBDRE5JIGxvZ3MgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zIGluY2x1 ZGluZyBTTk1QLAogICBzeXNsb2csIGZ0cCAoYW5kIHNlY3VyZSB2YXJpYW50cyksIHNjcCwgSFRU UCBQT1NULCBldGMuCgo0LjQuICBDRE5JIENvbnRyb2wgSW50ZXJmYWNlCgogICBUaGUgQ0ROSSBD b250cm9sIGludGVyZmFjZSBhbGxvd3MgdGhlIENvbnRyb2wgU3lzdGVtIGluCiAgIGludGVyY29u bmVjdGVkIENETnMgdG8gY29tbXVuaWNhdGUuICBUaGUgZXhhY3QgaW50ZXItQ0ROIGNvbnRyb2wK ICAgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlIENETkkgQ29u dHJvbCBpbnRlcmZhY2UKICAgaXMgbGVzcyB3ZWxsIGRlZmluZWQgdGhhbiB0aGUgb3RoZXIgdGhy ZWUgQ0ROSSBpbnRlcmZhY2VzIGF0IHRoaXMKICAgdGltZS4KCiAgIEl0IGlzIGV4cGVjdGVkIHRo YXQgZm9yIHRoZSBDb250cm9sIGludGVyZmFjZSwgYXMgZm9yIHRoZSBvdGhlciBDRE5JCiAgIElu dGVyZmFjZXMsIGV4aXN0aW5nIHByb3RvY29scyBjYW4gYmUgcmV1c2VkIG9yIGxldmVyYWdlZC4K Cgo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBtYWtlcyBubyByZXF1 ZXN0IG9mIElBTkEuCgogICBOb3RlIHRvIFJGQyBFZGl0b3I6IHRoaXMgc2VjdGlvbiBtYXkgYmUg cmVtb3ZlZCBvbiBwdWJsaWNhdGlvbiBhcyBhbgogICBSRkMuCgoKNi4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zCgogICBEaXN0cmlidXRpb24gb2YgY29udGVudCBieSBhIENETiBjb21lcyB3aXRo IGEgcmFuZ2Ugb2Ygc2VjdXJpdHkKICAgY29uc2lkZXJhdGlvbnMgc3VjaCBhcyBob3cgdG8gZW5m b3JjZSBjb250cm9sIG9mIGFjY2VzcyB0byB0aGUKICAgY29udGVudCBieSBlbmQgdXNlcnMgaW4g bGluZSB3aXRoIHRoZSBDU1AgcG9saWN5LCBvciBob3cgdG8gdHJ1c3QgdGhlCiAgIGxvZ2dpbmcg aW5mb3JtYXRpb24gZ2VuZXJhdGVkIGJ5IHRoZSBDRE4gZm9yIHRoZSBwdXJwb3NlcyBvZiBjaGFy Z2luZwogICB0aGUgQ1NQLiAgVGhlc2Ugc2VjdXJpdHkgYXNwZWN0cyBhcmUgYWxyZWFkeSBkZWFs dCB3aXRoIGJ5IENETgogICBQcm92aWRlcnMgYW5kIENTUHMgdG9kYXkgaW4gdGhlIGNvbnRleHQg b2Ygc3RhbmRhbG9uZSBDRE5zLiAgSG93ZXZlciwKICAgaW50ZXJjb25uZWN0aW9uIG9mIENETnMg aW50cm9kdWNlcyBhIG5ldyBzZXQgb2Ygc2VjdXJpdHkKICAgY29uc2lkZXJhdGlvbnMgYnkgZXh0 ZW5kaW5nIHRoZSB0cnVzdCBtb2RlbCB0byBhIGNoYWluIG9mIHRydXN0IChpLmUuCiAgIHRoZSBD U1AgInRydXN0cyIgYSBDRE4gdGhhdCAidHJ1c3RzIiBhbm90aGVyIENETikuICBUaGUgbWVjaGFu aXNtcwogICB1c2VkIHRvIG1pdGlnYXRlIHRoZXNlIHJpc2tzIGluIG11bHRpLUNETiBlbnZpcm9u bWVudHMgbWF5IGJlIHNpbWlsYXIKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBO b3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQg ICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEy CgoKICAgdG8gdGhvc2UgdXNlZCBpbiB0aGUgc2luZ2xlIENETiBjYXNlLCBidXQgdGhlaXIgc3Vp dGFiaWxpdHkgaW4gdGhpcwogICBtb3JlIGNvbXBsZXggZW52aXJvbm1lbnQgbXVzdCBiZSB2YWxp ZGF0ZWQuCgogICBNYWludGFpbmluZyB0aGUgc2VjdXJpdHkgb2YgdGhlIGNvbnRlbnQgaXRzZWxm LCBpdHMgYXNzb2NpYXRlZAogICBtZXRhZGF0YSAoaW5jbHVkaW5nIGRlbGl2ZXJ5IHBvbGljaWVz KSBhbmQgdGhlIENETnMgZGlzdHJpYnV0aW5nIGFuZAogICBkZWxpdmVyaW5nIGl0LCBhcmUgY3Jp dGljYWwgcmVxdWlyZW1lbnRzIGZvciBib3RoIENETiBQcm92aWRlcnMgYW5kCiAgIENTUHMgYW5k IHRoZSBDRE4gSW50ZXJjb25uZWN0aW9uIGludGVyZmFjZXMgbXVzdCBwcm92aWRlIHN1ZmZpY2ll bnQKICAgbWVjaGFuaXNtcyB0byBtYWludGFpbiB0aGUgc2VjdXJpdHkgb2YgdGhlIG92ZXJhbGwg c3lzdGVtIG9mCiAgIGludGVyY29ubmVjdGVkIENETnMgYXMgd2VsbCBhcyB0aGUgaW5mb3JtYXRp b24gKGNvbnRlbnQsIG1ldGFkYXRhLAogICBsb2dzLCBldGMpIGRpc3RyaWJ1dGVkIGFuZCBkZWxp dmVyZWQgdGhyb3VnaCBhbnkgc2V0IG9mCiAgIGludGVyY29ubmVjdGVkIENETnMuCgo2LjEuICBT ZWN1cml0eSBvZiB0aGUgQ0ROSSBDb250cm9sIGludGVyZmFjZQoKICAgSW5mb3JtYXRpb24gb24g dGhpcyBpbnRlcmZhY2UgaXMgb2YgYSB2ZXJ5IHByaXZhdGUgbmF0dXJlIGJldHdlZW4KICAgaW50 ZXJjb25uZWN0ZWQgQ0ROcy4gIEEgcGFpciBvZiBDRE5zIHVzZSB0aGlzIGludGVyZmFjZSB0byBh bGxvdwogICBib290c3RyYXBwaW5nIG9mIGFsbCB0aGUgb3RoZXIgQ0ROSSBpbnRlcmZhY2VzIHBv c3NpYmx5IGluY2x1ZGluZwogICBlc3RhYmxpc2htZW50IG9mIHRoZSBtZWNoYW5pc21zIGZvciBz ZWN1cmluZyB0aGVzZSBpbnRlcmZhY2VzLgogICBUaGVyZWZvcmUsIGNvcnJ1cHRpb24gb2YgdGhh dCBpbnRlcmZhY2UgbWF5IHJlc3VsdCBpbiBjb3JydXB0aW9uIG9mCiAgIGFsbCBvdGhlciBpbnRl cmZhY2VzLiAgVXNpbmcgdGhpcyBpbnRlcmZhY2UsIGFuIHVwc3RyZWFtIENETiBtYXkgcHJlLQog ICBwb3NpdGlvbiBvciBkZWxldGUgY29udGVudCBvciBtZXRhZGF0YSBpbiBhIGRvd25zdHJlYW0g Q0ROIGFuZCBhCiAgIGRvd25zdHJlYW0gQ0ROIG1heSBwcm92aWRlIGFkbWluaXN0cmF0aXZlIGlu Zm9ybWF0aW9uIHRvIGFuIHVwc3RyZWFtCiAgIENETiwgZXRjLiAgQWxsIG9mIHRoZXNlIG9wZXJh dGlvbnMgcmVxdWlyZSB0aGF0IHRoZSBwZWVyIENETnMgYXJlCiAgIGFwcHJvcHJpYXRlbHkgYXV0 aGVudGljYXRlZCBhbmQgdGhhdCB0aGUgY29uZmlkZW50aWFsaXR5IGFuZAogICBpbnRlZ3JpdHkg b2YgaW5mb3JtYXRpb24gZmxvd2luZyBiZXR3ZWVuIHRoZW0gY2FuIGJlIGVuc3VyZWQuCgo2LjIu ICBTZWN1cml0eSBvZiB0aGUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcgSW50ZXJmYWNlCgogICBBcHBy b3ByaWF0ZSBsZXZlbHMgb2YgYXV0aGVudGljYXRpb24gYW5kIGNvbmZpZGVudGlhbGl0eSBtdXN0 IGJlIHVzZWQKICAgaW4gdGhpcyBpbnRlcmZhY2UgYmVjYXVzZSBpdCBhbGxvd3MgYW4gdXBzdHJl YW0gQ0ROIHRvIHF1ZXJ5IHRoZQogICBkb3duc3RyZWFtIENETiBpbiBvcmRlciB0byByZWRpcmVj dCByZXF1ZXN0cywgYW5kIGNvbnZlcnNlbHksIGFsbG93cwogICB0aGUgZG93bnN0cmVhbSBDRE4g dG8gaW5mbHVlbmNlIHRoZSB1cHN0cmVhbSBDRE4ncyBSZXF1ZXN0IFJvdXRpbmcKICAgZnVuY3Rp b24uCgogICBJbiB0aGUgYWJzZW5jZSBvZiBhcHByb3ByaWF0ZSBzZWN1cml0eSBvbiB0aGlzIGlu dGVyZmFjZSwgYSByb2d1ZQogICB1cHN0cmVhbSBDRE4gY291bGQgaW51bmRhdGUgZG93bnN0cmVh bSBDRE5zIHdpdGggYm9ndXMgcmVxdWVzdHMsIG9yCiAgIGhhdmUgdGhlIGRvd25zdHJlYW0gQ0RO IHNlbmQgdGhlIHJvZ3VlIHVwc3RyZWFtIENETiBwcml2YXRlCiAgIGluZm9ybWF0aW9uLiAgQWxz bywgYSByb2d1ZSBkb3duc3RyZWFtIENETiBjb3VsZCBpbmZsdWVuY2UgdGhlCiAgIHVwc3RyZWFt IENETiBzbyB0aGUgdXBzdHJlYW0gQ0ROIHJlZGlyZWN0cyByZXF1ZXN0cyB0byB0aGUgcm9ndWUg ZENETgogICBvciBhbm90aGVyIGRDRE4gaW4gb3JkZXIgdG8sIGZvciBleGFtcGxlLCBhdHRyYWN0 IGFkZGl0aW9uYWwgZGVsaXZlcnkKICAgcmV2ZW51ZS4KCjYuMy4gIFNlY3VyaXR5IG9mIHRoZSBD RE5JIE1ldGFkYXRhIGludGVyZmFjZQoKICAgVGhpcyBpbnRlcmZhY2UgYWxsb3dzIGEgZG93bnN0 cmVhbSBDRE4gdG8gcmVxdWVzdCBDRE5JIG1ldGFkYXRhIGZyb20KICAgYW4gdXBzdHJlYW0gQ0RO LCBhbmQgdGhlcmVmb3JlIHRoZSB1cHN0cmVhbSBDRE4gbXVzdCBlbnN1cmUgdGhhdCB0aGUKICAg Zm9ybWVyIGlzIGFwcHJvcHJpYXRlbHkgYXV0aGVudGljYXRlZCBiZWZvcmUgc2VuZGluZyB0aGUg ZGF0YS4KICAgQ29udmVyc2VseSwgYSBkb3duc3RyZWFtIENETiBtdXN0IGF1dGhlbnRpY2F0ZSBh biB1cHN0cmVhbSBDRE4gYmVmb3JlCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAgIEV4cGlyZXMg Tm92ZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0 ICAgIENETiBJbnRlcmNvbm5lY3Rpb24gUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgQXByaWwgMjAx MgoKCiAgIHJlcXVlc3RpbmcgbWV0YWRhdGEgdG8gaW5zdWxhdGUgaXRzZWxmIGZyb20gcG9pc29u aW5nIGJ5IHJvZ3VlCiAgIHVwc3RyZWFtIENETnMuICBUaGUgY29uZmlkZW50aWFsaXR5IGFuZCBp bnRlZ3JpdHkgb2YgdGhlIGluZm9ybWF0aW9uCiAgIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZSBwZWVy cyBtdXN0IGJlIHByb3RlY3RlZC4KCjYuNC4gIFNlY3VyaXR5IG9mIHRoZSBDRE5JIExvZ2dpbmcg aW50ZXJmYWNlCgogICBMb2dnaW5nIGRhdGEgY29uc2lzdHMgb2YgcG90ZW50aWFsbHkgc2Vuc2l0 aXZlIGluZm9ybWF0aW9uICh3aGljaCBlbmQKICAgdXNlciBhY2Nlc3NlZCB3aGljaCBtZWRpYSBy ZXNvdXJjZSwgSVAgYWRkcmVzc2VzIG9mIGVuZCB1c2VycywKICAgcG90ZW50aWFsIG5hbWVzIGFu ZCBzdWJzY3JpYmVyIGFjY291bnQgaW5mb3JtYXRpb24sIGV0Yy4pLgogICBDb25maWRlbnRpYWxp dHkgb2YgdGhpcyBpbmZvcm1hdGlvbiBtdXN0IGJlIHByb3RlY3RlZCBhcyBsb2cgcmVjb3Jkcwog ICBhcmUgbW92ZWQgYmV0d2VlbiBDRE5zLiAgVGhpcyBpbmZvcm1hdGlvbiBtYXkgYWxzbyBiZSBz ZW5zaXRpdmUgZnJvbQogICB0aGUgdmlld3BvaW50IHRoYXQgaXQgY2FuIGJlIHRoZSBiYXNpcyBm b3IgY2hhcmdpbmcgYWNyb3NzIENETnMuCiAgIFRoZXJlZm9yZSwgYXBwcm9wcmlhdGUgbGV2ZWxz IG9mIHByb3RlY3Rpb24gYXJlIG5lZWRlZCBhZ2FpbnN0CiAgIGNvcnJ1cHRpb24sIGR1cGxpY2F0 aW9uIGFuZCBsb3NzIG9mIHRoaXMgaW5mb3JtYXRpb24uCgoKNy4gIEFja25vd2xlZGdlbWVudHMK CiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgQW5kcmUgQmVjaywgR2lsbGVzIEJl cnRyYW5kLCBNYXJrCiAgIENhcmxzb24sIEJydWNlIERhdmllLCBEYXZpZCBGZXJndXNvbiwgWWl1 IExlZSwgS2VudCBMZXVuZywgV2lsbCBMaSwKICAgS2V2aW4gTWEsIEp1bGllbiBNYWlzb25uZXV2 ZSwgR3V5IE1lYWRvciwgRW1pbGUgU3RlcGhhbiwgT3NrYXIgdmFuCiAgIERldmVudGVyLCBNYWhl c2ggVml2ZWdhbmFuZGhhbiBhbmQgUmljaGFyZCBXb3VuZHkgZm9yIHRoZWlyIHJldmlldwogICBj b21tZW50cyBhbmQgY29udHJpYnV0aW9ucyB0byB0aGUgdGV4dC4KCgo4LiAgUmVmZXJlbmNlcwoK OC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCjguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMK CiAgIFszR1AtREFTSF0KICAgICAgICAgICAgICAiVHJhbnNwYXJlbnQgZW5kLXRvLWVuZCBQYWNr ZXQtc3dpdGNoZWQgU3RyZWFtaW5nIFNlcnZpY2UKICAgICAgICAgICAgICAoUFNTKTsgUHJvZ3Jl c3NpdmUgRG93bmxvYWQgYW5kIER5bmFtaWMgQWRhcHRpdmUgU3RyZWFtaW5nCiAgICAgICAgICAg ICAgb3ZlciBIVFRQICgzR1AtREFTSCkKICAgICAgICAgICAgICBodHRwOi8vd3d3LjNncHAub3Jn L2Z0cC9TcGVjcy9odG1sLWluZm8vMjYyNDcuaHRtIi4KCiAgIFtBTFRPLUNoYXJ0ZXJdCiAgICAg ICAgICAgICAgIklFVEYgQUxUTyBXRyBDaGFydGVyCiAgICAgICAgICAgICAgKGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy93Zy9hbHRvL2NoYXJ0ZXIvKSIuCgogICBbQVRJU10gICAgICJBVElT IChodHRwOi8vd3d3LmF0aXMub3JnLykiLgoKICAgW0FUSVMtQ09EXQogICAgICAgICAgICAgICJB VElTIElJRjogSVBUViBDb250ZW50IG9uIERlbWFuZCBTZXJ2aWNlLCBKYW51YXJ5IDIwMTEgKGgK ICAgICAgICAgICAgICB0dHA6Ly93d3cuYXRpcy5vcmcvaWlmL19Db20vRG9jcy9UYXNrX0ZvcmNl cy9BUkNILwogICAgICAgICAgICAgIEFUSVMtMDgwMDA0Mi5wZGYpIi4KCgoKCk5pdmVuLUplbmtp bnMsIGV0IGFsLiAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgIFtQYWdl IDE5XQoMCkludGVybmV0LURyYWZ0ICAgIENETiBJbnRlcmNvbm5lY3Rpb24gUHJvYmxlbSBTdGF0 ZW1lbnQgICAgICAgQXByaWwgMjAxMgoKCiAgIFtDREktQ2hhcnRlcl0KICAgICAgICAgICAgICAi SUVURiBDREkgV0cgQ2hhcnRlcgogICAgICAgICAgICAgIChodHRwOi8vd3d3LmlldGYub3JnL3dn L2NvbmNsdWRlZC9jZGkpIi4KCiAgIFtDYWJsZUxhYnNdCiAgICAgICAgICAgICAgIkNhYmxlTGFi cyAoaHR0cDovL3d3dy5jYWJsZWxhYnMuY29tL2Fib3V0LykiLgoKICAgW0NhYmxlTGFicy1NZXRh ZGF0YV0KICAgICAgICAgICAgICAiQ2FibGVMYWJzIFZvRCBNZXRhZGF0YSBQcm9qZWN0IFByaW1l cgogICAgICAgICAgICAgIChodHRwOi8vd3d3LmNhYmxlbGFicy5jb20vcHJvamVjdHMvbWV0YWRh dGEvcHJpbWVyLykiLgoKICAgW0RFQ0FERS1DaGFydGVyXQogICAgICAgICAgICAgICJJRVRGIERF Q0FERSBXRyBDaGFydGVyCiAgICAgICAgICAgICAgKGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy93Zy9kZWNhZGUvY2hhcnRlci8pIi4KCiAgIFtJLUQuYmVydHJhbmQtY2RuaS1leHBlcmltZW50 c10KICAgICAgICAgICAgICBGYXVjaGV1ciwgRi4gYW5kIEwuIFBldGVyc29uLCAiQ29udGVudCBE aXN0cmlidXRpb24KICAgICAgICAgICAgICBOZXR3b3JrIEludGVyY29ubmVjdGlvbiAoQ0ROSSkg RXhwZXJpbWVudHMiLAogICAgICAgICAgICAgIGRyYWZ0LWJlcnRyYW5kLWNkbmktZXhwZXJpbWVu dHMtMDIgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIEZlYnJ1YXJ5IDIwMTIuCgog ICBbSS1ELmlldGYtY2RuaS11c2UtY2FzZXNdCiAgICAgICAgICAgICAgR2lsbGVzLCBCLiwgV2F0 c29uLCBHLiwgTWEsIEsuLCBFYXJkbGV5LCBQLiwgRW1pbGUsIFMuLAogICAgICAgICAgICAgIGFu ZCBULiBCdXJicmlkZ2UsICJVc2UgQ2FzZXMgZm9yIENvbnRlbnQgRGVsaXZlcnkgTmV0d29yawog ICAgICAgICAgICAgIEludGVyY29ubmVjdGlvbiIsIGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMt MDMgKHdvcmsgaW4KICAgICAgICAgICAgICBwcm9ncmVzcyksIEphbnVhcnkgMjAxMi4KCiAgIFtJ LUQuamVua2lucy1hbHRvLWNkbi11c2UtY2FzZXNdCiAgICAgICAgICAgICAgUHJldmlkaSwgUy4s IFdhdHNvbiwgRy4sIE1lZHZlZCwgSi4sIEJpdGFyLCBOLiwgYW5kIEIuCiAgICAgICAgICAgICAg Tml2ZW4tSmVua2lucywgIlVzZSBDYXNlcyBmb3IgQUxUTyB3aXRoaW4gQ0ROcyIsCiAgICAgICAg ICAgICAgZHJhZnQtamVua2lucy1hbHRvLWNkbi11c2UtY2FzZXMtMDIgKHdvcmsgaW4gcHJvZ3Jl c3MpLAogICAgICAgICAgICAgIERlY2VtYmVyIDIwMTEuCgogICBbTVBFRy1EQVNIXQogICAgICAg ICAgICAgICJJbmZvcm1hdGlvbiB0ZWNobm9sb2d5IC0gTVBFRyBzeXN0ZW1zIHRlY2hub2xvZ2ll cyAtIFBhcnQKICAgICAgICAgICAgICA2OiBEeW5hbWljIGFkYXB0aXZlIHN0cmVhbWluZyBvdmVy IEhUVFAgKERBU0gpLCAoRElTCiAgICAgICAgICAgICAgdmVyc2lvbiksIEZlYnJ1YXJ5IDIwMTEK ICAgICAgICAgICAgICBodHRwOi8vbXBlZy5jaGlhcmlnbGlvbmUub3JnLwogICAgICAgICAgICAg IHdvcmtpbmdfZG9jdW1lbnRzLmh0bSNNUEVHLUIiLgoKICAgW09JUEYtT3ZlcnZpZXddCiAgICAg ICAgICAgICAgIk9JUEYgUmVsZWFzZSAyIFNwZWNpZmljYXRpb24gVm9sdW1lIDEgLSBPdmVydmll dyIsCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMTAuCgogICBbUDJQUkctQ0ROSV0KICAgICAg ICAgICAgICBEYXZpZSwgQi4gYW5kIEYuIExlIEZhdWNoZXVyLCAiSW50ZXJjb25uZWN0aW5nIENE TnMgYWthCiAgICAgICAgICAgICAgIlBlZXJpbmcgUGVlci10by1QZWVyIgogICAgICAgICAgICAg IChodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzc3L3NsaWRlcy9QMlBSRy0yLnBkZiki LAoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMTIgICAg ICAgICAgICAgICBbUGFnZSAyMF0KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4gSW50ZXJjb25uZWN0 aW9uIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgogICAgICAgICAgICAgIE1h cmNoIDIwMTAuCgogICBbUFBTUC1DaGFydGVyXQogICAgICAgICAgICAgICJJRVRGIFBQU1AgV0cg Q2hhcnRlcgogICAgICAgICAgICAgIChodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvcHBz cC9jaGFydGVyLykiLgoKICAgW1JGQzI2MTZdICBGaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1v Z3VsLCBKLiwgRnJ5c3R5aywgSC4sCiAgICAgICAgICAgICAgTWFzaW50ZXIsIEwuLCBMZWFjaCwg UC4sIGFuZCBULiBCZXJuZXJzLUxlZSwgIkh5cGVydGV4dAogICAgICAgICAgICAgIFRyYW5zZmVy IFByb3RvY29sIC0tIEhUVFAvMS4xIiwgUkZDIDI2MTYsIEp1bmUgMTk5OS4KCiAgIFtSRkMzMDQw XSAgQ29vcGVyLCBJLiwgTWVsdmUsIEkuLCBhbmQgRy4gVG9tbGluc29uLCAiSW50ZXJuZXQgV2Vi CiAgICAgICAgICAgICAgUmVwbGljYXRpb24gYW5kIENhY2hpbmcgVGF4b25vbXkiLCBSRkMgMzA0 MCwgSmFudWFyeSAyMDAxLgoKICAgW1JGQzM0NjZdICBEYXksIE0uLCBDYWluLCBCLiwgVG9tbGlu c29uLCBHLiwgYW5kIFAuIFJ6ZXdza2ksICJBIE1vZGVsCiAgICAgICAgICAgICAgZm9yIENvbnRl bnQgSW50ZXJuZXR3b3JraW5nIChDREkpIiwgUkZDIDM0NjYsCiAgICAgICAgICAgICAgRmVicnVh cnkgMjAwMy4KCiAgIFtSRkMzNTY4XSAgQmFyYmlyLCBBLiwgQ2FpbiwgQi4sIE5haXIsIFIuLCBh bmQgTy4gU3BhdHNjaGVjaywgIktub3duCiAgICAgICAgICAgICAgQ29udGVudCBOZXR3b3JrIChD TikgUmVxdWVzdC1Sb3V0aW5nIE1lY2hhbmlzbXMiLAogICAgICAgICAgICAgIFJGQyAzNTY4LCBK dWx5IDIwMDMuCgogICBbUkZDMzU3MF0gIFJ6ZXdza2ksIFAuLCBEYXksIE0uLCBhbmQgRC4gR2ls bGV0dGksICJDb250ZW50CiAgICAgICAgICAgICAgSW50ZXJuZXR3b3JraW5nIChDREkpIFNjZW5h cmlvcyIsIFJGQyAzNTcwLCBKdWx5IDIwMDMuCgogICBbUkZDNTAyM10gIEdyZWdvcmlvLCBKLiBh bmQgQi4gZGUgaE9yYSwgIlRoZSBBdG9tIFB1Ymxpc2hpbmcKICAgICAgICAgICAgICBQcm90b2Nv bCIsIFJGQyA1MDIzLCBPY3RvYmVyIDIwMDcuCgogICBbUkZDNjEyMF0gIFNhaW50LUFuZHJlLCBQ LiwgIkV4dGVuc2libGUgTWVzc2FnaW5nIGFuZCBQcmVzZW5jZQogICAgICAgICAgICAgIFByb3Rv Y29sIChYTVBQKTogQ29yZSIsIFJGQyA2MTIwLCBNYXJjaCAyMDExLgoKICAgW1NOSUEtQ0RNSV0K ICAgICAgICAgICAgICAiU05JQSBDRE1JIChodHRwOi8vd3d3LnNuaWEub3JnL3RlY2hfYWN0aXZp dGllcy9zdGFuZGFyZHMvCiAgICAgICAgICAgICAgY3Vycl9zdGFuZGFyZHMvY2RtaSkiLgoKICAg W1RBWE9OT01ZXQogICAgICAgICAgICAgIFBhdGhhbiwgQS4sICJBIFRheG9ub215IGFuZCBTdXJ2 ZXkgb2YgQ29udGVudCBEZWxpdmVyeQogICAgICAgICAgICAgIE5ldHdvcmtzCiAgICAgICAgICAg ICAgKGh0dHA6Ly93d3cuZ3JpZGJ1cy5vcmcvcmVwb3J0cy9DRE4tVGF4b25vbXkucGRmKSIsIDIw MDcuCgogICBbWS4xOTEwXSAgICJJVFUtVCBSZWNvbWVuZGF0aW9uIFkuMTkxMCAiSVBUViBmdW5j dGlvbmFsCiAgICAgICAgICAgICAgYXJjaGl0ZWN0dXJlIiIsIFNlcHRlbWJlciAyMDA4LgoKICAg W1kuMjAxOV0gICAiSVRVLVQgUmVjb21lbmRhdGlvbiBZLjIwMTkgIkNvbnRlbnQgZGVsaXZlcnkg ZnVuY3Rpb25hbAogICAgICAgICAgICAgIGFyY2hpdGVjdHVyZSBpbiBOR04iIiwgU2VwdGVtYmVy IDIwMTAuCgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEs IDIwMTIgICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4gSW50 ZXJjb25uZWN0aW9uIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgpBcHBlbmRp eCBBLiAgRGVzaWduIGNvbnNpZGVyYXRpb25zIGZvciByZWFsaXppbmcgdGhlIENETkkgSW50ZXJm YWNlcwoKICAgVGhpcyBzZWN0aW9uIGV4cGFuZHMgb24gaG93IENETkkgaW50ZXJmYWNlcyBjYW4g cmV1c2UgYW5kIGxldmVyYWdlCiAgIGV4aXN0aW5nIHByb3RvY29scyBiZWZvcmUgZGVzY3JpYmlu ZyBlYWNoIENETkkgaW50ZXJmYWNlIGluZGl2aWR1YWxseQogICBhbmQgaGlnaGxpZ2h0aW5nIGV4 YW1wbGUgY2FuZGlkYXRlIHByb3RvY29scyB0aGF0IGNvdWxkIGJlIGNvbnNpZGVyZWQKICAgZm9y IHJldXNlIG9yIGxldmVyYWdpbmcgdG8gaW1wbGVtZW50IHRoZSBDRE5JIGludGVyZmFjZXMuCgpB LjEuICBDRE5JIFJlcXVlc3QgUm91dGluZyBJbnRlcmZhY2UKCiAgIFRoZSBDRE5JIFJlcXVlc3Qg Um91dGluZyBpbnRlcmZhY2UgZW5hYmxlcyBhIFJlcXVlc3QgUm91dGluZyBmdW5jdGlvbgogICBp biBhbiB1cHN0cmVhbSBDRE4gdG8gcXVlcnkgYSBSZXF1ZXN0IFJvdXRpbmcgZnVuY3Rpb24gaW4g YQogICBkb3duc3RyZWFtIENETiB0byBkZXRlcm1pbmUgaWYgdGhlIGRvd25zdHJlYW0gQ0ROIGlz IGFibGUgKGFuZAogICB3aWxsaW5nKSB0byBhY2NlcHQgdGhlIGRlbGVnYXRlZCBjb250ZW50IHJl cXVlc3QgYW5kIHRvIGFsbG93IHRoZQogICBkb3duc3RyZWFtIENETiB0byBjb250cm9sIHdoYXQg dGhlIHVwc3RyZWFtIFJlcXVlc3QgUm91dGluZyBmdW5jdGlvbgogICBzaG91bGQgcmV0dXJuIHRv IHRoZSBVc2VyIEFnZW50IGluIHRoZSByZWRpcmVjdGlvbiBtZXNzYWdlLgoKICAgVGhlcmVmb3Jl LCB0aGUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcgaW50ZXJmYWNlIG5lZWRzIHRvIG9mZmVyIGEKICAg bWVjaGFuaXNtIGZvciBhbiB1cHN0cmVhbSBDRE4gdG8gaXNzdWUgYSAiUmVkaXJlY3Rpb24gUmVx dWVzdCIgdG8gYQogICBkb3duc3RyZWFtIENETi4gIFRoZSBSZXF1ZXN0IFJvdXRpbmcgaW50ZXJm YWNlIG5lZWRzIHRvIGJlIGFibGUgdG8KICAgc3VwcG9ydCBzY2VuYXJpb3Mgd2hlcmUgdGhlIGlu aXRpYWwgVXNlciBBZ2VudCByZXF1ZXN0IHRvIHRoZQogICB1cHN0cmVhbSBDRE4gaXMgcmVjZWl2 ZWQgb3ZlciBETlMgYXMgd2VsbCBhcyBvdmVyIGEgY29udGVudCBzcGVjaWZpYwogICBhcHBsaWNh dGlvbiBwcm90b2NvbCAoZS5nLiAgSFRUUCwgUlRTUCwgUlRNUCwgZXRjLikuCgogICBUaGVyZWZv cmUgYSBSZWRpcmVjdGlvbiBSZXF1ZXN0IGlzIGV4cGVjdGVkIHRvIGNvbnRhaW4gaW5mb3JtYXRp b24KICAgc3VjaCBhczoKCiAgIG8gIFRoZSBwcm90b2NvbCAoZS5nLiAgRE5TLCBIVFRQKSBvdmVy IHdoaWNoIHRoZSB1cHN0cmVhbSBDRE4KICAgICAgcmVjZWl2ZWQgdGhlIGluaXRpYWwgVXNlciBB Z2VudCByZXF1ZXN0LgogICBvICBBZGRpdGlvbmFsIGRldGFpbHMgb2YgdGhlIFVzZXIgQWdlbnQg cmVxdWVzdCB0aGF0IGFyZSByZXF1aXJlZCB0bwogICAgICBwZXJmb3JtIGVmZmVjdGl2ZSBSZXF1 ZXN0IFJvdXRpbmcgYnkgdGhlIERvd25zdHJlYW0gQ0ROLiAgRm9yIEROUwogICAgICB0aGlzIHdv dWxkIHR5cGljYWxseSBiZSB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgRE5TIHJlc29sdmVyIG1ha2lu ZwogICAgICB0aGUgcmVxdWVzdCBvbiBiZWhhbGYgb2YgdGhlIFVzZXIgQWdlbnQuICBGb3IgcmVx dWVzdHMgcmVjZWl2ZWQKICAgICAgb3ZlciBjb250ZW50IHNwZWNpZmljIGFwcGxpY2F0aW9uIHBy b3RvY29scyB0aGUgUmVkaXJlY3Rpb24KICAgICAgUmVxdWVzdCBjb3VsZCBjb250YWluIHNpZ25p ZmljYW50bHkgbW9yZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvCiAgICAgIHRoZSBvcmlnaW5hbCBV c2VyIEFnZW50IHJlcXVlc3QgYnV0IGF0IGEgbWluaW11bSBpcyBleHBlY3RlZCB0bwogICAgICBp bmNsdWRlIHRoZSBVc2VyIEFnZW50J3MgSVAgYWRkcmVzcywgdGhlIGVxdWl2YWxlbnQgb2YgdGhl IEhUVFAKICAgICAgSG9zdCBoZWFkZXIgYW5kIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBIVFRQIGFi c19wYXRoIGRlZmluZWQgaW4KICAgICAgW1JGQzI2MTZdLgoKICAgSXQgc2hvdWxkIGJlIG5vdGVk IHRoYXQsIHRoZSBDRE5JIGFyY2hpdGVjdHVyZSBuZWVkcyB0byBjb25zaWRlciB0aGF0CiAgIGEg ZG93bnN0cmVhbSBDRE4gbWF5IHJlY2VpdmUgcmVxdWVzdHMgZnJvbSBVc2VyIEFnZW50cyB3aXRo b3V0IGZpcnN0CiAgIHJlY2VpdmluZyBhIFJlZGlyZWN0aW9uIFJlcXVlc3QgZnJvbSBhbiB1cHN0 cmVhbSBDRE4gZm9yIHRoZQogICBjb3JyZXNwb25kaW5nIFVzZXIgQWdlbnQgcmVxdWVzdCwgZm9y IGV4YW1wbGUgYmVjYXVzZToKCiAgIG8gIFVzZXIgQWdlbnRzIChvciBETlMgcmVzb2x2ZXJzKSBt YXkgY2FjaGUgRE5TIG9yIGFwcGxpY2F0aW9uCiAgICAgIHJlc3BvbnNlcyBmcm9tIFJlcXVlc3Qg Um91dGVycy4KCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEs IDIwMTIgICAgICAgICAgICAgICBbUGFnZSAyMl0KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4gSW50 ZXJjb25uZWN0aW9uIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgogICBvICBS ZXNwb25zZXMgdG8gUmVkaXJlY3Rpb24gUmVxdWVzdHMgb3ZlciB0aGUgUmVxdWVzdCBSb3V0aW5n CiAgICAgIGludGVyZmFjZSBtYXkgYmUgY2FjaGVhYmxlLgogICBvICBTb21lIENETnMgbWF5IHJl bHkgb24gc2ltcGxlIGNvYXJzZSBwb2xpY2llcywgZS5nLiAgQ0ROIEIgYWdyZWVzCiAgICAgIHRv IGFsd2F5cyBzZXJ2ZSBDRE4gQSdzIGRlbGVnYXRlZCByZWRpcmVjdGlvbiByZXF1ZXN0cywgaW4g d2hpY2gKICAgICAgY2FzZSB0aGUgbmVjZXNzYXJ5IHJlZGlyZWN0aW9uIGRldGFpbHMgYXJlIGV4 Y2hhbmdlZCBvdXQgb2YgYmFuZAogICAgICAob2YgdGhlIENETkkgaW50ZXJmYWNlcyksIGUuZy4g Y29uZmlndXJlZC4KCiAgIE9uIHJlY2VpdmluZyBhIFJlZGlyZWN0aW9uIFJlcXVlc3QsIHRoZSBk b3duc3RyZWFtIENETiB3aWxsIHVzZSB0aGUKICAgaW5mb3JtYXRpb24gcHJvdmlkZWQgaW4gdGhl IHJlcXVlc3QgdG8gZGV0ZXJtaW5lIGlmIGl0IGlzIGFibGUgKGFuZAogICB3aWxsaW5nKSB0byBh Y2NlcHQgdGhlIGRlbGVnYXRlZCBjb250ZW50IHJlcXVlc3QgYW5kIG5lZWRzIHRvIHJldHVybgog ICB0aGUgcmVzdWx0IG9mIGl0cyBkZWNpc2lvbiB0byB0aGUgdXBzdHJlYW0gQ0ROLgoKICAgVGh1 cywgYSBSZWRpcmVjdGlvbiBSZXNwb25zZSBmcm9tIHRoZSBkb3duc3RyZWFtIENETiBpcyBleHBl Y3RlZCB0bwogICBjb250YWluIGluZm9ybWF0aW9uIHN1Y2ggYXM6CgogICBvICBTdGF0dXMgY29k ZSBpbmRpY2F0aW5nIGFjY2VwdGFuY2Ugb3IgcmVqZWN0aW9uIChwb3NzaWJseSB3aXRoCiAgICAg IGFjY29tcGFueWluZyByZWFzb25zKS4KICAgbyAgSW5mb3JtYXRpb24gdG8gYWxsb3cgcmVkaXJl Y3Rpb24gYnkgdGhlIFVwc3RyZWFtIENETi4gIEluIHRoZSBjYXNlCiAgICAgIG9mIEROUy1iYXNl ZCByZXF1ZXN0IHJvdXRpbmcsIHRoaXMgaXMgZXhwZWN0ZWQgdG8gaW5jbHVkZSB0aGUKICAgICAg ZXF1aXZhbGVudCBvZiBhIEROUyByZWNvcmQocykgKGUuZy4gYSBDTkFNRSkgdGhhdCB0aGUgdXBz dHJlYW0gQ0ROCiAgICAgIHNob3VsZCByZXR1cm4gdG8gdGhlIHJlcXVlc3RpbmcgRE5TIHJlc29s dmVyLiAgSW4gdGhlIGNhc2Ugb2YKICAgICAgYXBwbGljYXRpb24gYmFzZWQgcmVxdWVzdCByb3V0 aW5nLCB0aGlzIGlzIGV4cGVjdGVkIHRvIGluY2x1ZGUgdGhlCiAgICAgIGluZm9ybWF0aW9uIG5l Y2Vzc2FyeSB0byBjb25zdHJ1Y3QgdGhlIGFwcGxpY2F0aW9uIHNwZWNpZmljCiAgICAgIHJlZGly ZWN0aW9uIHJlc3BvbnNlKHMpIHRvIHJldHVybiB0byB0aGUgcmVxdWVzdGluZyBVc2VyIEFnZW50 LgogICAgICBGb3IgSFRUUCByZXF1ZXN0cyBmcm9tIFVzZXIgQWdlbnRzIHRoaXMgY291bGQgaW5j bHVkZSBhIFVSSSB0aGF0CiAgICAgIHRoZSB1cHN0cmVhbSBDRE4gY291bGQgcmV0dXJuIGluIGEg SFRUUCAzeHggcmVzcG9uc2UuCgogICBUaGUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcgaW50ZXJmYWNl IGlzIHRoZXJlZm9yZSBhIGZhaXJseQogICBzdHJhaWdodGZvcndhcmQgcmVxdWVzdC9yZXNwb25z ZSBpbnRlcmZhY2UgYW5kIGNvdWxkIGJlIGltcGxlbWVudGVkCiAgIG92ZXIgYW55IG51bWJlciBv ZiByZXF1ZXN0L3Jlc3BvbnNlIHByb3RvY29scy4gIEZvciBleGFtcGxlLCBpdCBtYXkKICAgYmUg aW1wbGVtZW50ZWQgYXMgYSBXZWJTZXJ2aWNlIHVzaW5nIG9uZSBvZiB0aGUgY29tbW9uIFdlYlNl cnZpY2VzCiAgIG1ldGhvZG9sb2dpZXMgKFhNTC1SUEMsIEhUVFAgcXVlcnkgdG8gYSBrbm93biBV UkksIGV0Yy4pLiAgVGhpcwogICByZW1vdmVzIHRoZSBuZWVkIGZvciB0aGUgQ0ROSSB3b3JraW5n IGdyb3VwIHRvIGRlZmluZSBhIG5ldyBwcm90b2NvbAogICBmb3IgdGhlIHJlcXVlc3QvcmVzcG9u c2UgZWxlbWVudCBvZiB0aGUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcKICAgaW50ZXJmYWNlLiAgVGh1 cywgdGhlIENETkkgd29ya2luZyBncm91cCB3b3VsZCBiZSBsZWZ0IG9ubHkgd2l0aCB0aGUKICAg dGFzayBvZiBzcGVjaWZ5aW5nOgoKICAgbyAgVGhlIHJlY29tbWVuZGVkIHJlcXVlc3QvcmVzcG9u c2UgcHJvdG9jb2wgdG8gdXNlIGFsb25nIHdpdGggYW55CiAgICAgIGFkZGl0aW9uYWwgc2VtYW50 aWNzIGFuZCBwcm9jZWR1cmVzIHRoYXQgYXJlIHNwZWNpZmljIHRvIHRoZSBDRE5JCiAgICAgIFJl cXVlc3QgUm91dGluZyBpbnRlcmZhY2UgKGUuZy4gaGFuZGxpbmcgb2YgbWFsZm9ybWVkIHJlcXVl c3RzLwogICAgICByZXNwb25zZXMpLgogICBvICBUaGUgc3ludGF4IChpLmUgcmVwcmVzZW50YXRp b24vZW5jb2RpbmcpIG9mIHRoZSByZWRpcmVjdGlvbgogICAgICByZXF1ZXN0cyBhbmQgcmVzcG9u c2VzLgogICBvICBUaGUgc2VtYW50aWNzIChpLmUuIG1lYW5pbmcgYW5kIGV4cGVjdGVkIGNvbnRl bnRzKSBvZiB0aGUKICAgICAgcmVkaXJlY3Rpb24gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcy4KCiAg IEFkZGl0aW9uYWxseSwgYXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gMywgdGhlIENETkkgUmVxdWVz dCBSb3V0aW5nCiAgIGludGVyZmFjZSBpcyBhbHNvIGV4cGVjdGVkIHRvIGVuYWJsZSBhIGRvd25z dHJlYW0gQ0ROIHRvIHByb3ZpZGUgdG8KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJl cyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMjNdCgwKSW50ZXJuZXQtRHJh ZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAy MDEyCgoKICAgdGhlIHVwc3RyZWFtIENETiAoc3RhdGljIG9yIGR5bmFtaWMpIGluZm9ybWF0aW9u IChlLmcuIHJlc291cmNlcywKICAgZm9vdHByaW50LCBsb2FkKSB0byBmYWNpbGl0YXRlIHNlbGVj dGlvbiBvZiB0aGUgZG93bnN0cmVhbSBDRE4gYnkgdGhlCiAgIHVwc3RyZWFtIENETiByZXF1ZXN0 IHJvdXRpbmcgc3lzdGVtIHdoZW4gcHJvY2Vzc2luZyBzdWJzZXF1ZW50CiAgIGNvbnRlbnQgcmVx dWVzdHMgZnJvbSBVc2VyIEFnZW50cy4gIEl0IGlzIGV4cGVjdGVkIHRoYXQgc3VjaAogICBmdW5j dGlvbmFsaXR5IG9mIHRoZSBDRE5JIHJlcXVlc3QgUm91dGluZyBjb3VsZCBiZSBzcGVjaWZpZWQg YnkgdGhlCiAgIENETkkgd29ya2luZyBncm91cCB3aXRoIHNpZ25pZmljYW50IGxldmVyYWdpbmcg b2YgZXhpc3RpbmcgSUVURgogICBwcm90b2NvbHMgc3VwcG9ydGluZyB0aGUgZHluYW1pYyBkaXN0 cmlidXRpb24gb2YgcmVhY2hhYmlsaXR5CiAgIGluZm9ybWF0aW9uIChmb3IgZXhhbXBsZSBieSBs ZXZlcmFnaW5nIGV4aXN0aW5nIHJvdXRpbmcgcHJvdG9jb2xzKSBvcgogICBzdXBwb3J0aW5nIGFw cGxpY2F0aW9uIGxldmVsIHF1ZXJpZXMgZm9yIHRvcG9sb2dpY2FsIGluZm9ybWF0aW9uIChmb3IK ICAgZXhhbXBsZSBieSBsZXZlcmFnaW5nIEFMVE8pLgoKQS4yLiAgQ0ROSSBNZXRhZGF0YSBJbnRl cmZhY2UKCiAgIFRoZSBDRE5JIE1ldGFkYXRhIGludGVyZmFjZSBlbmFibGVzIHRoZSBEaXN0cmli dXRpb24gU3lzdGVtIGluIGEKICAgZG93bnN0cmVhbSBDRE4gdG8gb2J0YWluIENETkkgTWV0YWRh dGEgZnJvbSBhbiB1cHN0cmVhbSBDRE4gc28gdGhhdAogICB0aGUgZG93bnN0cmVhbSBDRE4gY2Fu IHByb3Blcmx5IHByb2Nlc3MgYW5kIHJlc3BvbmQgdG86CgogICBvICBSZWRpcmVjdGlvbiBSZXF1 ZXN0cyByZWNlaXZlZCBvdmVyIHRoZSBDRE5JIFJlcXVlc3QgUm91dGluZwogICAgICBpbnRlcmZh Y2UuCiAgIG8gIENvbnRlbnQgUmVxdWVzdHMgcmVjZWl2ZWQgZGlyZWN0bHkgZnJvbSBVc2VyIEFn ZW50cy4KCiAgIFRoZSBDRE5JIE1ldGFkYXRhIGludGVyZmFjZSBuZWVkcyB0byBvZmZlciBhIG1l Y2hhbmlzbSBmb3IgYW4KICAgVXBzdHJlYW0gQ0ROIHRvOgoKICAgbyAgRGlzdHJpYnV0ZS91cGRh dGUvcmVtb3ZlIENETkkgTWV0YWRhdGEgdG8gYSBEb3duc3RyZWFtIENETi4KCiAgIGFuZC9vciB0 byBhbGxvdyBhIGRvd25zdHJlYW0gQ0ROIHRvOgoKICAgbyAgTWFrZSBkaXJlY3QgcmVxdWVzdHMg Zm9yIENETkkgTWV0YWRhdGEgb2JqZWN0cwogICBvICBNYWtlIHJlY3Vyc2l2ZSByZXF1ZXN0cyBm b3IgQ0ROSSBtZXRhZGF0YSwgZm9yIGV4YW1wbGUgdG8gZW5hYmxlIGEKICAgICAgZG93bnN0cmVh bSBDRE4gdG8gd2FsayBkb3duIGEgdHJlZSBvZiBvYmplY3RzIHdpdGggaW50ZXItb2JqZWN0CiAg ICAgIHJlbGF0aW9uc2hpcHMuCgogICBUaGUgQ0ROSSBNZXRhZGF0YSBpbnRlcmZhY2UgaXMgdGhl cmVmb3JlIHNpbWlsYXIgdG8gdGhlIENETkkgUmVxdWVzdAogICBSb3V0aW5nIGludGVyZmFjZSBi ZWNhdXNlIGl0IGlzIGEgcmVxdWVzdC9yZXNwb25zZSBpbnRlcmZhY2Ugd2l0aCB0aGUKICAgcG90 ZW50aWFsIGFkZGl0aW9uIHRoYXQgQ0ROSSBNZXRhZGF0YSBzZWFyY2ggbWF5IGhhdmUgbW9yZSBj b21wbGV4CiAgIHNlbWFudGljcyB0aGFuIGEgc3RyYWlnaHRmb3J3YXJkIFJlcXVlc3QgUm91dGlu ZyByZWRpcmVjdGlvbiByZXF1ZXN0LgogICBUaGVyZWZvcmUsIGxpa2UgdGhlIENETkkgUmVxdWVz dCBSb3V0aW5nIGludGVyZmFjZSwgdGhlIENETkkgTWV0YWRhdGEKICAgaW50ZXJmYWNlIG1heSBi ZSBpbXBsZW1lbnRlZCBhcyBhIFdlYlNlcnZpY2UgdXNpbmcgb25lIG9mIHRoZSBjb21tb24KICAg V2ViU2VydmljZXMgbWV0aG9kb2xvZ2llcyAoWE1MLVJQQywgSFRUUCBxdWVyeSB0byBhIGtub3du IFVSSSwgZXRjLikKICAgb3IgcG9zc2libHkgdXNpbmcgb3RoZXIgZXhpc3RpbmcgcHJvdG9jb2xz IHN1Y2ggYXMgWE1QUCBbUkZDNjEyMF0uCiAgIFRoaXMgcmVtb3ZlcyB0aGUgbmVlZCBmb3IgdGhl IENETkkgd29ya2luZyBncm91cCB0byBkZWZpbmUgYSBuZXcKICAgcHJvdG9jb2wgZm9yIHRoZSBy ZXF1ZXN0L3Jlc3BvbnNlIGVsZW1lbnQgb2YgdGhlIENETkkgTWV0YWRhdGEKICAgaW50ZXJmYWNl LgoKICAgVGh1cywgdGhlIENETkkgd29ya2luZyBncm91cCB3b3VsZCBiZSBsZWZ0IG9ubHkgd2l0 aCB0aGUgdGFzayBvZgogICBzcGVjaWZ5aW5nOgoKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAg RXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMjRdCgwKSW50ZXJu ZXQtRHJhZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBB cHJpbCAyMDEyCgoKICAgbyAgVGhlIHJlY29tbWVuZGVkIHJlcXVlc3QvcmVzcG9uc2UgcHJvdG9j b2wgdG8gdXNlIGFsb25nIHdpdGggYW55CiAgICAgIGFkZGl0aW9uYWwgc2VtYW50aWNzIHRoYXQg YXJlIHNwZWNpZmljIHRvIHRoZSBDRE5JIE1ldGFkYXRhCiAgICAgIGludGVyZmFjZSAoZS5nLiBo YW5kbGluZyBvZiBtYWxmb3JtZWQgcmVxdWVzdHMvcmVzcG9uc2VzKS4KICAgbyAgVGhlIHN5bnRh eCAoaS5lIHJlcHJlc2VudGF0aW9uL2VuY29kaW5nKSBvZiB0aGUgQ0ROSSBNZXRhZGF0YQogICAg ICBvYmplY3RzIHRoYXQgd2lsbCBiZSBleGNoYW5nZWQgb3ZlciB0aGUgaW50ZXJmYWNlLgogICBv ICBUaGUgc2VtYW50aWNzIChpLmUuIG1lYW5pbmcgYW5kIGV4cGVjdGVkIGNvbnRlbnRzKSBvZiB0 aGUKICAgICAgaW5kaXZpZHVhbCBwcm9wZXJ0aWVzIG9mIGEgTWV0YWRhdGEgb2JqZWN0LgogICBv ICBIb3cgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBkaWZmZXJlbnQgQ0ROSSBNZXRhZGF0YSBv YmplY3RzIGFyZQogICAgICByZXByZXNlbnRlZC4KCkEuMy4gIENETkkgTG9nZ2luZyBJbnRlcmZh Y2UKCiAgIFRoZSBDRE5JIExvZ2dpbmcgaW50ZXJmYWNlIGVuYWJsZXMgZGV0YWlscyBvZiBsb2dz IG9yIGV2ZW50cyB0byBiZQogICBleGNoYW5nZWQgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5z LCB3aGVyZSBldmVudHMgY291bGQgYmU6CgogICBvICBMb2cgcmVjb3JkcyByZWxhdGVkIHRvIHRo ZSBkZWxpdmVyeSBvZiBjb250ZW50IChzaW1pbGFyIHRvIHRoZSBsb2cKICAgICAgcmVjb3JkcyBy ZWNvcmRlZCBpbiBhIHdlYiBzZXJ2ZXIncyBhY2Nlc3MgbG9nKS4KICAgbyAgUmVhbC10aW1lIG9y IG5lYXItcmVhbCB0aW1lIGV2ZW50cyBiZWZvcmUsIGR1cmluZyBvciBhZnRlciBjb250ZW50CiAg ICAgIGRlbGl2ZXJ5LCBlLmcuIGNvbnRlbnQgZGVsaXZlcnkgaW50ZXJydXB0aW9uCiAgIG8gIE9w ZXJhdGlvbnMgYW5kIGRpYWdub3N0aWMgbWVzc2FnZXMuCgogICBXaXRoaW4gQ0ROcyB0b2RheSwg bG9ncyBhbmQgZXZlbnRzIGFyZSB1c2VkIGZvciBhIHZhcmlldHkgb2YgcHVycG9zZXMKICAgaW4g YWRkaXRpb24gdG8gcmVhbC10aW1lIGFuZCBub24gcmVhbC10aW1lIGRpYWdub3N0aWNzIGFuZCBh dWRpdGluZwogICBieSB0aGUgQ0ROIFByb3ZpZGVyIGFuZCBpdHMgY3VzdG9tZXJzLiAgU3BlY2lm aWNhbGx5IENETnMgdXNlIGxvZ3MgdG8KICAgZ2VuZXJhdGUgQ2FsbCBEYXRhIFJlY29yZHMgKENE UnMpIGZvciBwYXNzaW5nIHRvIGJpbGxpbmcgYW5kIHBheW1lbnQKICAgc3lzdGVtcyBhbmQgdG8g cmVhbC10aW1lIChhbmQgbmVhciByZWFsLXRpbWUpIGFuYWx5dGljcyBzeXN0ZW1zLgogICBTdWNo IGFwcGxpY2F0aW9ucyBwbGFjZSByZXF1aXJlbWVudHMgb24gdGhlIENETkkgTG9nZ2luZyBpbnRl cmZhY2UgdG8KICAgc3VwcG9ydCBndWFyYW50ZWVkIGFuZCB0aW1lbHkgZGVsaXZlcnkgb2YgbG9n IG1lc3NhZ2VzIGJldHdlZW4KICAgaW50ZXJjb25uZWN0ZWQgQ0ROcy4gIEl0IG1heSBhbHNvIGJl IG5lY2Vzc2FyeSB0byBiZSBhYmxlIHRvIHByb3ZlCiAgIHRoZSBpbnRlZ3JpdHkgb2YgcmVjZWl2 ZWQgbG9nIG1lc3NhZ2VzLgoKICAgU2V2ZXJhbCBwcm90b2NvbHMgYWxyZWFkeSBleGlzdCB0aGF0 IGNvdWxkIHBvdGVudGlhbGx5IGJlIHVzZWQgdG8KICAgZXhjaGFuZ2UgQ0ROSSBsb2dzIGJldHdl ZW4gaW50ZXJjb25uZWN0ZWQgQ0ROcyBpbmNsdWRpbmcgU05NUCBUcmFwcywKICAgc3lzbG9nLCBm dHAsIEhUVFAgUE9TVCwgZXRjLiBhbHRob3VnaCBpdCBpcyBsaWtlbHkgdGhhdCBzb21lIG9mIHRo ZQogICBjYW5kaWRhdGUgcHJvdG9jb2xzIG1heSBub3QgYmUgd2VsbCBzdWl0ZWQgdG8gbWVldCBh bGwgdGhlCiAgIHJlcXVpcmVtZW50cyBvZiBDRE5JLiAgRm9yIGV4YW1wbGUgU05NUCB0cmFwcyBw b3NlIHNjYWxhYmlsaXR5CiAgIGNvbmNlcm5zIGFuZCBTTk1QIGRvZXMgbm90IHN1cHBvcnQgZ3Vh cmFudGVlZCBkZWxpdmVyeSBvZiBUcmFwcyBhbmQKICAgdGhlcmVmb3JlIGNvdWxkIHJlc3VsdCBp biBsb2cgcmVjb3JkcyBiZWluZyBsb3N0IGFuZCB0aGUgY29uc2VxdWVudAogICBDRFJzIGFuZCBi aWxsaW5nIHJlY29yZHMgZm9yIHRoYXQgY29udGVudCBkZWxpdmVyeSBub3QgYmVpbmcgcHJvZHVj ZWQKICAgYXMgd2VsbCBhcyB0aGF0IGNvbnRlbnQgZGVsaXZlcnkgYmVpbmcgaW52aXNpYmxlIHRv IGFueSBhbmFseXRpY3MKICAgcGxhdGZvcm1zLgoKICAgQWx0aG91Z2ggaXQgaXMgbm90IG5lY2Vz c2FyeSB0byBkZWZpbmUgYSBuZXcgcHJvdG9jb2wgZm9yIGV4Y2hhbmdpbmcKICAgbG9ncyBhY3Jv c3MgdGhlIENETkkgTG9nZ2luZyBpbnRlcmZhY2UsIHRoZSBDRE5JIHdvcmtpbmcgZ3JvdXAgd291 bGQKICAgc3RpbGwgbmVlZCB0byBzcGVjaWZ5OgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4g ICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAyNV0KDApJbnRl cm5ldC1EcmFmdCAgICBDRE4gSW50ZXJjb25uZWN0aW9uIFByb2JsZW0gU3RhdGVtZW50ICAgICAg IEFwcmlsIDIwMTIKCgogICBvICBUaGUgcmVjb21tZW5kZWQgcHJvdG9jb2wgdG8gdXNlLgogICBv ICBBIGRlZmF1bHQgc2V0IG9mIGxvZyBmaWVsZHMgYW5kIHRoZWlyIHN5bnRheCAmIHNlbWFudGlj cy4gIFRvZGF5CiAgICAgIHRoZXJlIGlzIG5vIHN0YW5kYXJkIHNldCBvZiBjb21tb24gbG9nIGZp ZWxkcyBhY3Jvc3MgZGlmZmVyZW50CiAgICAgIGNvbnRlbnQgZGVsaXZlcnkgcHJvdG9jb2xzIGFu ZCBpbiBzb21lIGNhc2VzIHRoZXJlIGlzIG5vdCBldmVuIGEKICAgICAgc3RhbmRhcmQgc2V0IG9m IGxvZyBmaWVsZCBuYW1lcyBhbmQgdmFsdWVzIGZvciBkaWZmZXJlbnQKICAgICAgaW1wbGVtZW50 YXRpb25zIG9mIHRoZSBzYW1lIGRlbGl2ZXJ5IHByb3RvY29sLgogICBvICBBIGRlZmF1bHQgc2V0 IG9mIGV2ZW50cyB0aGF0IHRyaWdnZXIgbG9ncyB0byBiZSBnZW5lcmF0ZWQuCgpBLjQuICBDRE5J IENvbnRyb2wgSW50ZXJmYWNlCgogICBUaGUgQ0ROSSBDb250cm9sIGludGVyZmFjZSBhbGxvd3Mg dGhlIENvbnRyb2wgU3lzdGVtIGluCiAgIGludGVyY29ubmVjdGVkIENETnMgdG8gY29tbXVuaWNh dGUuICBUaGUgZXhhY3QgaW50ZXItQ0ROIGNvbnRyb2wKICAgZnVuY3Rpb25hbGl0eSByZXF1aXJl ZCB0byBiZSBzdXBwb3J0ZWQgYnkgdGhlIENETkkgQ29udHJvbCBpbnRlcmZhY2UKICAgaXMgbGVz cyB3ZWxsIGRlZmluZWQgdGhhbiB0aGUgb3RoZXIgdGhyZWUgQ0ROSSBpbnRlcmZhY2VzIGF0IHRo aXMKICAgdGltZS4KCiAgIEhvd2V2ZXIsIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDMsIHRoZSBD RE5JIENvbnRyb2wgaW50ZXJmYWNlIG1heSBiZQogICByZXF1aXJlZCB0byBzdXBwb3J0IGZ1bmN0 aW9uYWxpdHkgc2ltaWxhciB0byB0aGUgZm9sbG93aW5nOgogICBvICBBbGxvdyBhbiB1cHN0cmVh bSBDRE4gYW5kIGRvd25zdHJlYW0gQ0ROIHRvIGVzdGFibGlzaCwgdXBkYXRlIG9yCiAgICAgIHRl cm1pbmF0ZSB0aGVpciBDRE5JIGludGVyY29ubmVjdGlvbi4KICAgbyAgQWxsb3cgYm9vdHN0cmFw cGluZyBvZiB0aGUgb3RoZXIgQ0ROSSBpbnRlcmZhY2VzIChlLmcuIHByb3RvY29sCiAgICAgIGFk ZHJlc3MgZGlzY292ZXJ5IGFuZCBlc3RhYmxpc2htZW50IG9mIHNlY3VyaXR5IGFzc29jaWF0aW9u cykuCiAgIG8gIEFsbG93IGNvbmZpZ3VyYXRpb24gb2YgdGhlIG90aGVyIENETkkgaW50ZXJmYWNl cyAoZS5nLiAgVXBzdHJlYW0KICAgICAgQ0ROIHNwZWNpZmllcyBpbmZvcm1hdGlvbiB0byBiZSBy ZXBvcnRlZCB0aHJvdWdoIHRoZSBDRE5JIExvZ2dpbmcKICAgICAgaW50ZXJmYWNlKS4KICAgbyAg QWxsb3cgdGhlIGRvd25zdHJlYW0gQ0ROIHRvIGNvbW11bmljYXRlIHN0YXRpYyBpbmZvcm1hdGlv biBhYm91dAogICAgICBpdHMgZGVsaXZlcnkgY2FwYWJpbGl0aWVzLCByZXNvdXJjZXMgYW5kIHBv bGljaWVzLgogICBvICBBbGxvdyBib290c3RyYXBwaW5nIG9mIHRoZSBpbnRlcmZhY2UgYmV0d2Vl biBDRE5zIGZvciBjb250ZW50CiAgICAgIGFjcXVpc2l0aW9uIChldmVuIGlmIHRoYXQgaW50ZXJm YWNlIGl0c2VsZiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZgogICAgICB0aGUgQ0ROSSB3b3JrKS4K ICAgSXQgaXMgZXhwZWN0ZWQgdGhhdCBmb3IgdGhlIENvbnRyb2wgaW50ZXJmYWNlIGFsc28sIGV4 aXN0aW5nCiAgIHByb3RvY29scyBjYW4gYmUgcmV1c2VkIG9yIGxldmVyYWdlZC4gIFRob3NlIHdp bGwgYmUgY29uc2lkZXJlZCBvbmNlCiAgIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBDb250cm9s IGludGVyZmFjZSBoYXZlIGJlZW4gcmVmaW5lZC4KCgpBcHBlbmRpeCBCLiAgQWRkaXRpb25hbCBN YXRlcmlhbAoKICAgTm90ZSB0byBSRkMgRWRpdG9yOiBUaGlzIGFwcGVuZGl4IGlzIHRvIGJlIHJl bW92ZWQgb24gcHVibGljYXRpb24gYXMKICAgYW4gUkZDLgoKQi4xLiAgTm9uLUdvYWxzIGZvciBJ RVRGCgogICBMaXN0ZWQgYmVsb3cgYXJlIGFzcGVjdHMgb2YgY29udGVudCBkZWxpdmVyeSB0aGF0 IHRoZSBhdXRob3JzIHByb3Bvc2UKICAgYmUga2VwdCBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiBh IHBvdGVudGlhbCBDRE5JIHdvcmtpbmcgZ3JvdXA6CiAgIG8gIFRoZSBpbnRlcmZhY2UgYmV0d2Vl biBDb250ZW50IFNlcnZpY2UgUHJvdmlkZXIgYW5kIHRoZQogICAgICBBdXRob3JpdGF0aXZlIENE TiAoaS5lLiB0aGUgdXBzdHJlYW0gQ0ROIGNvbnRyYWN0ZWQgYnkgdGhlIENTUCBmb3IKICAgICAg ZGVsaXZlcnkgYnkgdGhpcyBDRE4gb3IgYnkgaXRzIGRvd25zdHJlYW0gQ0ROcykuCgoKCgpOaXZl bi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMTIgICAgICAgICAgICAg ICBbUGFnZSAyNl0KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4gSW50ZXJjb25uZWN0aW9uIFByb2Js ZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgogICBvICBUaGUgZGVsaXZlcnkgaW50ZXJm YWNlIGJldHdlZW4gdGhlIGRlbGl2ZXJpbmcgQ0ROIHN1cnJvZ2F0ZSBhbmQKICAgICAgdGhlIFVz ZXIgQWdlbnQsIHN1Y2ggYXMgc3RyZWFtaW5nIHByb3RvY29scy4KICAgbyAgVGhlIHJlcXVlc3Qg aW50ZXJmYWNlIGJldHdlZW4gdGhlIFVzZXIgQWdlbnQgYW5kIHRoZSByZXF1ZXN0LQogICAgICBy b3V0aW5nIHN5c3RlbSBvZiBhIGdpdmVuIENETi4gIEV4aXN0aW5nIElFVEYgcHJvdG9jb2xzIChl LmcuCiAgICAgIEhUVFAsIFJUU1AsIEROUykgYXJlIGNvbW1vbmx5IHVzZWQgYnkgVXNlciBBZ2Vu dHMgdG8gcmVxdWVzdAogICAgICBjb250ZW50IGZyb20gYSBDRE4gYW5kIGJ5IENETiByZXF1ZXN0 IHJvdXRpbmcgc3lzdGVtcyB0byByZWRpcmVjdAogICAgICB0aGUgVXNlciBBZ2VudCByZXF1ZXN0 cy4gIFRoZSBDRE5JIHdvcmtpbmcgZ3JvdXAgbmVlZCBub3QgZGVmaW5lCiAgICAgIG5ldyBwcm90 b2NvbHMgZm9yIHRoaXMgcHVycG9zZS4gIE5vdGUgaG93ZXZlciwgdGhhdCB0aGUgQ0ROSQogICAg ICBjb250cm9sIHBsYW5lIGludGVyZmFjZSBtYXkgaW5kaXJlY3RseSBhZmZlY3Qgc29tZSBvZiB0 aGUKICAgICAgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIHRocm91Z2ggdGhlIHJlcXVlc3QgaW50ZXJm YWNlIChlLmcuICBVUkkpLgogICBvICBUaGUgY29udGVudCBhY3F1aXNpdGlvbiBpbnRlcmZhY2Ug YmV0d2VlbiBDRE5zIChpLmUuIHRoZSBkYXRhCiAgICAgIHBsYW5lIGludGVyZmFjZSBmb3IgYWN0 dWFsIGRlbGl2ZXJ5IG9mIGEgcGllY2Ugb2YgY29udGVudCBmcm9tIG9uZQogICAgICBDRE4gdG8g dGhlIG90aGVyKS4gIFRoaXMgaXMgZXhwZWN0ZWQgdG8gdXNlIGV4aXN0aW5nIHByb3RvY29scwog ICAgICBzdWNoIGFzIEhUVFAgb3IgcHJvdG9jb2xzIGRlZmluZWQgaW4gb3RoZXIgZm9ydW1zIGZv ciBjb250ZW50CiAgICAgIGFjcXVpc2l0aW9uIGJldHdlZW4gYW4gb3JpZ2luIHNlcnZlciBhbmQg YSBDRE4gKGUuZy4gIEhUVFAtYmFzZWQKICAgICAgQzIgcmVmZXJlbmNlIHBvaW50IG9mIEFUSVMg SUlGIENvRCkuICBUaGUgQ0ROIEludGVyY29ubmVjdGlvbgogICAgICBwcm9ibGVtIHNwYWNlIGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG1heSB0aGVyZWZvcmUgb25seQogICAgICBjb25jZXJu IGl0c2VsZiB3aXRoIHRoZSBhZ3JlZW1lbnQvbmVnb3RpYXRpb24gYXNwZWN0cyBvZiB3aGljaAog ICAgICBjb250ZW50IGFjcXVpc2l0aW9uIHByb3RvY29sIGlzIHRvIGJlIHVzZWQgYmV0d2VlbiB0 d28KICAgICAgaW50ZXJjb25uZWN0ZWQgQ0ROcyBpbiB2aWV3IG9mIGZhY2lsaXRhdGluZyBpbnRl cm9wZXJhYmlsaXR5LgogICBvICBFbmQgVXNlci9Vc2VyIEFnZW50IEF1dGhlbnRpY2F0aW9uLiAg RW5kIFVzZXIvVXNlciBBZ2VudAogICAgICBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv biBhcmUgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZQogICAgICBDb250ZW50IFNlcnZpY2UgUHJv dmlkZXIuCiAgIG8gIENvbnRlbnQgcHJlcGFyYXRpb24sIGluY2x1ZGluZyBlbmNvZGluZyBhbmQg dHJhbnNjb2RpbmcuICBUaGUgQ0ROSQogICAgICBhcmNoaXRlY3R1cmUgYWltcyBhdCBhbGxvd2lu ZyBkaXN0cmlidXRpb24gYWNyb3NzIGludGVyY29ubmVjdGVkCiAgICAgIENETnMgb2YgY29udGVu dCB0cmVhdGVkIGFzIG9wYXF1ZSBvYmplY3RzLiAgSW50ZXJwcmV0YXRpb24gYW5kCiAgICAgIHBy b2Nlc3Npbmcgb2YgdGhlIG9iamVjdHMsIGFzIHdlbGwgYXMgb3B0aW1pemVkIGRlbGl2ZXJ5IG9m IHRoZXNlCiAgICAgIG9iamVjdHMgYnkgdGhlIHN1cnJvZ2F0ZSB0byB0aGUgRW5kIFVzZXIgYXJl IG91dHNpZGUgdGhlIHNjb3BlIG9mCiAgICAgIENETkkuCiAgIG8gIERpZ2l0YWwgUmlnaHRzIE1h bmFnZW1lbnQgKERSTSkuICBEUk0gaXMgYW4gZW5kLXRvLWVuZCBpc3N1ZQogICAgICBiZXR3ZWVu IGEgY29udGVudCBwcm90ZWN0aW9uIHN5c3RlbSBhbmQgdGhlIFVzZXIgQWdlbnQuCiAgIG8gIEFw cGxpY2F0aW9ucyBjb25zdW1pbmcgQ0ROSSBsb2dzIChlLmcuIGNoYXJnaW5nLCBhbmFseXRpY3Ms CiAgICAgIHJlcG9ydGluZywuLi4pLgogICBvICBJbnRlcm5hbCBDRE4gaW50ZXJmYWNlcyAmIHBy b3RvY29scyAoaS5lLiBpbnRlcmZhY2VzICYgcHJvdG9jb2xzCiAgICAgIHdpdGhpbiBvbmUgQ0RO KS4KICAgbyAgU2NhbGFiaWxpdHkgb2YgaW5kaXZpZHVhbCBDRE5zLiAgV2hpbGUgc2NhbGFiaWxp dHkgb2YgdGhlIENETkkKICAgICAgaW50ZXJmYWNlcy9hcHByb2FjaCBpcyBpbiBzY29wZSwgaG93 IGFuIGluZGl2aWR1YWwgQ0ROIHNjYWxlcyBpcwogICAgICBvdXQgb2Ygc2NvcGUuCiAgIG8gIEFj dHVhbCBhbGdvcml0aG1zIGZvciBzZWxlY3Rpb24gb2YgQ0ROcyBvciBTdXJyb2dhdGVzIGJ5IFJl cXVlc3QKICAgICAgUm91dGluZyBzeXN0ZW1zIChob3dldmVyLCBzb21lIHNwZWNpZmljIHBhcmFt ZXRlcnMgcmVxdWlyZWQgYXMKICAgICAgaW5wdXQgdG8gdGhlc2UgYWxnb3JpdGhtcyBtYXkgYmUg aW4gc2NvcGUgd2hlbiB0aGV5IG5lZWQgdG8gYmUKICAgICAgY29tbXVuaWNhdGVkIGFjcm9zcyBD RE5zKS4KICAgbyAgU3Vycm9nYXRlIGFsZ29yaXRobXMuICBGb3IgZXhhbXBsZSBjYWNoaW5nIGFs Z29yaXRobXMgYW5kIGNvbnRlbnQKICAgICAgYWNxdWlzaXRpb24gbWV0aG9kcyBhcmUgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhlIENETkkgd29yay4KICAgICAgQ29udGVudCBtYW5hZ2VtZW50IChl LmcuICBDb250ZW50IERlbGV0aW9uKSBhcyBpdCByZWxhdGVzIHRvIENETkkKICAgICAgY29udGVu dCBtYW5hZ2VtZW50IHBvbGljaWVzLCBpcyBpbiBzY29wZSBidXQgdGhlIGludGVybmFsCiAgICAg IGFsZ29yaXRobXMgdXNlZCBieSBhIGNhY2hlIHRvIGRldGVybWluZSB3aGVuIHRvIG5vIGxvbmdl ciBjYWNoZSBhbgogICAgICBpdGVtIG9mIENvbnRlbnQgKGluIHRoZSBhYnNlbmNlIG9mIGFueSBz cGVjaWZpYyBtZXRhZGF0YSB0byB0aGUKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJl cyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMjddCgwKSW50ZXJuZXQtRHJh ZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAy MDEyCgoKICAgICAgY29udHJhcnkpIGlzIG91dCBvZiBzY29wZS4KICAgbyAgRWxlbWVudCBtYW5h Z2VtZW50IGludGVyZmFjZXMuCiAgIG8gIENvbW1lcmNpYWwsIGJ1c2luZXNzIGFuZCBsZWdhbCBh c3BlY3RzIHJlbGF0ZWQgdG8gdGhlCiAgICAgIGludGVyY29ubmVjdGlvbnMgb2YgQ0ROcy4KCkIu Mi4gIFJlbGF0ZWQgc3RhbmRhcmRpemF0aW9uIGFjdGl2aXRlcwoKICAgVGhlcmUgYXJlIGEgbnVt YmVyIG9mIG90aGVyIHN0YW5kYXJkcyBib2RpZXMgYW5kIGluZHVzdHJ5IGZvcnVtcyB0aGF0CiAg IGFyZSB3b3JraW5nIGluIGFyZWFzIHJlbGF0ZWQgdG8gQ0ROcywgYW5kIGluIHNvbWUgY2FzZXMg cmVsYXRlZCB0bwogICBDRE5JLiAgVGhpcyBzZWN0aW9uIG91dGxpbmVzIGFueSBwb3RlbnRpYWwg b3ZlcmxhcCB3aXRoIHRoZSB3b3JrIG9mCiAgIHRoZSBDRE5JIHdvcmtpbmcgZ3JvdXAgYW5kIGFu eSBjb21wb25lbnQgdGhhdCBjb3VsZCBwb3RlbnRpYWxseSBiZQogICByZXVzZWQgdG8gcmVhbGl6 ZSB0aGUgQ0ROSSBpbnRlcmZhY2VzLgoKICAgQSBudW1iZXIgb2Ygc3RhbmRhcmRzIGJvZGllcyBo YXZlIHByb2R1Y2VkIHNwZWNpZmljYXRpb25zIHJlbGF0ZWQgdG8KICAgQ0ROcywgZm9yIGV4YW1w bGU6CgogICBvICBFVFNJIFRJU1BBTiAoVGVsZWNvbW11bmljYXRpb25zIGFuZCBJbnRlcm5ldCBj b252ZXJnZWQgU2VydmljZXMKICAgICAgYW5kIFByb3RvY29scyBmb3IgQWR2YW5jZWQgTmV0d29y a2luZykgaGFzIGEgc2VyaWVzIG9mCiAgICAgIHNwZWNpZmljYXRpb25zIGZvY3VzaW5nIG9uIENE TnMuCiAgIG8gIFRoZSBPcGVuIElQVFYgRm9ydW0gKE9JUEYpIGFuZCBBVElTIElQVFYgSW50ZXJv cGVyYWJpbGl0eSBGb3J1bQogICAgICAoSUlGKSBzcGVjaWZ5IHRoZSBhcmNoaXRlY3R1cmUgYW5k IHRoZSBwcm90b2NvbHMgb2YgYW4gSVBUVgogICAgICBzb2x1dGlvbi4gIEFsdGhvdWdoIE9JUEYg YW5kIEFUSVMgc3BlY2lmaWNhdGlvbnMgaW5jbHVkZSB0aGUKICAgICAgaW50ZXJhY3Rpb24gd2l0 aCBhIENETiwgdGhlIENETiBzcGVjaWZpY2F0aW9ucyBhcmUgY291cGxlZCB3aXRoCiAgICAgIHRo ZWlyIElQVFYgc3BlY2lmaWNhdGlvbnMgYW5kIGRvIG5vdCBjb3ZlciBpbnRlcmNvbm5lY3Rpb24g b2YKICAgICAgQ0ROcy4KICAgbyAgQVRJUyBDbG91ZCBTZXJ2aWNlcyBGb3J1bSAoQ1NGKSBoYXMg c3RhcnRlZCBpbnZlc3RpZ2F0aW5nCiAgICAgIGludGVyY29ubmVjdGlvbiBvZiBDRE5zLiAgVGhl IEFUSVMgQ1NGIGZvY3VzZXMgb24gZGVmaW5pbmcgdXNlCiAgICAgIGNhc2VzIGFuZCByZXF1aXJl bWVudHMgZm9yIHN1Y2ggQ0ROIGludGVyY29ubmVjdGlvbiwgd2hpY2ggYXJlCiAgICAgIGV4cGVj dGVkIHRvIGJlIGNvbnNpZGVyZWQgYXMgaW5wdXQgaW50byB0aGUgd29yayBvZiB0aGUgQ0ROSQog ICAgICB3b3JraW5nIGdyb3VwLiAgQXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0aGlzIGRvY3VtZW50 LCBBVElTIENTRiBpcwogICAgICBub3Qgc3BlY2lmeWluZyB0aGUgY29ycmVzcG9uZGluZyBwcm90 b2NvbHMgb3IgaW50ZXJmYWNlcyBhbmQgaXMKICAgICAgZXhwZWN0ZWQgdG8gbGV2ZXJhZ2UgdGhl IHdvcmsgb2YgdGhlIElFVEYgQ0ROSSB3b3JraW5nIGdyb3VwIGZvcgogICAgICB0aG9zZS4KICAg byAgQ2FibGVMYWJzLCBTTklBIGFuZCBJVFUgaGF2ZSBkZXZlbG9wZWQgKG9yIGFyZSB3b3JraW5n IG9uKQogICAgICBkZWZpbml0aW9ucyBmb3IgY29udGVudCByZWxhdGVkIG1ldGFkYXRhIGFuZCBz cGVjaWZpY2F0aW9ucyBmb3IKICAgICAgaXRzIGRpc3RyaWJ1dGlvbi4gIEhvd2V2ZXIsIHRoZXkg ZG8gbm90IGluY2x1ZGUgbWV0YWRhdGEgc3BlY2lmaWMKICAgICAgdG8gdGhlIGRpc3RyaWJ1dGlv biBvZiBjb250ZW50IHdpdGhpbiBhIENETiBvciBiZXR3ZWVuCiAgICAgIGludGVyY29ubmVjdGVk IENETnMuCiAgIG8gIElFVEYgQ0RJIHdvcmtpbmcgZ3JvdXAgKG5vdyBjb25jbHVkZWQpIHRvdWNo ZWQgb24gdGhlIHNhbWUgcHJvYmxlbQogICAgICBzcGFjZSBhcyB0aGUgcHJlc2VudCBkb2N1bWVu dC4gIEhvd2V2ZXIsIGluIGFjY29yZGFuY2Ugd2l0aCBpdHMKICAgICAgaW5pdGlhbCBjaGFydGVy LCB0aGUgQ0RJIHdvcmtpbmcgZ3JvdXAgZGlkIG5vdCBkZWZpbmUgYW55CiAgICAgIHByb3RvY29s cyBvciBpbnRlcmZhY2VzIHRvIGFjdHVhbGx5IGVuYWJsZSBDRE4gSW50ZXJjb25uZWN0aW9uIGFu ZAogICAgICBhdCB0aGF0IHRpbWUgKDIwMDMpIHRoZXJlIHdhcyBub3QgZW5vdWdoIGluZHVzdHJ5 IGludGVyZXN0IGFuZAogICAgICByZWFsIGxpZmUgcmVxdWlyZW1lbnRzIHRvIGp1c3RpZnkgcmVj aGFydGVyaW5nIHRoZSB3b3JraW5nIGdyb3VwCiAgICAgIHRvIGNvbmR1Y3QgdGhlIGNvcnJlc3Bv bmRpbmcgcHJvdG9jb2wgd29yay4KCiAgIEFsdGhvdWdoIHNvbWUgb2YgdGhlIHNwZWNpZmljYXRp b25zIGRlc2NyaWJlIG11bHRpLUNETiBjb29wZXJhdGlvbiBvcgogICBpbmNsdWRlIHJlZmVyZW5j ZSBwb2ludHMgZm9yIGludGVyY29ubmVjdGluZyBDRE5zLCBub25lIG9mIHRoZW0KCgoKTml2ZW4t SmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAg W1BhZ2UgMjhdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVt IFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgc3BlY2lmeSBpbiBzdWZmaWNpZW50IGRl dGFpbCBhbGwgdGhlIENETkkgaW50ZXJmYWNlcyBhbmQgQ0ROSQogICBNZXRhZGF0YSByZXByZXNl bnRhdGlvbnMgcmVxdWlyZWQgdG8gZW5hYmxlIGV2ZW4gYSBiYXNlIGxldmVsIG9mIENETgogICBJ bnRlcmNvbm5lY3Rpb24gZnVuY3Rpb25hbGl0eSB0byBiZSBpbXBsZW1lbnRlZC4KCkIuMi4xLiAg SUVURiBDREkgV29ya2luZyBHcm91cCAoQ29uY2x1ZGVkKQoKICAgVGhlIENvbnRlbnQgRGlzdHJp YnV0aW9uIEludGVybmV0d29ya2luZyAoQ0RJKSBXb3JraW5nIEdyb3VwIHdhcwogICBmb3JtZWQg aW4gdGhlIElFVEYgZm9sbG93aW5nIGEgQm9GIGluIERlY2VtYmVyIDIwMDAgYW5kIGNsb3NlZCBp biBtaWQKICAgMjAwMy4KCiAgIEZvciBjb252ZW5pZW5jZSwgaGVyZSBpcyBhbiBleHRyYWN0IGZy b20gdGhlIENESSB3b3JraW5nIGdyb3VwCiAgIGNoYXJ0ZXIgW0NESS1DaGFydGVyXToKCiAgICIK CiAgIG8gIFRoZSBnb2FsIG9mIHRoaXMgd29ya2luZyBncm91cCBpcyB0byBkZWZpbmUgcHJvdG9j b2xzIHRvIGFsbG93IHRoZQogICAgICBpbnRlcm9wZXJhdGlvbiBvZiBzZXBhcmF0ZWx5LWFkbWlu aXN0ZXJlZCBjb250ZW50IG5ldHdvcmtzLgogICBvICBBIGNvbnRlbnQgbmV0d29yayBpcyBhbiBh cmNoaXRlY3R1cmUgb2YgbmV0d29yayBlbGVtZW50cywgYXJyYW5nZWQKICAgICAgZm9yIGVmZmlj aWVudCBkZWxpdmVyeSBvZiBkaWdpdGFsIGNvbnRlbnQuICBTdWNoIGNvbnRlbnQgaW5jbHVkZXMs CiAgICAgIGJ1dCBpcyBub3QgbGltaXRlZCB0bywgd2ViIHBhZ2VzIGFuZCBpbWFnZXMgZGVsaXZl cmVkIHZpYSBIVFRQLAogICAgICBhbmQgc3RyZWFtaW5nIG9yIGNvbnRpbnVvdXMgbWVkaWEgd2hp Y2ggYXJlIGNvbnRyb2xsZWQgYnkgUlRTUC4KICAgbyAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBm aXJzdCBkZWZpbmUgcmVxdWlyZW1lbnRzIGZvciB0aHJlZSBtb2RlcwogICAgICBvZiBjb250ZW50 IGludGVybmV0d29ya2luZzogaW50ZXJvcGVyYXRpb24gb2YgcmVxdWVzdC1yb3V0aW5nCiAgICAg IHN5c3RlbXMsIGludGVyb3BlcmF0aW9uIG9mIGRpc3RyaWJ1dGlvbiBzeXN0ZW1zLCBhbmQKICAg ICAgaW50ZXJvcGVyYXRpb24gb2YgYWNjb3VudGluZyBzeXN0ZW1zLiAgVGhlc2UgcmVxdWlyZW1l bnRzIGFyZQogICAgICBpbnRlbmRlZCB0byBsZWFkIHRvIGEgZm9sbG93LW9uIGVmZm9ydCB0byBk ZWZpbmUgcHJvdG9jb2xzIGZvcgogICAgICBpbnRlcm9wZXJhdGlvbiBvZiB0aGVzZSBzeXN0ZW1z LgogICBvICBJbiBpdHMgaW5pdGlhbCBmb3JtLCB0aGUgd29ya2luZyBncm91cCBpcyBub3QgY2hh cnRlcmVkIHRvIGRlbGl2ZXIKICAgICAgdGhvc2UgcHJvdG9jb2xzIFsuLi5dCgogICAiCgogICBU aHVzLCB0aGUgQ0RJIHdvcmtpbmcgZ3JvdXAgdG91Y2hlZCBvbiB0aGUgc2FtZSBwcm9ibGVtIHNw YWNlIGFzIHRoZQogICBwcmVzZW50IGRvY3VtZW50LgoKICAgVGhlIENESSB3b3JraW5nIGdyb3Vw IHB1Ymxpc2hlZCAzIEluZm9ybWF0aW9uYWwgUkZDczoKCiAgIG8gIFJGQyAzNDY2IFtSRkMzNDY2 XSAtICJBIE1vZGVsIGZvciBDb250ZW50IEludGVybmV0d29ya2luZyAoQ0RJKSIuCiAgIG8gIFJG QyAzNTY4IFtSRkMzNTY4XSAtICJLbm93biBDb250ZW50IE5ldHdvcmsgKENOKSBSZXF1ZXN0LVJv dXRpbmcKICAgICAgTWVjaGFuaXNtcyIuCiAgIG8gIFJGQyAzNTcwIFtSRkMzNTcwXSAtICJDb250 ZW50IEludGVybmV0d29ya2luZyAoQ0RJKSBTY2VuYXJpb3MiLgoKQi4yLjIuICAzR1BQCgogICAz R1BQIHdhcyB0aGUgZmlyc3Qgb3JnYW5pemF0aW9uIHRoYXQgcmVsZWFzZWQgYSBzcGVjaWZpY2F0 aW9uIHJlbGF0ZWQKICAgdG8gYWRhcHRpdmUgc3RyZWFtaW5nIG92ZXIgSFRUUC4gM0dQUCBSZWxl YXNlIDkgc3BlY2lmaWNhdGlvbiBvbgogICBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyB3YXMgcHVi bGlzaGVkIGluIE1hcmNoIDIwMTAsIGFuZCB0aGVyZSBoYXZlCiAgIGJlZW4gc29tZSBidWcgZml4 ZXMgb24gdGhpcyBzcGVjaWZpY2F0aW9uIHNpbmNlIHRoZSBwdWJsaWNhdGlvbi4gIEluCgoKCk5p dmVuLUplbmtpbnMsIGV0IGFsLiAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAxMiAgICAgICAgICAg ICAgIFtQYWdlIDI5XQoMCkludGVybmV0LURyYWZ0ICAgIENETiBJbnRlcmNvbm5lY3Rpb24gUHJv YmxlbSBTdGF0ZW1lbnQgICAgICAgQXByaWwgMjAxMgoKCiAgIGFkZGl0aW9uLCAzR1BQIGhhcyBw cm9kdWNlZCBhbiBleHRlbmRlZCB2ZXJzaW9uIGZvciBSZWxlYXNlIDEwLCB3aGljaAogICB3YXMg cHVibGlzaGVkIGluIDIwMTEuICBUaGlzIHJlbGVhc2Ugd2lsbCBpbmNsdWRlIGEgbnVtYmVyIG9m CiAgIGNsYXJpZmljYXRpb25zLCBpbXByb3ZlbWVudHMgYW5kIG5ldyBmZWF0dXJlcy4KCiAgIFsz R1AtREFTSF0gaXMgZGVmaW5lZCBhcyBhIGdlbmVyYWwgZnJhbWV3b3JrIGluZGVwZW5kZW50IG9m IHRoZSBkYXRhCiAgIGVuY2Fwc3VsYXRpb24gZm9ybWF0LiAgSXQgaGFzIHN1cHBvcnQgZm9yIGZh c3QgaW5pdGlhbCBzdGFydHVwIGFuZAogICBzZWVraW5nLCBhZGFwdGl2ZSBiaXRyYXRlIHN3aXRj aGluZywgcmUtdXNlIG9mIEhUVFAgb3JpZ2luIGFuZCBjYWNoZQogICBzZXJ2ZXJzLCByZS11c2Ug b2YgZXhpc3RpbmcgbWVkaWEgcGxheW91dCBlbmdpbmVzLCBvbi1kZW1hbmQsIGxpdmUKICAgYW5k IHRpbWUtc2hpZnRlZCBkZWxpdmVyeS4gIEl0IHNwZWNpZmllcyBzeW50YXggYW5kIHNlbWFudGlj cyBvZgogICBNZWRpYSBQcmVzZW50YXRpb24gRGVzY3JpcHRpb24gKE1QRCksIGZvcm1hdCBvZiBz ZWdtZW50cyBhbmQgZGVsaXZlcnkKICAgcHJvdG9jb2wgZm9yIHNlZ21lbnRzLiAgSXQgZG9lcyBu b3Qgc3BlY2lmeSBjb250ZW50IHByb3Zpc2lvbmluZywKICAgY2xpZW50IGJlaGF2aW9yIG9yIHRy YW5zcG9ydCBvZiBNUEQuCgogICBUaGUgY29udGVudCByZXRyaWV2ZWQgYnkgYSBjbGllbnQgdXNp bmcgWzNHUC1EQVNIXSBhZGFwdGl2ZSBzdHJlYW1pbmcKICAgY291bGQgYmUgb2J0YWluZWQgZnJv bSBhIENETiBidXQgdGhpcyBpcyBub3QgZGlzY3Vzc2VkIG9yIHNwZWNpZmllZAogICBpbiB0aGUg M0dQUCBzcGVjaWZpY2F0aW9ucyBhcyBpdCBpcyB0cmFuc3BhcmVudCB0byBbM0dQLURBU0hdCiAg IG9wZXJhdGlvbnMuICBTaW1pbGFybHksIGl0IGlzIGV4cGVjdGVkIHRoYXQgWzNHUC1EQVNIXSBj YW4gYmUgdXNlZAogICB0cmFuc3BhcmVudGx5IGZyb20gdGhlIENETnMgYXMgYSBkZWxpdmVyeSBw cm90b2NvbCAoYmV0d2VlbiB0aGUKICAgZGVsaXZlcmluZyBDRE4gc3Vycm9nYXRlIGFuZCB0aGUg VXNlciBBZ2VudCkgaW4gYSBDRE4gSW50ZXJjb25uZWN0aW9uCiAgIGVudmlyb25tZW50LiBbM0dQ LURBU0hdIGNvdWxkIGFsc28gYmUgYSBjYW5kaWRhdGUgZm9yIGNvbnRlbnQKICAgYWNxdWlzaXRp b24gYmV0d2VlbiBDRE5zIGluIGEgQ0ROIEludGVyY29ubmVjdGlvbiBlbnZpcm9ubWVudC4KCkIu Mi4zLiAgSVNPIE1QRUcKCiAgIFdpdGhpbiBJU08gTVBFRywgdGhlIER5bmFtaWMgQWRhcHRpdmUg U3RyZWFtaW5nIG92ZXIgSFRUUCAoREFTSCkgYWQtCiAgIGhvYyBncm91cCBhZG9wdGVkIHRoZSAz R1BQIFJlbGVhc2UgOSBbM0dQLURBU0hdIHNwZWNpZmljYXRpb24gYXMgYQogICBzdGFydGluZyBw b2ludCBhbmQgaGFzIG1hZGUgc29tZSBpbXByb3ZlbWVudHMgYW5kIGV4dGVuc2lvbnMuCiAgIFNp bWlsYXIgdG8gM0dQUCBTQTQsIHRoZSBNUEVHIERBU0ggYWQtaG9jIGdyb3VwIGhhcyBiZWVuIHdv cmtpbmcgb24KICAgc3RhbmRhcmRpemluZyB0aGUgbWFuaWZlc3QgZmlsZSBhbmQgdGhlIGRlbGl2 ZXJ5IGZvcm1hdC4KICAgQWRkaXRpb25hbGx5LCB0aGUgTVBFRyBEQVNIIGFkLWhvYyBncm91cCBo YXMgYWxzbyBiZWVuIHdvcmtpbmcgb24gdGhlCiAgIHVzZSBvZiBNUEVHLTIgVHJhbnNwb3J0IFN0 cmVhbXMgYXMgYSBtZWRpYSBmb3JtYXQsIGNvbnZlcnNpb24gZnJvbS90bwogICBleGlzdGluZyBm aWxlIGZvcm1hdHMsIGNvbW1vbiBlbmNyeXB0aW9uLCBhbmQgc28gb24uICBUaGUgTVBFRyBEQVNI CiAgIHNwZWNpZmljYXRpb24gY291bGQgYWxzbyBiZSBhIGNhbmRpZGF0ZSBmb3IgZGVsaXZlcnkg dG8gdGhlIFVzZXIKICAgQWdlbnQgYW5kIGZvciBjb250ZW50IGFjcXVpc2l0aW9uIGJldHdlZW4g Q0ROcyBpbiBhIENETgogICBJbnRlcmNvbm5lY3Rpb24gZW52aXJvbm1lbnQuICBUaGUgRHJhZnQg SW50ZXJuYXRpb25hbCBTdGFuZGFyZCAoRElTKQogICB2ZXJzaW9uIFtNUEVHLURBU0hdIGlzIGN1 cnJlbnRseSBwdWJsaWNseSBhdmFpbGFibGUgc2luY2UgZWFybHkKICAgRmVicnVhcnkgMjAxMS4K CiAgIEluIHRoZSA5NXRoIE1QRUcgbWVldGluZyBpbiBKYW51YXJ5IDIwMTEsIHRoZSBEQVNIIGFk LWhvYyBncm91cAogICBkZWNpZGVkIHRvIHN0YXJ0IGEgbmV3IGV2YWx1YXRpb24gZXhwZXJpbWVu dCBjYWxsZWQgIkNETi1FRSIuICBUaGUKICAgZ29hbHMgYXJlIHRvIHVuZGVyc3RhbmQgdGhlIHJl cXVpcmVtZW50cyBmb3IgTVBFRyBEQVNIIHRvIGJldHRlcgogICBzdXBwb3J0IENETi1iYXNlZCBk ZWxpdmVyeSwgYW5kIHRvIHByb3ZpZGUgYSBndWlkZWxpbmVzIGRvY3VtZW50IGZvcgogICBDRE4g b3BlcmF0b3JzIHRvIGJldHRlciBzdXBwb3J0IE1QRUcgREFTSCBzdHJlYW1pbmcgc2VydmljZXMu ICBUaGUKICAgb25nb2luZyB3b3JrIGlzIHN0aWxsIHZlcnkgcHJlbGltaW5hcnkgYW5kIGRvZXMg bm90IGN1cnJlbnRseSB0YXJnZXQKICAgbG9va2luZyBpbnRvIENETiBJbnRlcmNvbm5lY3Rpb24g dXNlIGNhc2VzLgoKCgoKCgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVy IDEsIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAzMF0KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4g SW50ZXJjb25uZWN0aW9uIFByb2JsZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgpCLjIu NC4gIEFUSVMgSUlGCgogICBBVElTIChbQVRJU10pIElJRiBpcyB0aGUgSVBUViBJbnRlcm9wZXJh YmlsaXR5IEZvcnVtICh3aXRoaW4gQVRJUykKICAgdGhhdCBkZXZlbG9wcyByZXF1aXJlbWVudHMs IHN0YW5kYXJkcywgYW5kIHNwZWNpZmljYXRpb25zIGZvciBJUFRWLgoKICAgQVRJUyBJSUYgaXMg ZGV2ZWxvcGluZyB0aGUgIklQVFYgQ29udGVudCBvbiBEZW1hbmQgKENvRCkgU2VydmljZSIKICAg c3BlY2lmaWNhdGlvbi4gIFRoaXMgaW5jbHVkZXMgdXNlIG9mIGEgQ0ROIChyZWZlcnJlZCB0byBp biBBVElTIElJRgogICBDb0QgYXMgdGhlICJDb250ZW50IERpc3RyaWJ1dGlvbiBhbmQgRGVsaXZl cnkgRnVuY3Rpb25zIikgZm9yIHN1cHBvcnQKICAgb2YgYSBDb250ZW50IG9uIERlbWFuZCAoQ29E KSBTZXJ2aWNlIGFzIHBhcnQgb2YgYSBicm9hZGVyIElQVFYKICAgc2VydmljZS4gIEhvd2V2ZXIs IHRoaXMgb25seSBjb3ZlcnMgdGhlIGNhc2Ugb2YgYSBtYW5hZ2VkIElQVFYKICAgc2VydmljZSAo aW4gcGFydGljdWxhciB3aGVyZSB0aGUgQ0ROIGlzIGFkbWluaXN0ZXJlZCBieSB0aGUgc2Vydmlj ZQogICBwcm92aWRlcikgYW5kIGRvZXMgbm90IGNvdmVyIHRoZSB1c2UsIG9yIGludGVyY29ubmVj dGlvbiwgb2YgbXVsdGlwbGUKICAgQ0ROcy4KCkIuMi41LiAgQ2FibGVMYWJzCgogICAiRm91bmRl ZCBpbiAxOTg4IGJ5IGNhYmxlIG9wZXJhdGluZyBjb21wYW5pZXMsIENhYmxlIFRlbGV2aXNpb24K ICAgTGFib3JhdG9yaWVzLCBJbmMuIChDYWJsZUxhYnMpIGlzIGEgbm9uLXByb2ZpdCByZXNlYXJj aCBhbmQKICAgZGV2ZWxvcG1lbnQgY29uc29ydGl1bSB0aGF0IGlzIGRlZGljYXRlZCB0byBwdXJz dWluZyBuZXcgY2FibGUKICAgdGVsZWNvbW11bmljYXRpb25zIHRlY2hub2xvZ2llcyBhbmQgdG8g aGVscGluZyBpdHMgY2FibGUgb3BlcmF0b3IKICAgbWVtYmVycyBpbnRlZ3JhdGUgdGhvc2UgdGVj aG5pY2FsIGFkdmFuY2VtZW50cyBpbnRvIHRoZWlyIGJ1c2luZXNzCiAgIG9iamVjdGl2ZXMuIiAg W0NhYmxlTGFic10KCiAgIENhYmxlTGFicyBoYXMgZGVmaW5lZCBzcGVjaWZpY2F0aW9ucyBmb3Ig Q29EIENvbnRlbnQgTWV0YWRhdGEgYXMgcGFydAogICBvZiBpdHMgVk9EIE1ldGFkYXRhIHByb2pl Y3QuCgpCLjIuNi4gIEVUU0kgTUNECgogICBFVFNJIE1DRCAoTWVkaWEgQ29udGVudCBEaXN0cmli dXRpb24pIGlzIHRoZSBFVFNJIHRlY2huaWNhbCBjb21taXR0ZWUKICAgImluIGNoYXJnZSBvZiBn dWlkaW5nIGFuZCBjb29yZGluYXRpbmcgc3RhbmRhcmRpemF0aW9uIHdvcmsgYWltaW5nIGF0CiAg IHRoZSBzdWNjZXNzZnVsIG92ZXJhbGwgZGV2ZWxvcG1lbnQgb2YgbXVsdGltZWRpYSBzeXN0ZW1z ICh0ZWxldmlzaW9uCiAgIGFuZCBjb21tdW5pY2F0aW9uKSByZXNwb25kaW5nIHRvIHRoZSBwcmVz ZW50IGFuZCBmdXR1cmUgbWFya2V0CiAgIHJlcXVlc3RzIG9uIG1lZGlhIGNvbnRlbnQgZGlzdHJp YnV0aW9uIi4KCiAgIE1DRCBjcmVhdGVkIGEgc3BlY2lmaWMgd29yayBpdGVtIG9uIGludGVyY29u bmVjdGlvbiBvZiBoZXRlcm9nZW5lb3VzCiAgIENETnMgKCJDRE4gSW50ZXJjb25uZWN0aW9uLCB1 c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyIpIGluIE1hcmNoCiAgIDIwMTAuICBNQ0QgdmVyeSBy ZWNlbnRseSBjcmVhdGVkIGEgd29ya2luZyBncm91cCB0byBwcm9ncmVzcyB0aGlzCiAgIHdvcmsg aXRlbS4gIEhvd2V2ZXIsIG5vIHByb3RvY29sIGxldmVsIHdvcmsgaGFzIHlldCBzdGFydGVkIGlu IE1DRAogICBmb3IgQ0ROIEludGVyY29ubmVjdGlvbi4KCkIuMi43LiAgRVRTSSBUSVNQQU4KCiAg IEVUU0kgVElTUEFOIGhhcyBwdWJsaXNoZWQgdHdvIHNldHMgb2YgSVBUViBzcGVjaWZpY2F0aW9u cywgb25lIG9mCiAgIHdoaWNoIGlzIGJhc2VkIG9uIElNUy4gIEluIGFkZGl0aW9uLCBUSVNQQU4g aGFzIHB1Ymxpc2hlZCBhIENETgogICBhcmNoaXRlY3R1cmUgc3VwcG9ydGluZyBkZWxpdmVyeSBv ZiB2YXJpb3VzIGNvbnRlbnQgc2VydmljZXMgc3VjaCBhcwogICB0aW1lLXNoaWZ0ZWQgVFYgYW5k IFZvRCB0byBUSVNQQU4gZGV2aWNlcyAoVUVzKSBvciByZWd1bGFyIFBDcy4gIFRoZQogICB1c2Ug Y2FzZXMgYWxsb3cgZm9yIGhpZXJhcmNoaWNhbGx5IGFuZCBnZW9ncmFwaGljYWxseSBkaXN0cmli dXRlZCBDRE4KICAgc2NlbmFyaW9zLCBhbG9uZyB3aXRoIG11bHRpLUNETiBjb29wZXJhdGlvbi4g IEFzIGEgcmVzdWx0LCB0aGUKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3Zl bWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMzFdCgwKSW50ZXJuZXQtRHJhZnQgICAg Q0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoK ICAgYXJjaGl0ZWN0dXJlIGNvbnRhaW5zIHJlZmVyZW5jZSBwb2ludHMgdG8gc3VwcG9ydCBpbnRl cmNvbm5lY3Rpb24gb2YKICAgb3RoZXIgVElTUEFOIENETnMuICBUaGUgcHJvdG9jb2wgZGVmaW5p dGlvbiBwaGFzZSBmb3IgdGhlCiAgIGNvcnJlc3BvbmRpbmcgQ0ROIGFyY2hpdGVjdHVyZSB3YXMg a2lja2VkLW9mZiBhdCB0aGUgZW5kIG9mIDIwMTAgYXMKICAgaXMgc3RpbGwgaW4gcHJvZ3Jlc3Mu ICBJbiBsaW5lIHdpdGggaXRzIGxvbmcgaGlzdG9yeSBvZiBsZXZlcmFnaW5nCiAgIElFVEYgcHJv dG9jb2xzLCBFVFNJIGNvdWxkIHBvdGVudGlhbGx5IGxldmVyYWdlIENETkkgaW50ZXJmYWNlcwog ICBkZXZlbG9wZWQgaW4gdGhlIElFVEYgZm9yIHRoZWlyIHJlbGF0ZWQgcHJvdG9jb2wgbGV2ZWwg d29yayBvbgogICBpbnRlcmNvbm5lY3Rpb25zIG9mIENETnMuCgpCLjIuOC4gIElUVS1UCgogICBT RzEzIGlzIGRldmVsb3Bpbmcgc3RhbmRhcmRzIHJlbGF0ZWQgdG8gdGhlIHN1cHBvcnQgb2YgSVBU ViBzZXJ2aWNlcwogICAoaS5lLi4gbXVsdGltZWRpYSBzZXJ2aWNlcyBzdWNoIGFzIHRlbGV2aXNp b24vVm9EL2F1ZGlvL3RleHQvCiAgIGdyYXBoaWNzL2RhdGEgZGVsaXZlcmVkIG92ZXIgSVAtYmFz ZWQgbWFuYWdlZCBuZXR3b3JrcykuCgogICBJVFUtVCBSZWNvbW1lbmRhdGlvbiBZLjE5MTAgW1ku MTkxMF0gcHJvdmlkZXMgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZQogICBJUFRWIGZ1bmN0aW9uYWwg YXJjaGl0ZWN0dXJlLiAgVGhpcyBhcmNoaXRlY3R1cmUgaW5jbHVkZXMgZnVuY3Rpb25zCiAgIGFu ZCBpbnRlcmZhY2VzIGZvciB0aGUgZGlzdHJpYnV0aW9uIGFuZCBkZWxpdmVyeSBvZiBjb250ZW50 LiAgVGhpcwogICBhcmNoaXRlY3R1cmUgaXMgYWxpZ25lZCB3aXRoIHRoZSBBVElTIElJRiBhcmNo aXRlY3R1cmUuCgogICBCYXNlZCB1cG9uIElUVS1UIFJlYy4gWS4xOTEwLCBJVFUtVCBSZWMuIFku MjAxOSBbWS4yMDE5XSBkZXNjcmliZXMgaW4KICAgbW9yZSBkZXRhaWwgdGhlIGNvbnRlbnQgZGVs aXZlcnkgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUuICBUaGlzCiAgIGFyY2hpdGVjdHVyZSBhbGxv d3MgQ0ROIEludGVyY29ubmVjdGlvbjogc29tZSBpbnRlcmZhY2VzIChzdWNoIGFzIEQzLAogICBE NCkgYXQgdGhlIGNvbnRyb2wgbGV2ZWwgYWxsb3cgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIGRpZmZl cmVudCBDRE5zLAogICBpbiB0aGUgc2FtZSBkb21haW4gb3IgaW4gZGlmZmVyZW50IGRvbWFpbnMu ICBHZW5lcmljIHByb2NlZHVyZXMgYXJlCiAgIGRlc2NyaWJlZCwgYnV0IHRoZSBjaG9pY2Ugb2Yg dGhlIHByb3RvY29scyBpcyBvcGVuLgoKQi4yLjkuICBPcGVuIElQVFYgRm9ydW0gKE9JUEYpCgog ICBUaGUgT3BlbiBJUFRWIEZvcnVtIGhhcyBkZXZlbG9wZWQgYW4gZW5kLXRvLWVuZCBzb2x1dGlv biB0byBhbGxvdyBhbnkKICAgT0lQRiB0ZXJtaW5hbCB0byBhY2Nlc3MgZW5yaWNoZWQgYW5kIHBl cnNvbmFsaXplZCBJUFRWIHNlcnZpY2VzCiAgIGVpdGhlciBpbiBhIG1hbmFnZWQgb3IgYSBub24t bWFuYWdlZCBuZXR3b3JrW09JUEYtT3ZlcnZpZXddLiAgU29tZQogICBPSVBGIHNlcnZpY2VzIChz dWNoIGFzIE5ldHdvcmsgUFZSKSBtYXkgYmUgaG9zdGVkIGluIGEgQ0ROLgoKICAgVG8gdGhhdCBl bmQsIHRoZSBPcGVuIElQVFYgRm9ydW0gc3BlY2lmaWNhdGlvbiBpcyBtYWRlIG9mIDUgcGFydHM6 CgogICBvICBNZWRpYSBGb3JtYXRzIGluY2x1ZGluZyBIVFRQIEFkYXB0aXZlIFN0cmVhbWluZwog ICBvICBDb250ZW50IE1ldGFkYXRhCiAgIG8gIFByb3RvY29scwogICBvICBUZXJtaW5hbCAoRGVj bGFyYXRpdmUgb3IgUHJvY2VkdXJhbCBBcHBsaWNhdGlvbiBFbnZpcm9ubWVudCkKICAgbyAgQXV0 aGVudGljYXRpb24sIENvbnRlbnQgUHJvdGVjdGlvbiBhbmQgU2VydmljZSBQcm90ZWN0aW9uCgpC LjIuMTAuICBUVi1Bbnl0aW1lIEZvcnVtCgogICBWZXJzaW9uIDEgb2YgdGhlIFRWLUFueXRpbWUg Rm9ydW0gc3BlY2lmaWNhdGlvbnMgd2VyZSBwdWJsaXNoZWQgYXMKICAgRVRTSSBUUyAxMDIgODIy LTEgdGhyb3VnaCBFVFNJIFRTIDEwMiA4MjItNyAiQnJvYWRjYXN0IGFuZCBPbi1saW5lCiAgIFNl cnZpY2VzOiBTZWFyY2gsIHNlbGVjdCwgYW5kIHJpZ2h0ZnVsIHVzZSBvZiBjb250ZW50IG9uIHBl cnNvbmFsCiAgIHN0b3JhZ2Ugc3lzdGVtcyAoIlRWLUFueXRpbWUiKSIuICBJdCBpbmNsdWRlcyB0 aGUgc3BlY2lmaWNhdGlvbiBvZgogICBjb250ZW50IG1ldGFkYXRhIGluIFhNTCBzY2hlbWFzIChF VFNJIFRTIDEwMiA4MjItMykgd2hpY2ggZGVmaW5lCgoKCk5pdmVuLUplbmtpbnMsIGV0IGFsLiAg IEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDMyXQoMCkludGVy bmV0LURyYWZ0ICAgIENETiBJbnRlcmNvbm5lY3Rpb24gUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg QXByaWwgMjAxMgoKCiAgIHRlY2huaWNhbCBwYXJhbWV0ZXJzIGZvciB0aGUgZGVzY3JpcHRpb24g b2YgQ29EIGFuZCBMaXZlIGNvbnRlbnRzLgogICBUaGUgc3BlY2lmaWNhdGlvbiBpcyByZWZlcmVu Y2VkIGJ5IERWQiBhbmQgT0lQRi4KCiAgIFRoZSBUVi1hbnl0aW1lIEZvcnVtIHdhcyBjbG9zZWQg aW4gMjAwNS4KCkIuMi4xMS4gIFNOSUEKCiAgIFRoZSBTdG9yYWdlIE5ldHdvcmtpbmcgSW5kdXN0 cnkgQXNzb2NpYXRpb24gKFNOSUEpIGlzIGFuIGFzc29jaWF0aW9uCiAgIG9mIHByb2R1Y2VycyBh bmQgY29uc3VtZXJzIG9mIHN0b3JhZ2UgbmV0d29ya2luZyBwcm9kdWN0cyB3aG9zZSBnb2FsCiAg IGlzIHRvIGZ1cnRoZXIgc3RvcmFnZSBuZXR3b3JraW5nIHRlY2hub2xvZ3kgYW5kIGFwcGxpY2F0 aW9ucy4KCiAgIFNOSUEgaGFzIHB1Ymxpc2hlZCB0aGUgQ2xvdWQgRGF0YSBNYW5hZ2VtZW50IElu dGVyZmFjZSAoQ0RNSSkKICAgc3RhbmRhcmQgKFtTTklBLUNETUldKS4KCiAgICJUaGUgQ2xvdWQg RGF0YSBNYW5hZ2VtZW50IEludGVyZmFjZSBkZWZpbmVzIHRoZSBmdW5jdGlvbmFsIGludGVyZmFj ZQogICB0aGF0IGFwcGxpY2F0aW9ucyB3aWxsIHVzZSB0byBjcmVhdGUsIHJldHJpZXZlLCB1cGRh dGUgYW5kIGRlbGV0ZQogICBkYXRhIGVsZW1lbnRzIGZyb20gdGhlIENsb3VkLiAgQXMgcGFydCBv ZiB0aGlzIGludGVyZmFjZSB0aGUgY2xpZW50CiAgIHdpbGwgYmUgYWJsZSB0byBkaXNjb3ZlciB0 aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBjbG91ZCBzdG9yYWdlCiAgIG9mZmVyaW5nIGFuZCB1c2Ug dGhpcyBpbnRlcmZhY2UgdG8gbWFuYWdlIGNvbnRhaW5lcnMgYW5kIHRoZSBkYXRhCiAgIHRoYXQg aXMgcGxhY2VkIGluIHRoZW0uICBJbiBhZGRpdGlvbiwgbWV0YWRhdGEgY2FuIGJlIHNldCBvbgog ICBjb250YWluZXJzIGFuZCB0aGVpciBjb250YWluZWQgZGF0YSBlbGVtZW50cyB0aHJvdWdoIHRo aXMgaW50ZXJmYWNlLiIKCkIuMi4xMi4gIFN1bW1hcnkgb2YgZXhpc3Rpbmcgc3RhbmFyZGl6YXRp b24gd29yawoKICAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3aWxsIHN1bW1hcml6ZSB0aGUgZXhp c3Rpbmcgd29yayBvZiB0aGUKICAgc3RhbmRhcmQgYm9kaWVzIGxpc3RlZCBlYXJsaWVyIGFnYWlu c3QgdGhlIENETkkgcHJvYmxlbSBzcGFjZS4KICAgQXBwZW5kaXggQi4yLjEyLjEgc3VtbWFyaXpl cyBleGlzdGluZyBpbnRlcmZhY2VzIHRoYXQgY291bGQgYmUKICAgbGV2ZXJhZ2VkIGZvciBjb250 ZW50IGFjcXVpc2l0aW9uIGJldHdlZW4gQ0ROcyBhbmQgQXBwZW5kaXggQi4yLjEyLjIKICAgc3Vt bWFyaXplcyBleGlzdGluZyBtZXRhZGF0YSBzcGVjaWZpY2F0aW9ucyB0aGF0IG1heSBiZSBhcHBs aWNhYmxlIHRvCiAgIENETkkuICBUbyBkYXRlIHdlIGFyZSBub3QgYXdhcmUgb2YgYW55IHN0YW5k YXJkaXphdGlvbiBhY3Rpdml0aWVzIGluCiAgIHRoZSBhcmVhcyBvZiB0aGUgcmVtYWluaW5nIENE TkkgaW50ZXJmYWNlcyAoQ0ROSSBSZXF1ZXN0IFJvdXRpbmcsCiAgIENETkkgQ29udHJvbCBhbmQg Q0ROSSBMb2dnaW5nKS4KCkIuMi4xMi4xLiAgQ29udGVudCBBY3F1aXNpdGlvbiBhY3Jvc3MgQ0RO cyBhbmQgRGVsaXZlcnkgdG8gRW5kIFVzZXIKICAgICAgICAgICAoRGF0YSBwbGFuZSkKCiAgIEEg bnVtYmVyIG9mIHN0YW5kYXJkcyBib2RpZXMgaGF2ZSBjb21wbGV0ZWQgd29yayBpbiB0aGUgYXJl YXMgb2YKICAgY29udGVudCBhY3F1aXNpdGlvbiBpbnRlcmZhY2UgYmV0d2VlbiBhIENTUCBhbmQg YSBDRE4sIGFzIHdlbGwgYXMgYXMKICAgb24gdGhlIGRlbGl2ZXJ5IGludGVyZmFjZSBiZXR3ZWVu IHRoZSBzdXJyb2dhdGUgYW5kIHRoZSBVc2VyIEFnZW50LgogICBTb21lIG9mIHRoaXMgd29yayBp cyBzdW1tYXJpemVkIGJlbG93LgoKICAgVElTUEFOLCBPSVBGIGFuZCBBVElTIGhhdmUgc3BlY2lm aWVkIElQVFYgYW5kL29yIENvbnRlbnQgb24gRGVtYW5kCiAgIChDb0QpIHNlcnZpY2VzLCBpbmNs dWRpbmcgdGhlIGRhdGEgcGxhbmUgYXNwZWN0cyAodHlwaWNhbGx5IGRpZmZlcmVudAogICBmbGF2 b3JzIG9mIFJUUC9SVENQIGFuZCBIVFRQKSB0byBvYnRhaW4gY29udGVudCBhbmQgZGVsaXZlciBp dCB0bwogICBVc2VyIEFnZW50cy4gIEZvciBleGFtcGxlLCA6CiAgIG8gIFRoZSBPSVBGIGRhdGEg cGxhbmUgaW5jbHVkZXMgYm90aCBSVFAgYW5kIEhUVFAgZmxhdm9ycyAoSFRUUAogICAgICBwcm9n cmVzc2l2ZSBkb3dubG9hZCwgSFRUUCBBZGFwdGl2ZSBzdHJlYW1pbmcgWzNHUC1EQVNIXSkuCgoK CgpOaXZlbi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMTIgICAgICAg ICAgICAgICBbUGFnZSAzM10KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4gSW50ZXJjb25uZWN0aW9u IFByb2JsZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgogICBvICBUaGUgQVRJUyBJSUYg c3BlY2lmaWNhdGlvbiAiSVBUViBDb250ZW50IG9uIERlbWFuZCAoQ29EKSBTZXJ2aWNlIgogICAg ICBbQVRJUy1DT0RdIGRlZmluZXMgYSByZWZlcmVuY2UgcG9pbnQgKEMyKSBhbmQgdGhlIGNvcnJl c3BvbmRpbmcKICAgICAgSFRUUC1iYXNlZCBkYXRhIHBsYW5lIHByb3RvY29sIGZvciBjb250ZW50 IGFjcXVpc2l0aW9uIGJldHdlZW4gYW4KICAgICAgYXV0aG9yaXRhdGl2ZSBvcmlnaW4gc2VydmVy IGFuZCB0aGUgQ0ROLgogICBXaGlsZSB0aGVzZSBwcm90b2NvbHMgaGF2ZSBub3QgYmVlbiBleHBs aWNpdGx5IHNwZWNpZmllZCBmb3IgY29udGVudAogICBhY3F1aXNpdGlvbiBhY3Jvc3MgQ0ROcywg dGhleSBhcmUgc3VpdGFibGUgKGluIGFkZGl0aW9uIHRvIG90aGVycwogICBzdWNoIGFzIHN0YW5k YXJkIEhUVFApIGZvciBjb250ZW50IGFjcXVpc2l0aW9uIGJldHdlZW4gQ0ROcyBpbiBhIENETgog ICBJbnRlcmNvbm5lY3Rpb24gZW52aXJvbm1lbnQuICBUaGVyZWZvcmUgZm9yIHRoZSBwdXJwb3Nl IG9mIHRoZSBDRE5JCiAgIHdvcmtpbmcgZ3JvdXAgdGhlcmUgYXJlIGFscmVhZHkgbXVsdGlwbGUg ZXhpc3RpbmcgZGF0YSBwbGFuZQogICBwcm90b2NvbHMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgY29u dGVudCBhY3F1aXNpdGlvbiBhY3Jvc3MgQ0ROcy4KCiAgIFNpbWlsYXJseSwgdGhlcmUgYXJlIG11 bHRpcGxlIGV4aXN0aW5nIHN0YW5kYXJkcyAoZS5nLiB0aGUgT0lQRiBkYXRhCiAgIHBsYW5lIG1l bnRpb25lZCBhYm92ZSwgSFRUUCBhZGFwdGl2ZSBzdHJlYW1pbmcgWzNHUC1EQVNIXSkgb3IgcHVi bGljCiAgIHNwZWNpZmljYXRpb25zIChlLmcuIHZlbmRvciBzcGVjaWZpYyBIVFRQIEFkYXB0aXZl IHN0cmVhbWluZwogICBzcGVjaWZpY2F0aW9ucykgc28gdGhhdCBjb250ZW50IGRlbGl2ZXJ5IGNh biBiZSBjb25zaWRlcmVkIGFscmVhZHkKICAgc29sdmVkIChvciBhdCBsZWFzdCBzdWZmaWNpZW50 bHkgYWRkcmVzc2VkIGluIG90aGVyIGZvcnVtcykuCgogICBUaHVzLCBzcGVjaWZpY2F0aW9uIG9m IHRoZSBjb250ZW50IGFjcXVpc2l0aW9uIGludGVyZmFjZSBiZXR3ZWVuIENETnMKICAgYW5kIHRo ZSBkZWxpdmVyeSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgc3Vycm9nYXRlIGFuZCB0aGUgVXNlciBB Z2VudAogICBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGUgQ0ROSSB3b3JraW5nIGdyb3VwLiAgVGhl IENETkkgd29ya2luZyBncm91cAogICBtYXkgb25seSBjb25jZXJuIGl0c2VsZiB3aXRoIHRoZSBu ZWdvdGlhdGlvbi9zZWxlY3Rpb24gYXNwZWN0cyBvZiB0aGUKICAgYWNxdWlzaXRpb24gcHJvdG9j b2wgdG8gYmUgdXNlZCBpbiBhIENETiBpbnRlcm9ubmVjdCBzY2VuYXJpby4KCkIuMi4xMi4yLiAg Q0ROSSBNZXRhZGF0YQoKICAgQ2FibGVMYWJzLCBJVFUsIE9JUEYgYW5kIFRWLUFueXRpbWUgaGF2 ZSB3b3JrIGl0ZW1zIGRlZGljYXRlZCB0byB0aGUKICAgc3BlY2lmaWNhdGlvbiBvZiBjb250ZW50 IG1ldGFkYXRhOgoKICAgbyAgQ2FibGVMYWJzIGhhcyBkZWZpbmVkIHNwZWNpZmljYXRpb25zIGZv ciBDb0QgQ29udGVudCBNZXRhZGF0YSBhcwogICAgICBwYXJ0IG9mIGl0cyBWT0QgTWV0YWRhdGEg cHJvamVjdC4gICJUaGUgVk9EIE1ldGFkYXRhIHByb2plY3QgaXMgYQogICAgICBjYWJsZSB0ZWxl dmlzaW9uIGluZHVzdHJ5IGFuZCBjcm9zcy1pbmR1c3RyeS13aWRlIGVmZm9ydCB0bwogICAgICBz cGVjaWZ5IHRoZSBtZXRhZGF0YSBhbmQgaW50ZXJmYWNlcyBmb3IgZGlzdHJpYnV0aW9uIG9mIHZp ZGVvLW9uLQogICAgICBkZW1hbmQgKFZPRCkgbWF0ZXJpYWwgZnJvbSBtdWx0aXBsZSBjb250ZW50 IHByb3ZpZGVycyB0byBjYWJsZQogICAgICBvcGVyYXRvcnMuIiAgW0NhYmxlTGFicy1NZXRhZGF0 YV0uICBIb3dldmVyLCB3aGlsZSB0aGUgQ2FibGVMYWJzCiAgICAgIHdvcmsgc3BlY2lmaWVzIGFu IGludGVyZmFjZSBiZXR3ZWVuIGEgY29udGVudCBwcm92aWRlciBhbmQgYQogICAgICBzZXJ2aWNl IHByb3ZpZGVyIHJ1bm5pbmcgYSBDRE4sIGl0IGRvZXMgbm90IGluY2x1ZGUgYW4gaW50ZXJmYWNl CiAgICAgIHRoYXQgY291bGQgYmUgdXNlZCBiZXR3ZWVuIENETnMuCiAgIG8gIElUVSBTdHVkeSBH cm91cCAxNiBoYXMgc3RhcnRlZCB3b3JrIG9uIGEgbnVtYmVyIG9mIGRyYWZ0CiAgICAgIFJlY29t bWVuZGF0aW9ucyAoSC5JUFRWLUNQTUQsIEguSVBUVi1DUE1ELCBIU1RQLklQVFYtQ01BLAogICAg ICBIU1RQLklQVFYtVU1DSSkgc3BlY2lmeWluZyBtZXRhZGF0YSBmb3IgY29udGVudCBkaXN0cmli dXRpb24gaW4KICAgICAgSVBUViBzZXJ2aWNlcy4KICAgbyAgQW4gT3BlbiBJUFRWIFRlcm1pbmFs IHJlY2VpdmVzIHRoZSB0ZWNobmljYWwgZGVzY3JpcHRpb24gb2YgdGhlCiAgICAgIGNvbnRlbnQg ZGlzdHJpYnV0aW9uIGZyb20gdGhlIE9JUEYgSVBUViBwbGF0Zm9ybSBiZWZvcmUgcmVjZWl2aW5n CiAgICAgIGFueSBjb250ZW50LiAgVGhlIENvbnRlbnQgZGlzdHJpYnV0aW9uIG1ldGFkYXRhIGlz IHNlbnQgaW4gdGhlCiAgICAgIGZvcm1hdCBvZiBhIFRWLUFueXRpbWUgWFNEIGluY2x1ZGluZyB0 YWdzIHRvIGRlc2NyaWJlcyB0aGUKICAgICAgbG9jYXRpb24gYW5kIHByb2dyYW0gdHlwZSAob24g ZGVtYW5kIG9yIExpdmUpIGFzIHdlbGwgYXMKICAgICAgZGVzY3JpYmluZyB0aGUgdGltZSBhdmFp bGFiaWxpdHkgb2YgdGhlIG9uIGRlbWFuZCBhbmQgbGl2ZQogICAgICBjb250ZW50LgoKCgpOaXZl bi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMTIgICAgICAgICAgICAg ICBbUGFnZSAzNF0KDApJbnRlcm5ldC1EcmFmdCAgICBDRE4gSW50ZXJjb25uZWN0aW9uIFByb2Js ZW0gU3RhdGVtZW50ICAgICAgIEFwcmlsIDIwMTIKCgogICBIb3dldmVyIHRoZSBzcGVjaWZpY2F0 aW9ucyBvdXRsaW5lZCBhYm92ZSBkbyBub3QgaW5jbHVkZSBtZXRhZGF0YQogICBzcGVjaWZpYyB0 byB0aGUgZGlzdHJpYnV0aW9uIG9mIGNvbnRlbnQgd2l0aGluIGEgQ0ROIG9yIGJldHdlZW4KICAg aW50ZXJjb25uZWN0ZWQgQ0ROcywgZm9yIGV4YW1wbGUgZ2VvLWJsb2NraW5nIGluZm9ybWF0aW9u LAogICBhdmFpbGFiaWxpdHkgd2luZG93cywgYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtcyB0byBi ZSBlbmZvcmNlZCBieSB0aGUKICAgc3Vycm9nYXRlLCBob3cgdG8gbWFwIGFuIGluY29taW5nIGNv bnRlbnQgcmVxdWVzdCB0byBhIGZpbGUgb24gdGhlCiAgIG9yaWdpbiBzZXJ2ZXIgb3IgYWNxdWly ZSBpdCBmcm9tIHRoZSB1cHN0cmVhbSBDRE4gZXRjLgoKICAgVGhlIENETUkgc3RhbmRhcmQgKFtT TklBLUNETUldKSBmcm9tIFNOSUEgZGVmaW5lcyBtZXRhZGF0YSB0aGF0IGNhbgogICBiZSBhc3Nv Y2lhdGVkIHdpdGggZGF0YSB0aGF0IGlzIHN0b3JlZCBieSBhIGNsb3VkIHN0b3JhZ2UgcHJvdmlk ZXIuCiAgIFdoaWxlIHRoZSBtZXRhZGF0YSBjdXJyZW50bHkgZGVmaW5lZCBkbyBub3QgbWF0Y2gg dGhlIG5lZWRzIG9mIENETgogICBJbnRlcmNvbm5lY3Rpb24sIGl0IGlzIHdvcnRoIGNvbnNpZGVy aW5nIENETUkgYXMgb25lIG9mIHRoZSBleGlzdGluZwogICBwaWVjZXMgb2Ygd29yayB0aGF0IG1h eSBwb3RlbnRpYWxseSBiZSBsZXZlcmFnZWQgZm9yIHRoZSBDRE5JCiAgIE1ldGFkYXRhIGludGVy ZmFjZSAoZS5nIGJ5IGV4dGVuZGluZyB0aGUgQ0RNSSBtZXRhZGF0YSB0byBhZGRyZXNzCiAgIG1v cmUgc3BlY2lmaWMgQ0ROSSBuZWVkcykuCgpCLjMuICBSZWxhdGVkIFJlc2VhcmNoIFByb2plY3Rz CgpCLjMuMS4gIElSVEYgUDJQIFJlc2VhcmNoIEdyb3VwCgogICBTb21lIGluZm9ybWF0aW9uIG9u IENETiBpbnRlcmNvbm5lY3Rpb24gbW90aXZhdGlvbnMgYW5kIHRlY2huaWNhbAogICBpc3N1ZXMg d2VyZSBwcmVzZW50ZWQgaW4gdGhlIFAyUCBSRyBhdCBJRVRGIDc3LiAgVGhlIHByZXNlbnRhdGlv biBjYW4KICAgYmUgZm91bmQgaW4gW1AyUFJHLUNETkldLgoKQi4zLjIuICBPQ0VBTgoKICAgT0NF QU4gKGh0dHA6Ly93d3cuaWN0LW9jZWFuLmV1LykgaXMgYW4gRVUgZnVuZGVkIHJlc2VhcmNoIHBy b2plY3QKICAgdGhhdCBzdGFydGVkIGluIEZlYnJ1YXJ5IDIwMTAgZm9yIDMgeWVhcnMuICBTb21l IG9mIGl0cyBvYmplY3RpdmVzCiAgIGFyZSByZWxldmFudCB0byBDRE5JLiAgSXQgYWltcywgYW1v bmcgb3RoZXIgdGhpbmdzLCBhdCBkZXNpZ25pbmcgYQogICBuZXcgYXJjaGl0ZWN0dXJhbCBmcmFt ZXdvcmsgZm9yIGF1ZGlvdmlzdWFsIGNvbnRlbnQgZGVsaXZlcnkgb3ZlciB0aGUKICAgSW50ZXJu ZXQsIGRlZmluaW5nIHB1YmxpYyBpbnRlcmZhY2VzIGJldHdlZW4gaXRzIG1ham9yIGJ1aWxkaW5n CiAgIGJsb2NrcyBpbiBvcmRlciB0byBmb3N0ZXIgbXVsdGktdmVuZG9yIHNvbHV0aW9ucyBhbmQg aW50ZXJjb25uZWN0aW9uCiAgIGJldHdlZW4gQ29udGVudCBOZXR3b3JrcyAodGhlIHRlcm0gIkNv bnRlbnQgTmV0d29ya3MiIGNvcnJlc3BvbmRzCiAgIGhlcmUgdG8gdGhlIGRlZmluaXRpb24gaW50 cm9kdWNlZCBpbiBbUkZDMzQ2Nl0sIHdoaWNoIGVuY29tcGFzc2VzCiAgIENETnMpLgoKICAgT0NF QU4gaGFzIG5vdCB5ZXQgcHVibGlzaGVkIGFueSBvcGVuIHNwZWNpZmljYXRpb25zLCBub3IgY29t bW9uIGJlc3QKICAgcHJhY3RpY2VzLCBkZWZpbmluZyBob3cgdG8gYWNoaWV2ZSBzdWNoIENETiBp bnRlcmNvbm5lY3Rpb24uCgpCLjMuMy4gIEV1cmVzY29tIFAxOTU1CgogICBFdXJlc2NvbSBQMTk1 NSB3YXMgYSAyMDEwIHJlc2VhcmNoIHByb2plY3QgaW52b2x2aW5nIGEgZm91ciBFdXJvcGVhbgog ICBOZXR3b3JrIG9wZXJhdG9ycywgd2hpY2ggc3R1ZGllZCB0aGUgaW50ZXJlc3RzIGFuZCBmZWFz aWJpbGl0eSBvZgogICBpbnRlcmNvbm5lY3RpbmcgQ0ROcyBieSBmaXJzdGx5IGVsYWJvcmF0aW5n IHRoZSBtYWluIHNlcnZpY2UgbW9kZWxzCiAgIGFyb3VuZCBDRE4gaW50ZXJjb25uZWN0aW9uLCBh cyB3ZWxsIGFzIGFuYWx5emluZyBhbiBhZGVxdWF0ZSBDRE4KICAgaW50ZXJjb25uZWN0aW9uIHRl Y2huaWNhbCBhcmNoaXRlY3R1cmUgYW5kIGZyYW1ld29yaywgYW5kIGZpbmFsbHkgYnkKICAgcHJv dmlkaW5nIHJlY29tbWVuZGF0aW9ucyBmb3IgdGVsY29zIHRvIGltcGxlbWVudCBDRE4KICAgaW50 ZXJjb25uZWN0aW9uLiAgVGhlIEV1cmVzY29tIFAxOTU1IHByb2plY3QgZW5kZWQgaW4gSnVseSAy MDEwLgoKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEy ICAgICAgICAgICAgICAgW1BhZ2UgMzVdCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIEludGVyY29u bmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgVGhlIGF1dGhv cnMgYXJlIG5vdCBhd2FyZSBvZiBtYXRlcmlhbCBkaXNjdXNzaW5nIENETiBpbnRlcmNvbm5lY3Rp b24KICAgcHJvdG9jb2xzIG9yIGludGVyZmFjZXMgbWFkZSBwdWJsaWNseSBhdmFpbGFibGUgYXMg YSBkZWxpdmVyYWJsZSBvZgogICB0aGlzIHByb2plY3QuCgpCLjQuICBSZWxhdGlvbnNoaXAgdG8g cmVsZXZhbnQgSUVURiBXb3JraW5nIEdyb3VwcwoKQi40LjEuICBBTFRPCgogICBBcyBzdGF0ZWQg aW4gdGhlIEFMVE8gV29ya2luZyBHcm91cCBjaGFydGVyIFtBTFRPLUNoYXJ0ZXJdOgoKICAgIlRo ZSBXb3JraW5nIEdyb3VwIHdpbGwgZGVzaWduIGFuZCBzcGVjaWZ5IGFuIEFwcGxpY2F0aW9uLUxh eWVyCiAgIFRyYWZmaWMgT3B0aW1pemF0aW9uIChBTFRPKSBzZXJ2aWNlIHRoYXQgd2lsbCBwcm92 aWRlIGFwcGxpY2F0aW9ucwogICB3aXRoIGluZm9ybWF0aW9uIHRvIHBlcmZvcm0gYmV0dGVyLXRo YW4tcmFuZG9tIGluaXRpYWwgcGVlcgogICBzZWxlY3Rpb24uICBBTFRPIHNlcnZpY2VzIG1heSB0 YWtlIGRpZmZlcmVudCBhcHByb2FjaGVzIGF0IGJhbGFuY2luZwogICBmYWN0b3JzIHN1Y2ggYXMg bWF4aW11bSBiYW5kd2lkdGgsIG1pbmltdW0gY3Jvc3MtZG9tYWluIHRyYWZmaWMsCiAgIGxvd2Vz dCBjb3N0IHRvIHRoZSB1c2VyLCBldGMuICBUaGUgd29ya2luZyBncm91cCB3aWxsIGNvbnNpZGVy IHRoZQogICBuZWVkcyBvZiBCaXRUb3JyZW50LCB0cmFja2VyLWxlc3MgUDJQLCBhbmQgb3RoZXIg YXBwbGljYXRpb25zLCBzdWNoCiAgIGFzIGNvbnRlbnQgZGVsaXZlcnkgbmV0d29ya3MgKENETikg YW5kIG1pcnJvciBzZWxlY3Rpb24uIgoKICAgSW4gcGFydGljdWxhciwgdGhlIEFMVE8gc2Vydmlj ZSBjYW4gYmUgdXNlZCBieSBhIENETiBSZXF1ZXN0IFJvdXRpbmcKICAgc3lzdGVtIHRvIGltcHJv dmUgaXRzIHNlbGVjdGlvbiBvZiBhIENETiBzdXJyb2dhdGUgdG8gc2VydmUgYQogICBwYXJ0aWN1 bGFyIFVzZXIgQWdlbnQgcmVxdWVzdCAob3IgdG8gc2VydmUgYSByZXF1ZXN0IGZyb20gYW5vdGhl cgogICBzdXJyb2dhdGUpLiAgW0ktRC5qZW5raW5zLWFsdG8tY2RuLXVzZS1jYXNlc10gZGVzY3Jp YmVzIGEgbnVtYmVyIG9mCiAgIHVzZSBjYXNlcyBmb3IgYSBDRE4gdG8gYmUgYWJsZSB0byBvYnRh aW4gbmV0d29yayB0b3BvbG9neSBhbmQgY29zdAogICBpbmZvcm1hdGlvbiBmcm9tIGFuIEFMVE8g c2VydmVyKHMpIGFuZCBkaXNjdXNzZXMgaG93IENETiBSZXF1ZXN0CiAgIFJvdXRpbmcgY291bGQg YmUgdXNlZCBhcyBhbiBpbnRlZ3JhdGlvbiBwb2ludCBvZiBBTFRPIGludG8gQ0ROcy4gIEl0CiAg IGlzIHBvc3NpYmxlIHRoYXQgdGhlIEFMVE8gc2VydmljZSBjb3VsZCBiZSB1c2VkIGluIHRoZSBz YW1lIG1hbm5lciBpbgogICBhIG11bHRpLUNETiBlbnZpcm9ubWVudCBiYXNlZCBvbiBDRE4gSW50 ZXJjb25uZWN0aW9uLiAgRm9yIGV4YW1wbGUsCiAgIGFuIHVwc3RyZWFtIENETiBtYXkgdGFrZSBh ZHZhbnRhZ2Ugb2YgdGhlIEFMVE8gc2VydmljZSBpbiBpdHMKICAgZGVjaXNpb24gZm9yIHNlbGVj dGluZyBhIGRvd25zdHJlYW0gQ0ROIHRvIHdoaWNoIGEgdXNlciByZXF1ZXN0CiAgIHNob3VsZCBi ZSBkZWxlZ2F0ZWQuCgogICBIb3dldmVyLCB0aGUgY3VycmVudCB3b3JrIG9mIEFMVE8gaXMgY29t cGxlbWVudGFyeSB0byBhbmQgZG9lcyBub3QKICAgb3ZlcmxhcCB3aXRoIHRoZSB3b3JrIGRlc2Ny aWJlZCBpbiB0aGlzIGRvY3VtZW50IGJlY2F1c2UgdGhlCiAgIGludGVncmF0aW9uIGJldHdlZW4g QUxUTyBhbmQgYSBDRE4gaXMgYW4gaW50ZXJuYWwgZGVjaXNpb24gZm9yIGEKICAgc3BlY2lmaWMg Q0ROIGFuZCBpcyB0aGVyZWZvcmUgb3V0IG9mIHNjb3BlIGZvciB0aGUgQ0ROSSB3b3JraW5nCiAg IGdyb3VwLiAgT25lIGFyZWEgZm9yIGZ1cnRoZXIgc3R1ZHkgaXMgd2hldGhlciBhZGRpdGlvbmFs IGluZm9ybWF0aW9uCiAgIHNob3VsZCBiZSBwcm92aWRlZCBieSBhbiBBTFRPIHNlcnZpY2UgdG8g ZmFjaWxpdGF0ZSBDRE5JIENETgogICBzZWxlY3Rpb24uCgpCLjQuMi4gIERFQ0FERQoKICAgVGhl IERFQ0FERSBXb3JraW5nIEdyb3VwIFtERUNBREUtQ2hhcnRlcl0gaXMgYWRkcmVzc2luZyB0aGUg cHJvYmxlbQogICBvZiByZWR1Y2luZyB0cmFmZmljIG9uIHRoZSBsYXN0LW1pbGUgdXBsaW5rLCBh cyB3ZWxsIGFzIGJhY2tib25lIGFuZAogICB0cmFuc2l0IGxpbmtzIGNhdXNlZCBieSBQMlAgc3Ry ZWFtaW5nIGFuZCBmaWxlIHNoYXJpbmcgYXBwbGljYXRpb25zLgogICBJdCBhZGRyZXNzZXMgdGhl IHByb2JsZW0gYnkgZW5hYmxpbmcgYW4gYXBwbGljYXRpb24gZW5kcG9pbnQgdG8gbWFrZQogICBj b250ZW50IGF2YWlsYWJsZSBmcm9tIGFuIGluLW5ldHdvcmsgc3RvcmFnZSBzZXJ2aWNlIGFuZCBi eSBlbmFibGluZwogICBvdGhlciBhcHBsaWNhdGlvbiBlbmRwb2ludHMgdG8gcmV0cmlldmUgdGhl IGNvbnRlbnQgZnJvbSB0aGVyZS4KCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBO b3ZlbWJlciAxLCAyMDEyICAgICAgICAgICAgICAgW1BhZ2UgMzZdCgwKSW50ZXJuZXQtRHJhZnQg ICAgQ0ROIEludGVyY29ubmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEy CgoKICAgRXhjaGFuZ2luZyBkYXRhIHRocm91Z2ggdGhlIGluLW5ldHdvcmsgc3RvcmFnZSBzZXJ2 aWNlIGluIHRoaXMKICAgbWFubmVyLCBpbnN0ZWFkIG9mIHRocm91Z2ggZGlyZWN0IGNvbW11bmlj YXRpb24sIHByb3ZpZGVzIHNpZ25pZmljYW50CiAgIGdhaW4gd2hlcmU6CgogICBvICBUaGUgbmV0 d29yayBjYXBhY2l0eS9iYW5kd2lkdGggZnJvbSBpbi1uZXR3b3JrIHN0b3JhZ2Ugc2VydmljZSB0 bwogICAgICBhcHBsaWNhdGlvbiBlbmRwb2ludCBzaWduaWZpY2FudGx5IGV4Y2VlZHMgdGhlIGNh cGFjaXR5L2JhbmR3aWR0aAogICAgICBmcm9tIGFwcGxpY2F0aW9uIGVuZHBvaW50IHRvIGFwcGxp Y2F0aW9uIGVuZHBvaW50IChlLmcuIGJlY2F1c2Ugb2YKICAgICAgYW4gZW5kLXVzZXIgdXBsaW5r IGJvdHRsZW5lY2spOyBhbmQKICAgbyAgV2hlcmUgdGhlIGNvbnRlbnQgaXMgdG8gYmUgYWNjZXNz ZWQgYnkgbXVsdGlwbGUgaW5zdGFuY2VzIG9mCiAgICAgIGFwcGxpY2F0aW9uIGVuZHBvaW50cyAo ZS5nLiBhcyBpcyB0eXBpY2FsbHkgdGhlIGNhc2UgZm9yIFAyUAogICAgICBhcHBsaWNhdGlvbnMp LgoKICAgV2hpbGUsIGFzIGlzIHRoZSBjYXNlIGZvciBhbnkgb3RoZXIgZGF0YSBkaXN0cmlidXRp b24gYXBwbGljYXRpb24sCiAgIHRoZSBERUNBREUgYXJjaGl0ZWN0dXJlIGFuZCBtZWNoYW5pc21z IGNvdWxkIHBvdGVudGlhbGx5IGJlIHVzZWQgZm9yCiAgIGV4Y2hhbmdlIG9mIENETkkgY29udHJv bCBwbGFuZSBpbmZvcm1hdGlvbiB2aWEgYW4gaW4tbmV0d29yay1zdG9yYWdlCiAgIHNlcnZpY2Ug KGFzIG9wcG9zZWQgdG8gZGlyZWN0bHkgYmV0d2VlbiB0aGUgZW50aXRpZXMgdGVybWluYXRpbmcg dGhlCiAgIENETkkgaW50ZXJmYWNlcyBpbiB0aGUgbmVpZ2hib3IgQ0ROcyksIHdlIG9ic2VydmUg dGhhdDoKCiAgIG8gIENETkkgd291bGQgb3BlcmF0ZSBhcyBhICJDb250ZW50IERpc3RyaWJ1dGlv biBBcHBsaWNhdGlvbiIgZnJvbQogICAgICB0aGUgREVDQURFIHZpZXdwb2ludCAoaS5lLiB3b3Vs ZCBvcGVyYXRlIG9uIHRvcCBvZiBERUNBREUpLgogICBvICBUaGVyZSBkb2VzIG5vdCBzZWVtIHRv IGJlIG9idmlvdXMgYmVuZWZpdHMgaW4gaW50ZWdyYXRpbmcgdGhlCiAgICAgIERFQ0FERSBjb250 cm9sIHBsYW5lIHJlc3BvbnNpYmxlIGZvciBzaWduYWxpbmcgaW5mb3JtYXRpb24KICAgICAgcmVs YXRpbmcgdG8gY29udHJvbCBvZiB0aGUgaW4tbmV0d29yayBzdG9yYWdlIHNlcnZpY2UgaXRzZWxm LCBhbmQKICAgICAgdGhlIENETkkgY29udHJvbCBwbGFuZSByZXNwb25zaWJsZSBmb3IgYXBwbGlj YXRpb24tc3BlY2lmaWMgQ0ROSQogICAgICBpbnRlcmFjdGlvbnMgKHN1Y2ggYXMgZXhjaGFuZ2Ug b2YgQ0ROSSBtZXRhZGF0YSwgQ0ROSSByZXF1ZXN0CiAgICAgIHJlZGlyZWN0aW9uLCB0cmFuc2Zl ciBvZiBDRE5JIGxvZ2dpbmcgaW5mb3JtYXRpb24pLgogICBvICBUaGVyZSB3b3VsZCB0eXBpY2Fs bHkgYmUgbGltaXRlZCBiZW5lZml0cyBpbiBtYWtpbmcgdXNlIG9mIGEKICAgICAgREVDQURFIGlu LW5ldHdvcmsgc3RvcmFnZSBzZXJ2aWNlIGJlY2F1c2UgdGhlIENETkkgaW50ZXJmYWNlcyBhcmUK ICAgICAgZXhwZWN0ZWQgdG8gYmUgdGVybWluYXRlZCBieSBhIHZlcnkgc21hbGwgbnVtYmVyIG9m IENETkkgY2xpZW50cwogICAgICAoaWYgbm90IG9uZSkgaW4gZWFjaCBDRE4sIGFuZCB0aGUgQ0RO SSBjbGllbnRzIGFyZSBleHBlY3RlZCB0bwogICAgICBiZW5lZml0IGZyb20gaGlnaCBiYW5kd2lk dGgvY2FwYWNpdHkgd2hlbiBjb21tdW5pY2F0aW5nIGRpcmVjdGx5CiAgICAgIHRvIGVhY2ggb3Ro ZXIgKGF0IGxlYXN0IGFzIGhpZ2ggYXMgaWYgdGhleSB3ZXJlIGNvbW11bmljYXRpbmcgdmlhCiAg ICAgIGFuIGluLW5ldHdvcmsgc3RvcmFnZSBzZXJ2ZXIpLgoKICAgVGhlIERFQ0FERSBpbi1uZXR3 b3JrIHN0b3JhZ2UgYXJjaGl0ZWN0dXJlIGFuZCBtZWNoYW5pc21zIG1heQogICB0aGVvcmV0aWNh bGx5IGJlIHVzZWQgZm9yIHRoZSBhY3F1aXNpdGlvbiBvZiB0aGUgY29udGVudCBvYmplY3RzCiAg IHRoZW1zZWx2ZXMgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zLiAgSXQgaXMgbm90IGV4cGVj dGVkIHRoYXQgdGhpcwogICB3b3VsZCBoYXZlIG9idmlvdXMgYmVuZWZpdHMgaW4gdHlwaWNhbCBz aXR1YXRpb25zIHdoZXJlIGEgY29udGVudAogICBvYmplY3QgaXMgYWNxdWlyZWQgb25seSBvbmNl IGZyb20gYW4gVXBzdHJlYW0gQ0ROIHRvIGEgRG93bnN0cmVhbSBDRE4KICAgKGFuZCB0aGVuIGRp c3RyaWJ1dGVkIGFzIG5lZWRlZCBpbnNpZGUgdGhlIERvd25zdHJlYW0gQ0ROKS4gIEJ1dCBpdAog ICBtaWdodCBoYXZlIGJlbmVmaXRzIGluIHNvbWUgcGFydGljdWxhciBzaXR1YXRpb25zLiAgU2lu Y2UgdGhlCiAgIGFjcXVpc2l0aW9uIHByb3RvY29sIGJldHdlZW4gQ0ROcyBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGUgQ0ROSQogICB3b3JrLCB0aGlzIHF1ZXN0aW9uIGlzIGxlZnQgZm9yIGZ1 cnRoZXIgc3R1ZHkuCgogICBUaGUgREVDQURFIGluLW5ldHdvcmsgc3RvcmFnZSBhcmNoaXRlY3R1 cmUgYW5kIG1lY2hhbmlzbXMgbWF5CiAgIHBvdGVudGlhbGx5IGFsc28gYmUgdXNlZCB3aXRoaW4g YSBnaXZlbiBDRE4gZm9yIHRoZSBkaXN0cmlidXRpb24gb2YKICAgdGhlIGNvbnRlbnQgb2JqZWN0 cyB0aGVtc2VsdmVzIGFtb25nIHN1cnJvZ2F0ZXMgb2YgdGhhdCBDRE4uICBTaW5jZQogICB0aGUg Q0ROSSB3b3JrIGRvZXMgbm90IGNvbmNlcm4gaXRzZWxmIHdpdGggb3BlcmF0aW9uIHdpdGhpbiBh IENETiwKCgoKTml2ZW4tSmVua2lucywgZXQgYWwuICAgRXhwaXJlcyBOb3ZlbWJlciAxLCAyMDEy ICAgICAgICAgICAgICAgW1BhZ2UgMzddCgwKSW50ZXJuZXQtRHJhZnQgICAgQ0ROIEludGVyY29u bmVjdGlvbiBQcm9ibGVtIFN0YXRlbWVudCAgICAgICBBcHJpbCAyMDEyCgoKICAgdGhpcyBxdWVz dGlvbiBpcyBsZWZ0IGZvciBmdXJ0aGVyIHN0dWR5LgoKICAgVGhlcmVmb3JlLCB0aGUgd29yayBv ZiBERUNBREUgbWF5IGJlIGNvbXBsZW1lbnRhcnkgdG8gYnV0IGRvZXMgbm90CiAgIG92ZXJsYXAg d2l0aCB0aGUgQ0ROSSB3b3JrIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LgoKQi40LjMuICBQ UFNQCgogICBBcyBzdGF0ZWQgaW4gdGhlIFBQU1AgV29ya2luZyBHcm91cCBjaGFydGVyIFtQUFNQ LUNoYXJ0ZXJdOgoKICAgIlRoZSBQZWVyLXRvLVBlZXIgU3RyZWFtaW5nIFByb3RvY29sIChQUFNQ KSB3b3JraW5nIGdyb3VwIGRldmVsb3BzCiAgIHR3byBzaWduYWxpbmcgYW5kIGNvbnRyb2wgcHJv dG9jb2xzIGZvciBhIHBlZXItdG8tcGVlciAoUDJQKQogICBzdHJlYW1pbmcgc3lzdGVtIGZvciB0 cmFuc21pdHRpbmcgbGl2ZSBhbmQgdGltZS1zaGlmdGVkIG1lZGlhIGNvbnRlbnQKICAgd2l0aCBu ZWFyIHJlYWwtdGltZSBkZWxpdmVyeSByZXF1aXJlbWVudHMuIiBhbmQgIlRoZSBQUFNQIHdvcmtp bmcKICAgZ3JvdXAgZGVzaWducyBhIHByb3RvY29sIGZvciBzaWduYWxpbmcgYW5kIGNvbnRyb2wg YmV0d2VlbiB0cmFja2VycwogICBhbmQgcGVlcnMgKHRoZSBQUFNQICJ0cmFja2VyIHByb3RvY29s IikgYW5kIGEgc2lnbmFsaW5nIGFuZCBjb250cm9sCiAgIHByb3RvY29sIGZvciBjb21tdW5pY2F0 aW9uIGFtb25nIHRoZSBwZWVycyAodGhlIFBQU1AgInBlZXIKICAgcHJvdG9jb2wiKS4gIFRoZSB0 d28gcHJvdG9jb2xzIGVuYWJsZSBwZWVycyB0byByZWNlaXZlIHN0cmVhbWluZyBkYXRhCiAgIHdp dGhpbiB0aGUgdGltZSBjb25zdHJhaW50cyByZXF1aXJlZCBieSBzcGVjaWZpYyBjb250ZW50IGl0 ZW1zLiIKCiAgIFRoZXJlZm9yZSBQUFNQIGlzIGNvbmNlcm5lZCB3aXRoIHRoZSBkaXN0cmlidXRp b24gb2YgdGhlIHN0cmVhbWVkCiAgIGNvbnRlbnQgaXRzZWxmIGFsb25nIHdpdGggdGhlIG5lY2Vz c2FyeSBzaWduYWxpbmcgYW5kIGNvbnRyb2wKICAgcmVxdWlyZWQgdG8gZGlzdHJpYnV0ZSB0aGUg Y29udGVudC4gIEFzIHN1Y2gsIGl0IGNvdWxkIHBvdGVudGlhbGx5IGJlCiAgIHVzZWQgZm9yIHRo ZSBhY3F1aXNpdGlvbiBvZiBzdHJlYW1lZCBjb250ZW50IGFjcm9zcyBpbnRlcmNvbm5lY3RlZAog ICBDRE5zLiAgQnV0IHNpbmNlIHRoZSBhY3F1aXNpdGlvbiBwcm90b2NvbCBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGUKICAgd29yayBwcm9wb3NlZCBmb3IgQ0ROSSwgd2UgbGVhdmUgdGhpcyBm b3IgZnVydGhlciBzdHVkeS4gIEFsc28sCiAgIGJlY2F1c2Ugb2YgaXRzIHN0cmVhbWluZyBuYXR1 cmUsIFBQU1AgaXMgbm90IHNlZW4gYXMgYXBwbGljYWJsZSB0bwogICB0aGUgZGlzdHJpYnV0aW9u IGFuZCBjb250cm9sIG9mIHRoZSBDRE5JIGNvbnRyb2wgcGxhbmUgYW5kIENETkkgZGF0YQogICBy ZXByZXNlbnRhdGlvbnMuCgogICBUaGVyZWZvcmUsIHRoZSB3b3JrIG9mIFBQU1AgbWF5IGJlIGNv bXBsZW1lbnRhcnkgdG8gYnV0IGRvZXMgbm90CiAgIG92ZXJsYXAgd2l0aCB0aGUgd29yayBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBmb3IgQ0ROSS4KCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAg IEJlbiBOaXZlbi1KZW5raW5zCiAgIFZlbG9jaXggKEFsY2F0ZWwtTHVjZW50KQogICAzMjYgQ2Ft YnJpZGdlIFNjaWVuY2UgUGFyawogICBNaWx0b24gUm9hZCwgQ2FtYnJpZGdlICBDQjQgMFdHCiAg IFVLCgogICBFbWFpbDogYmVuQHZlbG9jaXguY29tCgoKCgoKCgoKCk5pdmVuLUplbmtpbnMsIGV0 IGFsLiAgIEV4cGlyZXMgTm92ZW1iZXIgMSwgMjAxMiAgICAgICAgICAgICAgIFtQYWdlIDM4XQoM CkludGVybmV0LURyYWZ0ICAgIENETiBJbnRlcmNvbm5lY3Rpb24gUHJvYmxlbSBTdGF0ZW1lbnQg ICAgICAgQXByaWwgMjAxMgoKCiAgIEZyYW5jb2lzIExlIEZhdWNoZXVyCiAgIENpc2NvIFN5c3Rl bXMKICAgR3JlZW5zaWRlLCA0MDAgQXZlbnVlIGRlIFJvdW1hbmlsbGUKICAgU29waGlhIEFudGlw b2xpcyAgMDY0MTAKICAgRnJhbmNlCgogICBQaG9uZTogKzMzIDQgOTcgMjMgMjYgMTkKICAgRW1h aWw6IGZsZWZhdWNoQGNpc2NvLmNvbQoKCiAgIE5hYmlsIEJpdGFyCiAgIFZlcml6b24KICAgNDAg U3lsdmFuIFJvYWQKICAgV2FsdGhhbSwgTUEgIDAyMTQ1CiAgIFVTQQoKICAgRW1haWw6IG5hYmls LmJpdGFyQHZlcml6b24uY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpOaXZl bi1KZW5raW5zLCBldCBhbC4gICBFeHBpcmVzIE5vdmVtYmVyIDEsIDIwMTIgICAgICAgICAgICAg ICBbUGFnZSAzOV0KDAo= --_002_CBC4A8C0343C5benvelocixcom_-- From jakob@kirei.se Mon Apr 30 23:20:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DEA21F8741 for ; Mon, 30 Apr 2012 23:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=2.776, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehTZhCUcr-yx for ; Mon, 30 Apr 2012 23:20:37 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [91.206.174.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6486B21F86D7 for ; Mon, 30 Apr 2012 23:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=20IQ4a32d3TEc5gZjOtxDge0R+7mYI2ZHAkCazR+DhU=; b=1eHwebah3oWMrgJQ+uvSUODD7P4t06AmCTwtliDkR9CbSKiyxLAOJiDC4jHpO+o0+C2qXahPZReDT 9Kdf+Hl35RW78+bOvp1YDrm0BRa3auVNQMl3ynMgfdmmeBF9J/NmDr4g25G09EletdKex9iNxnWnmL 9K9+G1IyiU1m6wFY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 1 May 2012 08:05:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> Date: Tue, 1 May 2012 08:05:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Tue, 01 May 2012 02:28:52 -0700 Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, John Gilmore , iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 06:20:38 -0000 On 30 apr 2012, at 15:53, Martin Rex wrote: > When trying to deliver mail to @toad.com, the only secure > question to ask is whether the server is authorized to process > Email for @toad.com. For certificates issued from the traditional > PKIX world, that would require a "toad.com" DNSName SAN. That would require large hosting provider, e.g. Google Apps, to update = their SMTP TLS certificates each and every time they added or removed a = customer. In my book, that would not scale. I believe we should focus on = securing the transport, not building a TLS-based application = authorization system. jakob From marka@isc.org Mon Apr 30 17:15:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FC121F8748; Mon, 30 Apr 2012 17:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RiQMeuL+wH3; Mon, 30 Apr 2012 17:15:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC621F8734; Mon, 30 Apr 2012 17:15:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2AF345F9C33; Tue, 1 May 2012 00:14:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4c27:d59:8c27:a78b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3203F216C31; Tue, 1 May 2012 00:14:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C44672043D0C; Tue, 1 May 2012 10:14:40 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp> In-reply-to: Your message of "Mon, 30 Apr 2012 17:37:19 +0200." <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp> Date: Tue, 01 May 2012 10:14:39 +1000 Message-Id: <20120501001440.C44672043D0C@drugs.dv.isc.org> X-Mailman-Approved-At: Tue, 01 May 2012 02:29:03 -0700 Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:15:15 -0000 In message <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp>, Martin Rex writes: > Tony Finch wrote: > > > > Martin Rex wrote: > > > > > > > The security properties of any MX, CNAME, A or AAAA lookups during > > > > > connection establishment with that server are irrelevant for DANE > > > > > (and invisible to PKIX). > > > > > > > > RFC 6125 allows for secure name indirections. > > > > > > Which _secure_ name indirections are you thinking of? > > > > RFC 6125 says: > > > > The client might need to extract the source domain and application > > service type from the input(s) it has received. The extracted data > > MUST include only information that can be securely parsed out of the > > inputs (e.g., parsing the fully qualified DNS domain name out of the > > "host" component (or its equivalent) of a URI or deriving the > > application service type from the scheme of a URI) or information > > that is derived in a manner not subject to subversion by network > > attackers (e.g., pulling the data from a delegated domain that is > > explicitly established via client or system configuration, resolving > > the data via [DNSSEC], or obtaining the data from a third-party > > domain mapping service in which a human user has explicitly placed > > trust and with which the client communicates over a connection or > > association that provides both mutual authentication and integrity > > checking). > > > One should not confuse DNSSEC protection of DNS records (which provide > only data integrity and data origin authentication) with the concept > of a secure directory service providing name translations. When you add a CNAME you are asserting that the canonical name for the owner of the CNAME is the target of the CNAME. CNAME does NOT mean "hosted at" which is how HTTP{S} treat CNAME. CNAME *really* should change the expect name of any CERT, unfortunately nobody asked for a "hosted at" record for HTTP{S} and the closest fit in the existing records was CNAME. > Sprinkling security equally across all DNS records also seems like > a bad idea. I think it would be much more sensible to limit the > security-relevant DNS records (and indirections allowed for them) > to _very_ few records, and preferably all _new_ records, because > DNSSEC-less zones will be with us for many years to come, and > > I believe it would be a really bad idea to change the sensitivity > of existing DNS records underneath DNS registrar's feet. All the records registrars handle require and always have required protection from unauthorised updates. DNSSEC has not changed that. If your registrar is not performing that service properly pick a different registrar. The world is assuming that all registrars are providing data protection for the records being added. > For TLSA records it would be OK if DNS software (and DNS servers) > performed some plausibility checks, e.g. warn prominently if TLSA > records are present in a Zone but no DNSSEC is active for the zone. > Something which does not make sense for any of the traditional > DNS records. The TLSA record is just ignored if it is insecure. Note it can be signed yet still be insecure as far as the client is concerned. > Looking at the example from a previous post: > > > > > ;; QUESTION SECTION: > > ;universalmusic.com. IN MX > > > > ;; ANSWER SECTION: > > universalmusic.com. 3600 IN MX 10 mail.global.frontbridge.com. > > For regular DANE, it is sufficient if (but also necessary that) > the DNS-Domain "universalmusic.com" has DNSSEC active in order to > securely provide a TLSA record for > > _25._tcp.universalmusic.com. > > and simultaneously independent from the DNSSEC status of frontbridge.com. And for STARTTLS you only need universalmusic.com MX record to be secure and that mail.global.frontbridge.com have a CERT issued in that name. If you want to prevent downgrade attacks then you need either a "Secure MX" record or _25._tcp.mail.global.frontbridge.com to be signed with the appropriate TLSA record. > If you want to allow DNS-based indirection, and in particular on existing > DNS records, then you would have to enforce that *ALL* domains that > are traversed during all possible DNS indirections have DNSSEC active > and that all lookups are verified, and require that the SMTP-software > aborts if DNSSEC verification of one of the indirections fails or > is not possible, and it may be difficult to impossible for the DNS-Software > (maintenance tools and DNS-Server) to help you maintaining consistency > across all those possible indirections, and close to impossible for the > DNS admins to understand the implications. If a site cares about the security of the email being sent to it then it signs its zones and adds relevent TLSA records to prevent downgrade attacks or if email is being handled by a third party that the relevent zones operated by the third party are signed. Moving to "Secure MX" records would provide the signaling and indirection with just one record. You just don't have implict "Secure MX" records, just implict MX records. Mark > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rbarnes@bbn.com Mon Apr 30 14:47:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018EB21E80C3; Mon, 30 Apr 2012 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.444 X-Spam-Level: X-Spam-Status: No, score=-106.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlulIcSspzH8; Mon, 30 Apr 2012 14:47:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2C321E80C0; Mon, 30 Apr 2012 14:47:41 -0700 (PDT) Received: from [128.89.253.186] (port=60199) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SOyRA-000Fm9-JB; Mon, 30 Apr 2012 17:47:16 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> Date: Mon, 30 Apr 2012 17:48:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Tue, 01 May 2012 02:29:17 -0700 Cc: "apps-discuss@ietf.org Discuss" , Paul Hoffman , XMPP Working Group , IETF DANE WG list Subject: Re: [apps-discuss] [dane] Documenting DANE for XMPP (WAS: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:47:43 -0000 +1 to documenting the use of DANE with XMPP +1 also to incorporating this discussion in a broader DNA / "server = federation" document On Apr 30, 2012, at 2:52 PM, Matt Miller wrote: >=20 > On Apr 30, 2012, at 12:37, Paul Hoffman wrote: >=20 >> On Apr 30, 2012, at 10:46 AM, Matt Miller wrote: >>=20 >>> I think there might still need to be some explicitness on what name = to expect to match on regardless of where the certificate is found, = especially with multi-domain XMPP servers (e.g. a server = "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and = "denmark.shakespeare.lit"). >>=20 >> Yes. >>=20 >>> Maybe that doesn't need to be its own document. =20 >>=20 >> Are you serious!?!?! After the amount of confusing and disagreement = we have seen in the past few months on this topic, a stand-alone = document that can be referred to easily is exactly what we need. >>=20 >=20 > The preference of having a single document came from the XMPP WG. I = personally am not sure it's the best idea, but I also don't have = anything written up yet. I'm more than willing to fight hard to = separate, but I also need to see what it looks like with the rest of = XMPP federation stuff. >=20 >>> I am working on a proposal for improving XMPP federation, and a = section in that document might be sufficient...Probably (-: >>=20 >> I'm skeptical, to say the least. >=20 > I did say "might" and "probably" (-: >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From fanf2@hermes.cam.ac.uk Tue May 1 04:22:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8333221F8776; Tue, 1 May 2012 04:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvrY87eHyvWW; Tue, 1 May 2012 04:22:25 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id BF0E021F8775; Tue, 1 May 2012 04:22:25 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56571) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SPB9x-0002mB-Ev (Exim 4.72) (return-path ); Tue, 01 May 2012 12:22:21 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPB9x-00029z-Jf (Exim 4.67) (return-path ); Tue, 01 May 2012 12:22:21 +0100 Date: Tue, 1 May 2012 12:22:21 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ned Freed In-Reply-To: <01OEXVCY097U0006TF@mauve.mrochek.com> Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 11:22:26 -0000 Ned Freed wrote: > > But even this may not be acceptable for all I know. It may turn out that using > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong, > but it seems to me that this is what all this additional discussion is about. I don't think it's as simple as that because RFC 6125 says certificates should match the SRV owner name not the target name. See also Dave Cridland's comments about XMPP. Tony. -- f.anthony.n.finch http://dotat.at/ Dover, Wight: Variable 3 or 4. Moderate becoming slight. Showers, fog patches. Moderate or good, occasionally very poor. From msk@cloudmark.com Tue May 1 06:44:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CE121E8213 for ; Tue, 1 May 2012 06:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d7uepqJb2Kv for ; Tue, 1 May 2012 06:44:07 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id EA2D021E81D2 for ; Tue, 1 May 2012 06:44:07 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 4dk11j0010ZaKgw01dk1Tj; Tue, 01 May 2012 06:44:07 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=WuKpwKjv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=Pip2rxCYUeAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=iaFxQ7KoavX-IZ4UVGMA:9 a=CjuIK1q_8ugA:10 a=_RhRFcbxBZMA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 1 May 2012 06:43:37 -0700 From: "Murray S. Kucherawy" To: Julian Reschke Thread-Topic: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec Thread-Index: Ac0l10W9SlaETdSSRZWdVKRKL9SkswBVntWAAAXqgAAAGcuogAADHYPA Date: Tue, 1 May 2012 13:43:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> In-Reply-To: <4F9F9A8D.8080004@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335879847; bh=2g33PJv/rvs6t5CvpAvGBpByGHNjSlkX4yGdY9hX4bE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KFQJORl/i8yw3HgwgUVz1FKNGHy92sDnbqKuSOlncrmtHua+4NnmEgMlyYSMHcUys 2aiQHi+SBBUMKX7KavvkOooHUbYBTlTCrD4bpAIWBOtNCrvXnepjy/1jqNhOLXgUIp n72tg4AsxXFIzpYgtfCpADQYjmdTwy87TBh7LHFU= Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [websec] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 13:44:08 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, May 01, 2012 1:11 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-tran= sport-sec@tools.ietf.org > Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transpor= t-sec >=20 > > Why not just say "delta-seconds is defined in Section 3.3.2 of > > [RFC2616]" and leave out the restatement of the ABNF? Then it's truly > > only specified in one place. >=20 > That's *exactly* what the prose ABNF rule is doing; except that it > makes the in-spec ABNF complete. Yes, and I'm saying I think that's a risky thing to do. Granted, in this p= articular case it's pretty hard to copy and get wrong, but in general it's = safer to point to an authoritative definition of something rather than copy= it just so it's all local. -MSK From sm@resistor.net Tue May 1 10:04:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CBD21E8345 for ; Tue, 1 May 2012 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXSSdCGHWpi1 for ; Tue, 1 May 2012 10:04:15 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3DE21E8188 for ; Tue, 1 May 2012 10:04:14 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q41H3x16009194; Tue, 1 May 2012 10:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335891846; i=@resistor.net; bh=owOgg2wry+WGPBBCZu88RT4aPTX1N/ro4NPL/s1eAjg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jDRYcC2nJEcvtja0OvEvR2+q8YwU6N0Qvdue8KzJPOkJb4M8EOmTolGYr0yrnZOLs plhwRi72rcw84kPJTjlXIpuBkV/rqB2sG3uQ1dDtPz/hBXDMQ/r2Ac5Q11A/o87vvN j5xDLvNVV+F0NZ5eJ9zI/OJ6j+VGmVNw16HmFxtk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335891846; i=@resistor.net; bh=owOgg2wry+WGPBBCZu88RT4aPTX1N/ro4NPL/s1eAjg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1K4uS5MsFHW584PlirL9gMQu1RVcpfQp2ZzUEbqp/nAUK0ZIu6gu5lQpufBKV6IaO 9qRxP6dB9c6YQd7otZnPHEp+lxM6lyGnjjd6H9emBIKgohcJFW0hs5mVHnKOXKP8BL lf9RDTbQ1w6SGFdedXfheZssyk4ha3Fupqlh5FHY= Message-Id: <6.2.5.6.2.20120501093657.0a6772b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 May 2012 10:03:06 -0700 To: Stephen Farrell From: SM In-Reply-To: <4F9FA95F.1080709@cs.tcd.ie> References: <4F9FA90B.9090607@cs.tcd.ie> <4F9FA95F.1080709@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: [dane] DANE IETF LC state of play X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:04:18 -0000 Hi Stephen, At 02:14 01-05-2012, Stephen Farrell wrote: >Notes: a) they might be just fine, e.g. if just one person comments >and nobody else thought it important, then doing nothing is probably >right. these just weren't clear from the archive so I wanna check; The above could be read as if nobody "+1" a comment, the course of action should probably be "do nothing". The RFC has not been published and yet there are different interpretations of how DANE works from an application perspective. There has been more traffic on apps-discuss@ than during the IETF Last Call. I hope that these discussions have been taken into account. I consider the comments at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05439.html as unaddressed. BTW, I am ok with the follow-up on this being on ietf@ only. Regards, -sm From paul.hoffman@vpnc.org Tue May 1 10:24:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B234421E828C; Tue, 1 May 2012 10:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLTfCdT3fRpt; Tue, 1 May 2012 10:24:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC7C21E81CF; Tue, 1 May 2012 10:24:15 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41HOCES010811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2012 10:24:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F9F4DEE.1090309@stpeter.im> Date: Tue, 1 May 2012 10:24:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:24:16 -0000 On Apr 30, 2012, at 7:43 PM, Peter Saint-Andre wrote: >> 1b. The term "client-chosen port" makes it sound as if the client=20 >> can choose any port it pleases when connecting to the TLS server.=20 >> Yet typically the port is derived from a URI, "hardcoded" into the >> application protocol (sometimes as a fallback), or discovered via=20 >> the DNS (again, think SRV). We needn't reflect those alternatives=20 >> in the text, but at the least "appropriate" is better than=20 >> "client-chosen". >=20 > The change from "client-chosen port" to "client-define port" is > mystifying to me. Even assuming that "client-defined" was meant, it's > not clear to me what a client-defined port is, and I see no effective > difference between the old text and the new text. The intended difference was to say that the client gets to define which = port it is using based on pre-configured settings ("POP is always done = over TLS on port 995") or the way it interprets the URL or on something = else we cannot guess. I didn't feel that your proposal of "appropriate" = indicated to whom it needed to be appropriate, namely the client. Better suggestions are welcome. >> 4. In Section 2.2, the term "whitespace" is underspecified. Does=20 >> that include, say, any Unicode space separator (Unicode General=20 >> Category Zs) or also line separators (Unicode General Category Zl)=20 >> or only certain code points in the ASCII range? Further, is the=20 >> whitespace significant in the examples from Section 2.3? >=20 > I see no change in -20 to clarify this matter. We can add ", as described in " in the next = draft, or remove the whole sentence since it is already covered by an = Internet Standard. I think the former is better, but can do the latter = if you think that is clearer. >> 2. Section 1.1, uses the term "subdomain" in the sentence "This=20 >> prevents an untrustworthy signer from compromising anyone's keys=20 >> except those in their own subdomains." The term "subdomain" is not >> always well understood. I suggest explicitly citing Section 3.1 >> of RFC 1034 here. >=20 > Unchanged, but it's probably OK as-is. There are many DNS-related terms that are defined in 1034/1035; I don't = think calling each out will help the reader. > In a follow-up email message, I also noted: >=20 > ### >=20 > One more issue is nagging at me: there is no definition or citation > for "domain name" in Section 3. In particular, there is no indication > of whether internationalized domain names are allowed (and, if so, in > what format). I think it would good to make this clear by saying that > a domain name can be either a "traditional domain name" (RFC 1034) or > an "internationalized domain name" (RFC 5890); for the latter I think > it would be best to say that the IDN's internationalized labels are > represented only as A-labels. IMHO a short paragraph on this matter > would be appropriate in Section 3 or in a new section entitled > "Internationalization Considerations". >=20 > ### >=20 > I still think that this document needs to say something about IDNs. Please give specific wording for a specific location. I do not see any = place appropriate in this document to introduce IDNs and explain = A-labels in order to say "they're fine here". If you propose wording and = a location, I bet they will be fine. --Paul Hoffman From paul.hoffman@vpnc.org Tue May 1 10:27:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0329221E82A5 for ; Tue, 1 May 2012 10:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX4UOdwQ1ar1 for ; Tue, 1 May 2012 10:27:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFC521E801F for ; Tue, 1 May 2012 10:27:46 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41HRjuB015689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2012 10:27:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <6.2.5.6.2.20120501093657.0a6772b8@resistor.net> Date: Tue, 1 May 2012 10:27:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89D5EDFB-6B1C-4615-B43B-F480A55B5E64@vpnc.org> References: <4F9FA90B.9090607@cs.tcd.ie> <4F9FA95F.1080709@cs.tcd.ie> <6.2.5.6.2.20120501093657.0a6772b8@resistor.net> To: SM X-Mailer: Apple Mail (2.1257) Cc: Apps Discuss Subject: Re: [apps-discuss] [dane] DANE IETF LC state of play X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:27:47 -0000 On May 1, 2012, at 10:03 AM, SM wrote: > The RFC has not been published and yet there are different = interpretations of how DANE works from an application perspective. Those interpretations were by people who didn't believe the text that MX = and SRV were purposely not addressed. > There has been more traffic on apps-discuss@ than during the IETF = Last Call. I hope that these discussions have been taken into account. I believe I did: I repeated the "we're not addressing this" text so it = appears twice. > I consider the comments at = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05439.html = as unaddressed. They are not addressed because they have nothing to do with the protocol = in the document. Please let me know if you still disagree, and send = proposed text to the DANE WG. --Paul Hoffman From fanf2@hermes.cam.ac.uk Tue May 1 11:02:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C3021E840E; Tue, 1 May 2012 11:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubGTYAFe-Yzc; Tue, 1 May 2012 11:02:01 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5896D21E83FC; Tue, 1 May 2012 11:02:01 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40533) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SPHOi-0002Ue-Wl (Exim 4.72) (return-path ); Tue, 01 May 2012 19:02:00 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPHOi-0001PF-4Y (Exim 4.67) (return-path ); Tue, 01 May 2012 19:02:00 +0100 Date: Tue, 1 May 2012 19:02:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4F9F4DEE.1090309@stpeter.im> Message-ID: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:02:02 -0000 Peter Saint-Andre wrote: > > The change from "client-chosen port" to "client-define port" is > mystifying to me. Even assuming that "client-defined" was meant, it's > not clear to me what a client-defined port is, and I see no effective > difference between the old text and the new text. I think the mistake is to talk about the client here. The client begins a connection to the service's port at that IP address. Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Cyclonic 5 in far north, otherwise southwesterly 5 to 7. Moderate or rough. Occasional rain. Moderate or good, occasionally poor in north. From alexey.melnikov@isode.com Tue May 1 11:26:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A817621E8036 for ; Tue, 1 May 2012 11:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1o8ZIB7qcMdd for ; Tue, 1 May 2012 11:26:22 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD43221E8034 for ; Tue, 1 May 2012 11:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335896780; d=isode.com; s=selector; i=@isode.com; bh=viI3GEWuL4RaJmpi4XDQf0E3W3nzcGnCM7dPXvD8Peg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kra1meCPzpB6b/2GoioVSxH99iG8FLoSUgtHPIZlsQNxVqXblGkI1oo2fZj/ejRxcnxyva v7eBIFxFiJtjn6XAqaUUdf88oZgpz/SPqL47yL+kZNJ2FhR5cZKTUWIUN88fg0zfmahkRD mJ8P6obHK0tLx0cZy/jiRYcjZVpNPrg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 1 May 2012 19:26:19 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FA02AEA.1080407@isode.com> Date: Tue, 01 May 2012 19:26:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "apps-discuss@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:26:22 -0000 Dear WG participants, I would like to initiate WG Last Call on draft-ietf-appsawg-http-forwarded-02.txt ("Forwarded HTTP Extension"). Please send your reviews, as well as expressions of support regarding document readiness for IESG (or not) either to the mailing list, or directly to WG chairs (Murray Kucherawy and myself). Comments like "I've read the document and it is Ok to publish" or "I've read the document and it has the following issues" are useful and would be gratefully accepted by chairs. The WGLC will end on Friday, May 18th. Thank you, Alexey as an APPSAWG co-chair. From sm@resistor.net Tue May 1 11:37:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17A821E8034 for ; Tue, 1 May 2012 11:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXGcwNWneYKk for ; Tue, 1 May 2012 11:37:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BC021E801F for ; Tue, 1 May 2012 11:37:50 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q41Ibi2t025163; Tue, 1 May 2012 11:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335897470; i=@resistor.net; bh=N2dsOlSISiFagH4fR3SEOCsqeT5YmVsJzBNPS4+PYeE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VDopIpyI3h02JqYEcEciU879aLbJKCnGf1EtavvIN2ybexqLC4ybqXmxXtab+c6vX WoT7/dqs19k5aHFvgzSa+KTxuYvYGMSZCvyYJQwvGQRvzDe206HfkW1mK55femX8qP PjuH39e1h1pkiJSGm0V2afNsvX41uO+c1tr5kGVk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335897470; i=@resistor.net; bh=N2dsOlSISiFagH4fR3SEOCsqeT5YmVsJzBNPS4+PYeE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BJLADUFTVKoENVAVESbVEYxWTY6ja+7MPxzG7C+zu32UVe3NyH1Q0TDhJwLTlWf+v t40qAjuicX54Xv6I48piCR/HxCkkKlrsAd145KkrOJVQo2T/81YBqd2vfnuYJj9/62 QjMO3fbV6y6PobJWDMehzlfY9eycCvfZlHHDXBdw= Message-Id: <6.2.5.6.2.20120501105907.0a67cdb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 May 2012 11:23:04 -0700 To: Paul Hoffman From: SM In-Reply-To: <89D5EDFB-6B1C-4615-B43B-F480A55B5E64@vpnc.org> References: <4F9FA90B.9090607@cs.tcd.ie> <4F9FA95F.1080709@cs.tcd.ie> <6.2.5.6.2.20120501093657.0a6772b8@resistor.net> <89D5EDFB-6B1C-4615-B43B-F480A55B5E64@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Discuss Subject: Re: [apps-discuss] [dane] DANE IETF LC state of play X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:37:52 -0000 Hi Paul, At 10:27 01-05-2012, Paul Hoffman wrote: >Those interpretations were by people who didn't believe the text >that MX and SRV were purposely not addressed. Ok. >I believe I did: I repeated the "we're not addressing this" text so >it appears twice. Sorry, I must have missed that. >They are not addressed because they have nothing to do with the >protocol in the document. Please let me know if you still disagree, >and send proposed text to the DANE WG. I'll post the text here as part of IETF Last Call comments if it is ok with you/the WG. I am not including the arguments to avoid rehashing what was said before. Please ask if the arguments are needed. In section 1.3: Proposed text: "Note that this document does not cover how to associate certificates with domain names for application protocols that depend on MX, SRV, NAPTR, and similar DNS resource records; it is expected that later updates to this document might cover methods for making those associations." I suggest removing the following text in Section 3: 'To request a TLSA resource record for an SMTP server running the STARTTLS protocol on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is used.' in Section 8: A DNS administrator who goes rogue and changes both the A, AAAA, CNAME and/or TLSA records for a domain name can cause the user to go to an unauthorized server that will appear authorized, unless the client performs PKIX certification path validation and rejects the certificate. If the authentication mechanism for adding or changing TLSA data in a zone is weaker than the authentication mechanism for changing the A AAAA, and/or CNAME records, a man-in-the-middle who can redirect traffic to their site may be able to impersonate the attacked host in TLS if they can use the weaker authentication mechanism. Regards, -sm From stpeter@stpeter.im Tue May 1 11:56:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C2621E82BA; Tue, 1 May 2012 11:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egg0u7nPxnrU; Tue, 1 May 2012 11:56:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB221E822A; Tue, 1 May 2012 11:56:20 -0700 (PDT) Received: from [171.70.217.95] (unknown [171.70.217.95]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CE68840058; Tue, 1 May 2012 13:11:14 -0600 (MDT) Message-ID: <4FA031D1.50006@stpeter.im> Date: Tue, 01 May 2012 11:56:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tony Finch References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:56:21 -0000 On 5/1/12 11:02 AM, Tony Finch wrote: > Peter Saint-Andre wrote: >> >> The change from "client-chosen port" to "client-define port" is >> mystifying to me. Even assuming that "client-defined" was meant, it's >> not clear to me what a client-defined port is, and I see no effective >> difference between the old text and the new text. > > I think the mistake is to talk about the client here. The client begins a > connection to the service's port at that IP address. Usually, yes. Sometimes the client is configured to override the default port for the given service, as Paul noted. Could we just say "It then begins a connection to a particular port at that address"? Perhaps the method for determining the port isn't really relevant in this spec. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue May 1 12:02:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5AA21F8A21; Tue, 1 May 2012 12:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfThgG7rmIrG; Tue, 1 May 2012 12:02:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1059D21F89A5; Tue, 1 May 2012 12:02:56 -0700 (PDT) Received: from [171.70.217.95] (unknown [171.70.217.95]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4932440058; Tue, 1 May 2012 13:17:51 -0600 (MDT) Message-ID: <4FA0335E.7090306@stpeter.im> Date: Tue, 01 May 2012 12:02:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:02:57 -0000 On 5/1/12 10:24 AM, Paul Hoffman wrote: > On Apr 30, 2012, at 7:43 PM, Peter Saint-Andre wrote: > >>> 1b. The term "client-chosen port" makes it sound as if the client >>> can choose any port it pleases when connecting to the TLS >>> server. Yet typically the port is derived from a URI, "hardcoded" >>> into the application protocol (sometimes as a fallback), or >>> discovered via the DNS (again, think SRV). We needn't reflect >>> those alternatives in the text, but at the least "appropriate" is >>> better than "client-chosen". >> >> The change from "client-chosen port" to "client-define port" is >> mystifying to me. Even assuming that "client-defined" was meant, >> it's not clear to me what a client-defined port is, and I see no >> effective difference between the old text and the new text. > > The intended difference was to say that the client gets to define > which port it is using based on pre-configured settings ("POP is > always done over TLS on port 995") or the way it interprets the URL > or on something else we cannot guess. I didn't feel that your > proposal of "appropriate" indicated to whom it needed to be > appropriate, namely the client. > > Better suggestions are welcome. See other message. >>> 4. In Section 2.2, the term "whitespace" is underspecified. Does >>> that include, say, any Unicode space separator (Unicode General >>> Category Zs) or also line separators (Unicode General Category >>> Zl) or only certain code points in the ASCII range? Further, is >>> the whitespace significant in the examples from Section 2.3? >> >> I see no change in -20 to clarify this matter. > > We can add ", as described in " in the next > draft, or remove the whole sentence since it is already covered by an > Internet Standard. I think the former is better, but can do the > latter if you think that is clearer. Hmm. The text I'm referring to is: o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters. How does RFC 1035 apply to the representation of the certificate association data field? >>> 2. Section 1.1, uses the term "subdomain" in the sentence "This >>> prevents an untrustworthy signer from compromising anyone's keys >>> except those in their own subdomains." The term "subdomain" is >>> not always well understood. I suggest explicitly citing Section >>> 3.1 of RFC 1034 here. >> >> Unchanged, but it's probably OK as-is. > > There are many DNS-related terms that are defined in 1034/1035; I > don't think calling each out will help the reader. You're right. >> In a follow-up email message, I also noted: >> >> ### >> >> One more issue is nagging at me: there is no definition or >> citation for "domain name" in Section 3. In particular, there is no >> indication of whether internationalized domain names are allowed >> (and, if so, in what format). I think it would good to make this >> clear by saying that a domain name can be either a "traditional >> domain name" (RFC 1034) or an "internationalized domain name" (RFC >> 5890); for the latter I think it would be best to say that the >> IDN's internationalized labels are represented only as A-labels. >> IMHO a short paragraph on this matter would be appropriate in >> Section 3 or in a new section entitled "Internationalization >> Considerations". >> >> ### >> >> I still think that this document needs to say something about >> IDNs. > > Please give specific wording for a specific location. I do not see > any place appropriate in this document to introduce IDNs and explain > A-labels in order to say "they're fine here". If you propose wording > and a location, I bet they will be fine. I'm tied up today, but I will try to formulate some text as soon as possible. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Tue May 1 12:18:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8958A21E8425; Tue, 1 May 2012 12:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54LCG57jSCvd; Tue, 1 May 2012 12:18:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F408621E8370; Tue, 1 May 2012 12:18:48 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41JIIAw086234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2012 12:18:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA031D1.50006@stpeter.im> Date: Tue, 1 May 2012 12:18:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:18:49 -0000 On May 1, 2012, at 11:56 AM, Peter Saint-Andre wrote: > On 5/1/12 11:02 AM, Tony Finch wrote: >> Peter Saint-Andre wrote: >>>=20 >>> The change from "client-chosen port" to "client-define port" is >>> mystifying to me. Even assuming that "client-defined" was meant, = it's >>> not clear to me what a client-defined port is, and I see no = effective >>> difference between the old text and the new text. >>=20 >> I think the mistake is to talk about the client here. The client = begins a >> connection to the service's port at that IP address. >=20 > Usually, yes. Sometimes the client is configured to override the = default > port for the given service, as Paul noted. >=20 > Could we just say "It then begins a connection to a particular port at > that address"? Perhaps the method for determining the port isn't = really > relevant in this spec. Works for me. What do others think? Current: It then begins a connection to a client-defined port at that address, = and sends an initial message there. Proposed: It then begins a connection to a particular port at that address, and = sends an initial message there. --Paul Hoffman From paul.hoffman@vpnc.org Tue May 1 12:20:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2B21E843F; Tue, 1 May 2012 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnGlxbjcaXEq; Tue, 1 May 2012 12:20:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6C721E8370; Tue, 1 May 2012 12:20:50 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q41JKkdM086294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2012 12:20:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA0335E.7090306@stpeter.im> Date: Tue, 1 May 2012 12:20:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5C578F9E-D666-4596-8A37-5C546ECCD3D0@vpnc.org> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:20:51 -0000 On May 1, 2012, at 12:02 PM, Peter Saint-Andre wrote: >>>> 4. In Section 2.2, the term "whitespace" is underspecified. Does >>>> that include, say, any Unicode space separator (Unicode General >>>> Category Zs) or also line separators (Unicode General Category >>>> Zl) or only certain code points in the ASCII range? Further, is >>>> the whitespace significant in the examples from Section 2.3? >>> >>> I see no change in -20 to clarify this matter. >> >> We can add ", as described in " in the next >> draft, or remove the whole sentence since it is already covered by an >> Internet Standard. I think the former is better, but can do the >> latter if you think that is clearer. > > Hmm. The text I'm referring to is: > > o The certificate association data field MUST be represented as a > string of hexadecimal characters. Whitespace is allowed within > the string of hexadecimal characters. > > How does RFC 1035 apply to the representation of the certificate > association data field? The representation is happening in a DNS zone file. >>> In a follow-up email message, I also noted: >>> >>> ### >>> >>> One more issue is nagging at me: there is no definition or >>> citation for "domain name" in Section 3. In particular, there is no >>> indication of whether internationalized domain names are allowed >>> (and, if so, in what format). I think it would good to make this >>> clear by saying that a domain name can be either a "traditional >>> domain name" (RFC 1034) or an "internationalized domain name" (RFC >>> 5890); for the latter I think it would be best to say that the >>> IDN's internationalized labels are represented only as A-labels. >>> IMHO a short paragraph on this matter would be appropriate in >>> Section 3 or in a new section entitled "Internationalization >>> Considerations". >>> >>> ### >>> >>> I still think that this document needs to say something about >>> IDNs. >> >> Please give specific wording for a specific location. I do not see >> any place appropriate in this document to introduce IDNs and explain >> A-labels in order to say "they're fine here". If you propose wording >> and a location, I bet they will be fine. > > I'm tied up today, but I will try to formulate some text as soon as > possible. No rush: IDNs will be with us for a long time. :-) --Paul Hoffman From ned.freed@mrochek.com Tue May 1 12:26:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0F21E82CD; Tue, 1 May 2012 12:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RC9BDcWglvs; Tue, 1 May 2012 12:26:24 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D595F21E8053; Tue, 1 May 2012 12:26:24 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEYVHXWDIO000VVF@mauve.mrochek.com>; Tue, 1 May 2012 12:26:20 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 1 May 2012 12:26:16 -0700 (PDT) Message-id: <01OEYVHVJRM80006TF@mauve.mrochek.com> Date: Tue, 01 May 2012 12:12:52 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 May 2012 12:22:21 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> To: Tony Finch Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:26:25 -0000 > Ned Freed wrote: > > > > But even this may not be acceptable for all I know. It may turn out that using > > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong, > > but it seems to me that this is what all this additional discussion is about. > I don't think it's as simple as that because RFC 6125 says certificates > should match the SRV owner name not the target name. See also Dave > Cridland's comments about XMPP. That's actualy A Good Thing, because it means that there's nobody can argue that there's a simple addition to this document that will address the SRV case. Now all that remains is to open the door to using TLSA without having to update this specification. Ned From julian.reschke@gmx.de Tue May 1 12:54:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8783B21E8427 for ; Tue, 1 May 2012 12:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iT5wWDZmzjLH for ; Tue, 1 May 2012 12:54:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 894B821E8424 for ; Tue, 1 May 2012 12:54:09 -0700 (PDT) Received: (qmail invoked by alias); 01 May 2012 19:54:08 -0000 Received: from p5DD97D93.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.125.147] by mail.gmx.net (mp069) with SMTP; 01 May 2012 21:54:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+716Vsv3a7k1uUwrlZcQ5wjeBzXDKwFD9Nv+4/51 5stlNhLTlbjcbn Message-ID: <4FA03F4D.3050606@gmx.de> Date: Tue, 01 May 2012 21:53:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [websec] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:54:10 -0000 On 2012-05-01 15:43, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Tuesday, May 01, 2012 1:11 AM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-sec@tools.ietf.org >> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec >> >>> Why not just say "delta-seconds is defined in Section 3.3.2 of >>> [RFC2616]" and leave out the restatement of the ABNF? Then it's truly >>> only specified in one place. >> >> That's *exactly* what the prose ABNF rule is doing; except that it >> makes the in-spec ABNF complete. > > Yes, and I'm saying I think that's a risky thing to do. Granted, in this particular case it's pretty hard to copy and get wrong, but in general it's safer to point to an authoritative definition of something rather than copy it just so it's all local. Technically it *does* point to the authoritative definition. Best regards, Julian From Claudio.Allocchio@garr.it Tue May 1 14:16:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136AF21E8248; Tue, 1 May 2012 14:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONDJ4NRxtEl4; Tue, 1 May 2012 14:16:41 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id B268C21E8129; Tue, 1 May 2012 14:16:40 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it ([140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q41LGbcj048492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 23:16:38 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q41LGbcj048492 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Y8UPAmLUnAwwSEasX0Q1zSxk/LRSPUCFFl7rUCgK4gBgBhYK51y3UD++91Q0WVrNc N0d9zevZzcfQUAtiy9EXSwPLEfPy/tP3qga0H2AbFLdCXyqUYk7d8gmnLJYuTX41zsa FWEfFnNZGq021NEuNxMpSJb1f9fRf53a0Fkz58o= Date: Tue, 1 May 2012 23:16:37 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Arnt Gulbrandsen In-Reply-To: <4FA04B17.9050902@gulbrandsen.priv.no> Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 21:16:42 -0000 On Tue, 1 May 2012, Arnt Gulbrandsen wrote: > On 05/01/2012 11:41 AM, Claudio Allocchio wrote: >> 2.3 Subject >> >> adding or non adding a "DOWNGRADED" or equivalent to the subject is a >> major decision which also impacts on the way the security failure which >> are introduced by this specification are perceived by the user. This >> issue shall be fixed and a decision taken ASAP, in order to publish this. > > Yes. > >> 5. Security Considerations >> >> this section is way too short and simplified, compared to the issues >> that this specification introduces against secure e-mail mechanisms. > > As far as I can tell it introduces no issues at all. > > Think about it: How would a program verify a signature when it cannot > parse the signature's owner's address? Now downgrade the signature's > owner's address, using any algorithm you can think of. What new issue > has been introduced? as I already clarified in other discussions on these lists, I'm not talking about the signatures and other features. I'm talking about including a Security consideration section which describes clearly which features can be broken, and just warns about this. I also suggested as example the security considerations section of draft-ietf-eai-popimap-downgrade-05. See my discussions with Ned and others. > >> This section should give an exaustive list of caveats, and possible >> actions in various cases, in order to make clear that this specification >> breaks explicilty most of the existing security anchors where users >> should rely nowadays. > > Duck that. You're just pointing out something that's easily pointed out. > AFAICT it's not an issue either I or any downgrade implementer can do > anything about, so why does it deserve any text? warning implementers that these problems exists, IMHO, is never useless. >> given the quite invasive action on messages presentation that such a >> specification describes, such a short and "optimistic" abstract is, >> IMHO, misleading. At least insert a sentence to describe the scenario, >> and what this specification is trying to accomplish, what problems it >> tries to solve, and what issues are left open and voluntarily not solved >> here. >> >> 1 Overview: >> >> I disagree on the way the overview present "phylosophically" the problem >> to the reader. This is a technical specification intended for Standards >> Track, not an informational document. Thus, it should not focus on the >> way implementerss spend their time, os users' behaviours. It should >> state the problem and the proposed solutions: (dot)! >> >> Here is my suggested version of this paragraph: >> >> --- >> >> 1. Overview >> >> It may happen that a conventional IMAP or POP client opens a mailbox >> containing internationalized messages, or even attempt to read >> internationalized messages, for instance when a user has both >> internationalized and conventional MUAs. >> >> When this mismatched sitation happens, various strategies are possible: >> >> a) the server can hide the existence of such messages entirely, but >> doing that can be both tricky to implement and gives a false mailbox >> status to the user; >> >> b) the server attempts to present at least some information about these >> messages to the user. It shall be clear that what the user is being >> presented is not the original message, and information is dropped; >> >> c) the server does nothing, possibly creating problems to the client, and >> providing a bad user's experience. >> >> This document specify a way to implement strategy b), which enables the >> best compromise between a) and c), and promotes a simple to implement >> solution which conveys a better-than-nothing information service to the >> user. Accuracy of information and Security featues of the message will, >> however, not be preserved, and users should rely on an internationalised >> client as much as possible. >> >> The server is assumed to be internationalized internally. When it >> needs to present an internationalized message to a conventional >> client, it synthesizes a conventional message containing most of the >> information and presents that (the "synthetic message"). > > You've made it about four times as long and hardly four times as good. being long is a problem in a specification? >> 2.1 Email addresses >> >> At lease one sentence clearly stating that this will make impossible to >> reply to such a synthetic message should be present here. Too obvious? >> no... never suppouse that. > > It's not obvious, it's wrong ;) Nothing is made impossible, it was > impossible to start with. This does not change the need to state it. >> 1 Overwiew >> >> "It may happen that a conventional IMAP or POP client (MUA) opens..." >> ^ add the definition > > Do you mind if I define it as "IMAP or POP client"? That is, after all, > the operative definition ;) it's a nit... it's up to editors :-) >> 7. IANA Considerations >> >> ADD the name of the correct registry! > > I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name. > > Arnt > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From ned.freed@mrochek.com Tue May 1 19:57:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B4D21E80C9; Tue, 1 May 2012 19:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW4inFSm0ybI; Tue, 1 May 2012 19:57:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8221E809B; Tue, 1 May 2012 19:57:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEZB9QI02O000SA3@mauve.mrochek.com>; Tue, 1 May 2012 19:57:51 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Tue, 1 May 2012 19:57:47 -0700 (PDT) Message-id: <01OEZB9OC9VW0006TF@mauve.mrochek.com> Date: Tue, 01 May 2012 19:55:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 May 2012 09:46:52 +0100" <4F9FA2FC.7050402@cs.tcd.ie> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> <01OEY4K69WQE0006TF@mauve.mrochek.com> <4F9FA2FC.7050402@cs.tcd.ie> To: Stephen Farrell Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 02:57:57 -0000 > Hi Ned, > On 05/01/2012 07:30 AM, Ned Freed wrote: > >> On 4/30/12 6:52 PM, Ned Freed wrote: > >>> > >>>>> Again, I'm not taking any position on the interaction of TLSA records and > >>>>> services that use SRV or SRV-like mechanisms. That said, I think most of the > >>>>> comments are essentially saying that not discussing how TLSA records would > >>>>> interact with such services at all - even if that discussion is simply to say > >>>>> that those services need to specify how they are going to use TLSA records - > >>>>> is a mistake. And I have to say that is a pretty compelling argument. > >>> > >>>> Could well be. What changes to the text in 1.3 of -20 do you think > >>>> are needed if any? > >>> > >>>> " Note that this document does not cover how to associate > >>>> certificates with domain names for application protocols that depend > >>>> on SRV, NAPTR, and similar DNS resource records; it is expected that > >>>> later updates to this document might cover methods for making those > >>>> associations." > >>> > >>> Well, to be blunt, I think that by trying to avoid solving the problem now > >>> while not giving up control over future solutions this ends up being > >>> unacceptable to everyone. > >>> > >>> What if a service comes along that uses SRV records and wants to specify how > >>> TLSA records are used to secure them? According to this text, it can't - the > >>> clear implication here is that this has to be done by revising the DANE > >>> specification itself. > >>> > >>> And what about existing services like email where it is arguably the case that > >>> simply using TLSA records to secure the A/AAAA targets MX records is > >>> sufficient? A very short "secure email transport" specification could > >>> be writte that refers to the DANE specification, but this would also seem > >>> to forbid that. > >>> > >>> I would much rather see a note that simply refers to future specification work > >>> being needed, not specifically to a DANE revision being needed. > > > >> I had the same concern but then I realized that "later updates to this > >> document might cover methods for making those associations" could be > >> construed as referring to add-on documents that would officially update > >> the DANE-RFC-to-be, not as saying that such changes would need to be > >> made in the single DANEbis document that would cover all possible uses > >> of the TLSA RR. > > > > That doesn't fix the problem. Anything that says "updates RFC FOO" is > > effectively the same as a DANEbis spec. What I want is for other specification > > to be able define how to use TLSA records to secure protocols that use more > > elaborate DNS record mechanisms *without* having to update DANE. > So I don't get the sensitivity here at all. There is, afaik, no > plan for the DANE WG to be gatekeeper for anything, and nor is > there any plan for the DANE WG to have a very long lifetime. When why does the language say otherwise? > I don't think is there a definite need e.g. for something that > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > that might or might not be needed but we won't know until its > being done. But that's what it currently says is needed. > Nevertheless, how about if it said: > "Note that this document does not cover how to associate > certificates with domain names for application protocols that depend > on SRV, NAPTR, and similar DNS resource records. It is expected that > future documents will cover methods for making those associations. > Those documents may or may not need to update this one." That's essentially the change I suggested making. > As Paul said, I don't think there's any problem if you've a > better wording for that, so please do suggest some specific text > if the above doesn't work. The wording you suggest is fine with me, and addresses my concern. Ned From w@1wt.eu Tue May 1 22:41:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED42421F8995 for ; Tue, 1 May 2012 22:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.194 X-Spam-Level: X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[AWL=-5.163, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4+fEhZjSwQj for ; Tue, 1 May 2012 22:41:06 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEAC21F87D3 for ; Tue, 1 May 2012 22:41:06 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q425f3cp018475 for apps-discuss@ietf.org; Wed, 2 May 2012 07:41:03 +0200 Date: Wed, 2 May 2012 07:41:03 +0200 From: Willy Tarreau To: apps-discuss@ietf.org Message-ID: <20120502054103.GL10028@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 05:41:07 -0000 Hi, On Wed, May 02, 2012 at 09:33:53AM +1000, Mark Nottingham wrote: > HTTP folk, > > Please have a look at this document and send along comments, especially if you're an intermediary or firewall person, or consume the existing X-Forwarded-For header. > > A quick note before it escapes my mind, for 8.2. Information leak : I would add : This header field must never be copied into response messages by origin servers or intermediaries for whatever reason as it can reveal the whole proxy chain to the client. As a side effect, special care must be taken in hosting environments not to allow the TRACE request where the Forwarded field is used, as it would appear in the body of the response message. Regards, Willy From sm@elandsys.com Tue May 1 23:38:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711DB21F88B8 for ; Tue, 1 May 2012 23:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gE+cHitTxa8 for ; Tue, 1 May 2012 23:38:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4822C21F88B7 for ; Tue, 1 May 2012 23:38:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.171]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q426blCu005140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2012 23:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335940679; i=@elandsys.com; bh=zqGUK52j4TVbS4QeHUuosqOYS6oD680Orv398VKej/8=; h=Date:To:From:Subject:Cc; b=CBG6UCjMAKCbepYkFjBoDFDjD4hn5VpXifNcfzL3w+J0GWXRzZxq8qXZHcUpm91XJ 1FsQSPJ7sScxbc1bR/8IxLy9Lsk0Irbfd63wLe3jmuip7BMhX2RgiFRHKfRP0O5jZZ afQDxLQtso9Tlkot5VUyS63Kn+VpIDFGKLm/cVDg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335940679; i=@elandsys.com; bh=zqGUK52j4TVbS4QeHUuosqOYS6oD680Orv398VKej/8=; h=Date:To:From:Subject:Cc; b=ROhvctcnSExuPwud81X6AkB0zRuKgYdgqjbvJrqKg8T4Klrr9Br8cEu7o9JasMYar 6VAZDzS6jqs0Z9FLU6KCfaFTafNqnTtwPkAR4BVCxb1VOiC/TEzxKwzL+DHHfzm+lf oKqvuYaWrcljD0uljws4H7vsu/ie2Jaxf4AoLsBM= Message-Id: <6.2.5.6.2.20120501223143.0a4e9a30@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 May 2012 23:17:15 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Directorate Report for April 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 06:38:03 -0000 The Applications Area Directorate provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The directorate consists of the Working Group Chairs of the Applications Area and recognized experts in the Applications Area. Some information for authors has been published on the Applications Area Directorate web page. The following reviews were performed in April 2012: Reviewer I-D Yves Lafon draft-ietf-mile-sci-02 Ted Hardie draft-johansson-loa-registry-04 S. Moonesamy draft-dbider-sha2-mac-for-ssh-05 Yoshiro Yoneya draft-ietf-emu-chbind-14 Vijay K. Gurbani draft-ietf-cdni-problem-statement-04 William J. Mills draft-ietf-kitten-gssapi-naming-exts-14 Joseph Yee draft-ietf-appsawg-greylisting-06 Tobias Gondrom draft-ietf-krb-wg-des-die-die-die-04 Eliot Lear draft-ietf-ippm-reporting-metrics-08 S. Moonesamy draft-kucherawy-marf-source-ports-01 Ted Hardie draft-ietf-eai-simpledowngrade-03 Peter Saint-Andre draft-ietf-dane-protocol-19 Alexey Melnikov draft-ietf-dane-protocol-19 Ted Hardie draft-ietf-alto-protocol-11 Murray S. Kucherawy draft-ietf-websec-strict-transport-sec-06 Tim Bray draft-ietf-appsawg-about-uri-scheme-04 Claudio Allocchio draft-ietf-eai-simpledowngrade-03 Claudio Allocchio draft-ietf-eai-popimap-downgrade-05 Pending reviews are listed at http://trac.tools.ietf.org/area/app/trac/report/1 18 reviews last month compared to 13 reviews in April 2011. I would like to acknowledge the efforts of Ted Hardie (three reviews) and Claudio Allocchio (two reviews). There is very low women participation currently. In order to improve that I would like to encourage women to volunteer for the directorate. Please email me if you are interested or if you need more information. Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From arnt@gulbrandsen.priv.no Wed May 2 00:23:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B74821F8875; Wed, 2 May 2012 00:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGPJklLo5lia; Wed, 2 May 2012 00:23:17 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id A6FD221F8874; Wed, 2 May 2012 00:23:17 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1487BF8E7E8; Wed, 2 May 2012 07:23:15 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335943394-31604-31603/10/1; Wed, 2 May 2012 07:23:14 +0000 Message-Id: <4FA0E0F3.5050208@gulbrandsen.priv.no> Date: Wed, 2 May 2012 09:23:31 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Claudio Allocchio References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 07:23:18 -0000 On 05/01/2012 11:16 PM, Claudio Allocchio wrote: > as I already clarified in other discussions on these lists, I'm not > talking about the signatures and other features. I'm talking about > including a Security consideration section which describes clearly which > features can be broken, and just warns about this. OK, what are they? > being long is a problem in a specification? Yes. If you sort the IMAP extension RFCs (just to take a reasonably sized corpus) by length, you've more or less also sorted them by deployment. The correlation isn't 1.0. But it's much closer to 1 than to -1. >>> 2.1 Email addresses >>> >>> At lease one sentence clearly stating that this will make impossible to >>> reply to such a synthetic message should be present here. Too obvious? >>> no... never suppouse that. >> >> It's not obvious, it's wrong ;) Nothing is made impossible, it was >> impossible to start with. > > This does not change the need to state it. Do you really think that someone who has written an IMAP or POP server and extended it to support EAI needs to be told that EAI extends email addresses incompatibly? Arnt From sm@elandsys.com Wed May 2 01:00:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855BC21F8844 for ; Wed, 2 May 2012 01:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiNYOKo7E54D for ; Wed, 2 May 2012 01:00:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DF821F883A for ; Wed, 2 May 2012 01:00:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.171]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q427gY5Q025236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 May 2012 00:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335944587; i=@elandsys.com; bh=IJHjYDvtD1km7+0GNRkVBvlxhGHwcS2gmelHE4precA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qMeVNzym8vhVkNKlUtkzcVn59vKZ837FgTrzICAEgs2LnYOfagAjejADzAGCkDqdu YeURuVAiA6uJwFE0+mDlPZ68prNczdk/Kb35ST8265LTi38VXLC3P9C7+AeAx3/hu7 0+8bulkU7KWe1s0IczKV70yAEM8RDxjiIaE/fWY4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335944587; i=@elandsys.com; bh=IJHjYDvtD1km7+0GNRkVBvlxhGHwcS2gmelHE4precA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Rq6j6aQTjSgT3Qtgo3TtFEvbfJvZn55swlLsAJgtnJYNbx7UIm07miJ9QN7uT6bFy 2RsldEHJOfh4oW26auVIjb+k9mWG+Q53jSNXoAt8gXYrKwwN27ivmW336YJkcP6tTI HEr/NQ2LIORbH3iJLpZhbQj6AHzXRViWW6divFDw= Message-Id: <6.2.5.6.2.20120502000504.09882378@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 02 May 2012 00:10:38 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120501223143.0a4e9a30@elandnews.com> References: <6.2.5.6.2.20120501223143.0a4e9a30@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Apps Area Directorate Report for April 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:00:02 -0000 I forgot to include the following review in the report for April 2012: Reviewer I-D Jiankang Yao draft-claise-export-application-info-in-ipfix-05 The total number of review for last month is 19. I apologize to Jiankang for the omission. Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From Claudio.Allocchio@garr.it Wed May 2 01:10:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3317B21F8A60; Wed, 2 May 2012 01:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-gxQb+SGonR; Wed, 2 May 2012 01:10:19 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id A3DCB21F8A63; Wed, 2 May 2012 01:10:18 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q4289jDB023061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 10:09:46 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q4289jDB023061 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=u3YYL0Ei6DWo2cwelV2BdF8XD1NrAQyMmFOZgwDMQD18h5v9dq9MeA28a8pmZRTTG 5WmTwmn5e+JFD0VjE6OXJruCPNKy0xcIkSPOOdbu9Bhblrxf2OKrjs7OroBZpzIXwFu gcSDptKxXnvwCdVjU5QtQUYJJQfup6tpji0B2dM= Date: Wed, 2 May 2012 10:09:45 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Arnt Gulbrandsen In-Reply-To: <4FA0E0F3.5050208@gulbrandsen.priv.no> Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <4FA0E0F3.5050208@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: apps-discuss@ietf.org, ima@ietf.org Subject: Re: [apps-discuss] [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:10:20 -0000 On Wed, 2 May 2012, Arnt Gulbrandsen wrote: > On 05/01/2012 11:16 PM, Claudio Allocchio wrote: >> as I already clarified in other discussions on these lists, I'm not >> talking about the signatures and other features. I'm talking about >> including a Security consideration section which describes clearly which >> features can be broken, and just warns about this. > > OK, what are they? please read ALL replies before re-posting. Digesting information helps in non real time discussions like those using ML: On Wed, 2 May 2012, John Levine wrote: > I suppose we could add something like this: > > MUAs that attempt to validate message signatures such as DKIM or > S/MIME will often be unable to do so, since the downgrade > modifications will often break the signatures. Users should upgrade > to an EAI-capable MUA if they wish to continue doing signature > validation in the MUA. I replied: this is a good short and clear way to state the problem! +1 is this ok for you, too? >> being long is a problem in a specification? > > Yes. well, this is your opinion, were you probably then write the code yourself out of the specification, or suppouse that all implementers belong to the IETF world, etc.. I'm afrid I live in a different world where programmers sometine do not even know what a "scoket()" call does internally and why. But, this is an off topic for now, is it? > Do you really think that someone who has written an IMAP or POP server > and extended it to support EAI needs to be told that EAI extends email > addresses incompatibly? yes, and see above why. and it does not harm anybody. :-) ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From arnt@gulbrandsen.priv.no Wed May 2 01:21:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8444521F8AD7; Wed, 2 May 2012 01:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieSdcqqegB+q; Wed, 2 May 2012 01:21:56 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id AFAD721F8AD6; Wed, 2 May 2012 01:21:56 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2194CF8E796; Wed, 2 May 2012 08:21:55 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1335946914-31604-31603/10/3; Wed, 2 May 2012 08:21:54 +0000 Message-Id: <4FA0EEB4.6080507@gulbrandsen.priv.no> Date: Wed, 2 May 2012 10:22:12 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 Mime-Version: 1.0 To: Claudio Allocchio References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> <4FA0E0F3.5050208@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1 Cc: ima@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:21:57 -0000 On 05/02/2012 10:09 AM, Claudio Allocchio wrote: > On Wed, 2 May 2012, Arnt Gulbrandsen wrote: > >> On 05/01/2012 11:16 PM, Claudio Allocchio wrote: >>> as I already clarified in other discussions on these lists, I'm not >>> talking about the signatures and other features. I'm talking about >>> including a Security consideration section which describes clearly which >>> features can be broken, and just warns about this. >> >> OK, what are they? > > please read ALL replies before re-posting. Digesting information helps > in non real time discussions like those using ML: When I uploaded -04 at 9:50, I had read all the mail that had arrived until 9:30. Specifically regarding the security problems, I've seen that signatures can be invalid, which is in the draft, and nothing else that's concrete enough to add to the draft. I'm sorry if I've overlooked anything. Arnt From paulej@packetizer.com Wed May 2 01:42:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A03021F8A18 for ; Wed, 2 May 2012 01:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daetDB8g6JT1 for ; Wed, 2 May 2012 01:42:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EB58321F8A17 for ; Wed, 2 May 2012 01:42:43 -0700 (PDT) Received: from [156.106.218.62] ([156.106.218.62]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q428gftR001290 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 2 May 2012 04:42:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335948163; bh=1X34agviuQTP7ObRNSDSQCTRudQGYRnPBv3oxcTb1Dw=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=kXebBwUeVXSG9W6LTRXsoKdOMx5awfo95AHx25n7ujUVoc5BpRF6qdrS6C4yzpkkF 30Yf4fXclP9lpNKJq4XDXDg4yTsHgQCMMz1y/zypdTVBIu0QN7mqAAvyOjLH6FTJKg 93eV/VxwkWJG51eNirOW31SVmDQltG2HauEH6lKY= Message-ID: <4FA0F384.5050008@packetizer.com> Date: Wed, 02 May 2012 04:42:44 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:42:45 -0000 Folks, I did not see (enough) follow-up on Blaine's message regarding WebFinger. He raised three issues: 1) JSON vs. XML 2) JSON format 3) Direct vs. Indirect (i.e., single query response with "resource" parameter) I have no strong preferences to the point of derailing the project :-), but I would prefer: 1) The server is required to provide both XML and JSON formats, while the client can select what it wants 2) The JSON format should be the JRD format as described in RFC 6415 3) We should make the "resource" parameter a MUST in order to allow the client to be implemented such that it can make a single query to get the information it is seeking I believe this would satisfy the requirements from the OpenID Connect team. #3 would mean that current WebFinger servers are "broken" until they either: 1) Provide support in the WebFinger server code for the "resource" parameter 2) Use HTTP server re-writing rules (or similar) to handle the request. (See http://www.packetizer.com/webfinger/server.html for an example of how Apache can be used to allow a static site to support the "resource" parameter.) The "rel" parameter is presently listed as optional and I see no reason to mandate it. Mandating it only potentially reduces the size of the response. I think a SHOULD is enough. Static sites cannot support the "rel" parameter and they would likely have only a few link relations. How is this for a way forward? Any heartburn with this? Paul From Michael.Jones@microsoft.com Wed May 2 01:53:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E194421F882E for ; Wed, 2 May 2012 01:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.937 X-Spam-Level: X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkV3OewGSRMB for ; Wed, 2 May 2012 01:53:40 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id B668021F882D for ; Wed, 2 May 2012 01:53:39 -0700 (PDT) Received: from mail179-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 May 2012 08:53:31 +0000 Received: from mail179-va3 (localhost [127.0.0.1]) by mail179-va3-R.bigfish.com (Postfix) with ESMTP id 37FD8260194; Wed, 2 May 2012 08:53:31 +0000 (UTC) X-SpamScore: -31 X-BigFish: VS-31(zz9371I542M148cMzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail179-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail179-va3 (localhost.localdomain [127.0.0.1]) by mail179-va3 (MessageSwitch) id 1335948809703026_2699; Wed, 2 May 2012 08:53:29 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.244]) by mail179-va3.bigfish.com (Postfix) with ESMTP id A7E752400E5; Wed, 2 May 2012 08:53:29 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 2 May 2012 08:53:29 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.73]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Wed, 2 May 2012 08:53:32 +0000 From: Mike Jones To: "Paul E. Jones" , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] WebFinger Discussion Points Thread-Index: AQHNKD+PRasDh6p7LESYKe1GmD6+cJa2MXDA Date: Wed, 2 May 2012 08:53:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664A51CE@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4FA0F384.5050008@packetizer.com> In-Reply-To: <4FA0F384.5050008@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:53:41 -0000 This seems like a way forward to me, Paul. Thanks for picking the discussi= on back up. (I suspect many of us were exhausted! ;-) ) -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Paul E. Jones Sent: Wednesday, May 02, 2012 1:43 AM To: apps-discuss@ietf.org Subject: [apps-discuss] WebFinger Discussion Points Folks, I did not see (enough) follow-up on Blaine's message regarding WebFinger. = He raised three issues: 1) JSON vs. XML 2) JSON format 3) Direct vs. Indirect (i.e., single query response with "resource"=20 parameter) I have no strong preferences to the point of derailing the project :-), but= I would prefer: 1) The server is required to provide both XML and JSON formats, while the c= lient can select what it wants 2) The JSON format should be the JRD format as described in RFC 6415 3) We should make the "resource" parameter a MUST in order to allow the cli= ent to be implemented such that it can make a single query to get the infor= mation it is seeking I believe this would satisfy the requirements from the OpenID Connect team.= #3 would mean that current WebFinger servers are "broken" until they eith= er: 1) Provide support in the WebFinger server code for the "resource" paramete= r 2) Use HTTP server re-writing rules (or similar) to handle the request. =20 (See http://www.packetizer.com/webfinger/server.html for an example of how = Apache can be used to allow a static site to support the "resource"=20 parameter.) The "rel" parameter is presently listed as optional and I see no reason to = mandate it. Mandating it only potentially reduces the size of the response= . I think a SHOULD is enough. Static sites cannot support the "rel" param= eter and they would likely have only a few link relations. How is this for a way forward? Any heartburn with this? Paul _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From fanf2@hermes.cam.ac.uk Wed May 2 01:59:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BBD21F8A39; Wed, 2 May 2012 01:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE-KMJx1vRrk; Wed, 2 May 2012 01:59:43 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6D21F8A36; Wed, 2 May 2012 01:59:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37378) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SPVPS-0002EW-XJ (Exim 4.72) (return-path ); Wed, 02 May 2012 09:59:42 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPVPS-0004GL-4R (Exim 4.67) (return-path ); Wed, 02 May 2012 09:59:42 +0100 Date: Wed, 2 May 2012 09:59:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4FA031D1.50006@stpeter.im> Message-ID: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 08:59:45 -0000 Peter Saint-Andre wrote: > On 5/1/12 11:02 AM, Tony Finch wrote: > > > > I think the mistake is to talk about the client here. The client begins a > > connection to the service's port at that IP address. > > Usually, yes. Sometimes the client is configured to override the default > port for the given service, as Paul noted. My point is that the correct port is defined by the service's configuration, which belongs to the server not to the client. I didn't mean to imply the service's port is well-known - it might come from SRV records or from URLs etc. > Could we just say "It then begins a connection to a particular port at > that address"? Works for me. > Perhaps the method for determining the port isn't really > relevant in this spec. Right. A bit like the question of which name is authenticated :-) Tony. -- f.anthony.n.finch http://dotat.at/ German Bight, Humber: Variable 3 or 4, becoming north or northeast 4 or 5. Slight or moderate. Fair. Moderate or good, occasionally poor. From fanf2@hermes.cam.ac.uk Wed May 2 02:01:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557DF21F8903; Wed, 2 May 2012 02:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXsoPd7QWIqD; Wed, 2 May 2012 02:01:23 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8375C21F883C; Wed, 2 May 2012 02:01:23 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44704) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SPVR4-0003D9-YV (Exim 4.72) (return-path ); Wed, 02 May 2012 10:01:22 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPVR4-0004e0-KL (Exim 4.67) (return-path ); Wed, 02 May 2012 10:01:22 +0100 Date: Wed, 2 May 2012 10:01:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20120502033808.DC27A205548E@drugs.dv.isc.org> Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <20120502033808.DC27A205548E@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 09:01:24 -0000 Mark Andrews wrote: > Tony Finch writes: > > Ned Freed wrote: > > > > > > But even this may not be acceptable for all I know. It may turn out that using > > > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > > > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong, > > > but it seems to me that this is what all this additional discussion is about. > > > > I don't think it's as simple as that because RFC 6125 says certificates > > should match the SRV owner name not the target name. See also Dave > > Cridland's comments about XMPP. > > Should != must. Indeed, I used the word precisely :-) Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic 5 to 7, occasionally gale 8 at first, decreasing 4 at times. Moderate or rough. Rain or thundery showers. Moderate or good, occasionally poor. From gsalguei@cisco.com Wed May 2 02:32:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0557621F89E4 for ; Wed, 2 May 2012 02:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3PpKmMumiRE for ; Wed, 2 May 2012 02:32:49 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1576021F8841 for ; Wed, 2 May 2012 02:32:49 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q429Wmol012291 for ; Wed, 2 May 2012 02:32:48 -0700 (PDT) Received: from sjc-vpn3-344.cisco.com (sjc-vpn3-344.cisco.com [10.21.65.88]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q429Wiel002587; Wed, 2 May 2012 02:32:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664A51CE@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Wed, 2 May 2012 05:32:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E6BB662-7D95-4AC8-AFC3-1E8C352644F8@cisco.com> References: <4FA0F384.5050008@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664A51CE@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 09:32:50 -0000 I too support this as a way forward. I'm also of the mind that it would = be most productive if we produce an -04 version of the WebFinger draft = that incorporates these two changes (note #1 is already in the the -03 = version of the WF draft) and can be the 'line in the sand' that we can = adopt as a WG document. This base draft can be the foundation on which = we build a discovery protocol that meets the needs of both WF and SWD = camps. Cheers, Gonzalo On May 2, 2012, at 4:53 AM, Mike Jones wrote: > This seems like a way forward to me, Paul. Thanks for picking the = discussion back up. (I suspect many of us were exhausted! ;-) ) >=20 > -- Mike >=20 > -----Original Message----- > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones > Sent: Wednesday, May 02, 2012 1:43 AM > To: apps-discuss@ietf.org > Subject: [apps-discuss] WebFinger Discussion Points >=20 > Folks, >=20 > I did not see (enough) follow-up on Blaine's message regarding = WebFinger. He raised three issues: >=20 > 1) JSON vs. XML > 2) JSON format > 3) Direct vs. Indirect (i.e., single query response with "resource"=20= > parameter) >=20 > I have no strong preferences to the point of derailing the project = :-), but I would prefer: >=20 > 1) The server is required to provide both XML and JSON formats, while = the client can select what it wants > 2) The JSON format should be the JRD format as described in RFC 6415 > 3) We should make the "resource" parameter a MUST in order to allow = the client to be implemented such that it can make a single query to get = the information it is seeking >=20 > I believe this would satisfy the requirements from the OpenID Connect = team. #3 would mean that current WebFinger servers are "broken" until = they either: > 1) Provide support in the WebFinger server code for the "resource" = parameter > 2) Use HTTP server re-writing rules (or similar) to handle the = request. =20 > (See http://www.packetizer.com/webfinger/server.html for an example of = how Apache can be used to allow a static site to support the "resource"=20= > parameter.) >=20 > The "rel" parameter is presently listed as optional and I see no = reason to mandate it. Mandating it only potentially reduces the size of = the response. I think a SHOULD is enough. Static sites cannot support = the "rel" parameter and they would likely have only a few link = relations. >=20 > How is this for a way forward? Any heartburn with this? >=20 > Paul >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From melvincarvalho@gmail.com Wed May 2 03:06:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D421F8841 for ; Wed, 2 May 2012 03:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idtxwn+q3SIf for ; Wed, 2 May 2012 03:06:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2FD21F8830 for ; Wed, 2 May 2012 03:06:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so335945vbb.31 for ; Wed, 02 May 2012 03:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/u8Vyow2RpT3hD/EhO21Q+oJXo3AXOXkutNImVoG7lY=; b=LjAZqEJ7oiwRZ/mCUVgl6nDey/9H8UdHPvS8tG3R0fAbEwhByIfomKbi44pyt4LeAG dDMH7xAWK4s3iAUOfvbLPrB0v/qvwaa0H4zQr/zmgzc2fdP73FxrijI9J1LxCjNJYvUw ux+1O6VNSeZ+JNhJcFtGC87kgQIxaASenmDszSX/5+nfApUb80Zccib4vKldC9HfvrD1 TwCvUy0BCGphEhNPYriKtMVfpqMme3Fs3+x/hec1+6vteTaQAuW0W44ELiQK1Ax/XZ7L cC6Pbja26WsM5G9uBL3HEHul/6ygK8VSzpriL0Mju/i6U3TSJLxLN6UGDawheXvNSFVA SLoA== MIME-Version: 1.0 Received: by 10.52.91.16 with SMTP id ca16mr9005202vdb.125.1335953174771; Wed, 02 May 2012 03:06:14 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Wed, 2 May 2012 03:06:14 -0700 (PDT) In-Reply-To: <4FA0F384.5050008@packetizer.com> References: <4FA0F384.5050008@packetizer.com> Date: Wed, 2 May 2012 12:06:14 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf307f3be26b39e604bf0ad63b Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 10:06:16 -0000 --20cf307f3be26b39e604bf0ad63b Content-Type: text/plain; charset=ISO-8859-1 On 2 May 2012 10:42, Paul E. Jones wrote: > Folks, > > I did not see (enough) follow-up on Blaine's message regarding WebFinger. > He raised three issues: > > 1) JSON vs. XML > 2) JSON format > 3) Direct vs. Indirect (i.e., single query response with "resource" > parameter) > > I have no strong preferences to the point of derailing the project :-), > but I would prefer: > > 1) The server is required to provide both XML and JSON formats, while the > client can select what it wants > -1 I thought issue #1 was for JSON ONLY? And only to reply if there was anyone supporting XML. I didnt see any replies. I may have misunderstood the whole thing tho. I came across this video recently, entitled "Lessons of JSON" http://inkdroid.org/journal/2012/04/30/lessons-of-json/ Douglas Crockford gives some insights into the advantages of JSON over XML. > 2) The JSON format should be the JRD format as described in RFC 6415 > I think I was the only person to reply to this point. I'm curious as to why a bespoke almost unused MIME type application/xrd+json Rather than, the commonly used: application/json As per SWD Is there a spec for JRD, other than Eran's blog post. What's the licensing? > 3) We should make the "resource" parameter a MUST in order to allow the > client to be implemented such that it can make a single query to get the > information it is seeking > > I believe this would satisfy the requirements from the OpenID Connect > team. #3 would mean that current WebFinger servers are "broken" until they > either: > 1) Provide support in the WebFinger server code for the "resource" > parameter > 2) Use HTTP server re-writing rules (or similar) to handle the request. > (See http://www.packetizer.com/**webfinger/server.htmlfor an example of how Apache can be used to allow a static site to support > the "resource" parameter.) > What are the typical values that resource can take? Is resource=user@host acceptable, or is a scheme required? In particular re acct: Is the new scheme "acct" still proposed? The documentation for the account scheme is still incomplete as of http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 Should it have its own RFC, or folded into the new joint spec? Personally, I think documenting acct: is a bigger task than SWD itself. If, once documented and reviewed, there is a consensus is for acct: is taken forward, should it be a new URI scheme or a URN? How does it relate to XMPP and email? Are there possible collisions? etc. etc. > > The "rel" parameter is presently listed as optional and I see no reason to > mandate it. Mandating it only potentially reduces the size of the > response. I think a SHOULD is enough. Static sites cannot support the > "rel" parameter and they would likely have only a few link relations. > > How is this for a way forward? Any heartburn with this? > > Paul > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --20cf307f3be26b39e604bf0ad63b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 May 2012 10:42, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

I did not see (enough) follow-up on Blaine's message regarding WebFinge= r. =A0He raised three issues:

1) JSON vs. XML
2) JSON format
3) Direct vs. =A0Indirect (i.e., single query response with "resource&= quot; parameter)

I have no strong preferences to the point of derailing the project :-), but= I would prefer:

1) The server is required to provide both XML and JSON formats, while the c= lient can select what it wants

-1

I thought= issue #1 was for JSON ONLY?=A0 And only to reply if there was anyone suppo= rting XML.=A0 I didnt see any replies.=A0 I may have misunderstood the whol= e thing tho.

I came across this video recently, entitled "Lessons of JSON"=

http://inkdroid.org/journal/2012/04/30/lessons-of-json/

Douglas= Crockford gives some insights into the advantages of JSON over XML.
=A0
2) The JSON format should be the JRD format as described in RFC 6415

I think I was the only person to reply to this point.
I'm curious as to why a bespoke almost unused MIME type

application/xrd+json

Rather than, the commonly used:

applica= tion/json

As per SWD

Is there a spec for JRD, other than Era= n's blog post.=A0 What's the licensing?
=A0
3) We should make the "resource" parameter a MUST in order to all= ow the client to be implemented such that it can make a single query to get= the information it is seeking

I believe this would satisfy the requirements from the OpenID Connect team.= =A0#3 would mean that current WebFinger servers are "broken" unt= il they either:
1) Provide support in the WebFinger server code for the "resource"= ; parameter
2) Use HTTP server re-writing rules (or similar) to handle the request. =A0= (See http://www.packetizer.com/webfinger/server.html for an e= xample of how Apache can be used to allow a static site to support the &quo= t;resource" parameter.)

What are the typical values that resource can take?
Is resource=3Duser@host acceptable, or is a scheme required?

In particular re acct:

Is the new scheme "acct" still = proposed?=A0 The documentation for the account scheme is still incomplete a= s of http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03

Should it have its own RFC, or folded into the new joint spec?=A0 Perso= nally, I think documenting acct: is a bigger task than SWD itself.

I= f, once documented and reviewed, there is a consensus is for acct: is taken= forward, should it be a new URI scheme or a URN?

How does it relate to XMPP and email?=A0 Are there possible collisions?=

etc. etc.
=A0

The "rel" parameter is presently listed as optional and I see no = reason to mandate it. =A0Mandating it only potentially reduces the size of = the response. I think a SHOULD is enough. =A0Static sites cannot support = =A0the "rel" parameter and they would likely have only a few link= relations.

How is this for a way forward? =A0Any heartburn with this?

Paul

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf307f3be26b39e604bf0ad63b-- From melvincarvalho@gmail.com Wed May 2 03:11:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04F21F851B for ; Wed, 2 May 2012 03:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJIDfXmw35fA for ; Wed, 2 May 2012 03:11:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63FC921F863E for ; Wed, 2 May 2012 03:11:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so339114vbb.31 for ; Wed, 02 May 2012 03:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mnw6pN5TSUSb8/ovWhJLCVKUGvnNMpxXETbS7reNVT4=; b=ncf1GlNIYj4dRDEtLwvYo5RQ3WkiW6DE6M3GpKlFHbkT/7jKBCV1qP+ey1ggXYIXR7 QWWs46OGt5FC4nA7nBuHrSYT7jEfuGEdGOFJ6LSfN4IH+BkAcabi5hHkuWMJGtjh4YjU ZzjOoTbfIeO7ZRu3lohsLVixnGXLmP7u+ihIqubILOR8nXAG/InaIrnfFODxAEFoEM3e f5azX+5YR/VkEcqqXryyxiS5In7LhtU0w4uRAPIpCmGjHTRHYR68+0uzu1zSe9eBmSBn PF3BjRyzr1XoJaJjW3Zw0jjpHnpVgTxkEvbVXS+t+0pbOeKFv09N1kZbFI5N2YUJt3rH sVeA== MIME-Version: 1.0 Received: by 10.52.17.82 with SMTP id m18mr23707292vdd.89.1335953460868; Wed, 02 May 2012 03:11:00 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Wed, 2 May 2012 03:11:00 -0700 (PDT) In-Reply-To: References: <4FA0F384.5050008@packetizer.com> Date: Wed, 2 May 2012 12:11:00 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=bcaec50405d678b7f104bf0ae704 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 10:11:02 -0000 --bcaec50405d678b7f104bf0ae704 Content-Type: text/plain; charset=ISO-8859-1 On 2 May 2012 12:06, Melvin Carvalho wrote: > > > On 2 May 2012 10:42, Paul E. Jones wrote: > >> Folks, >> >> I did not see (enough) follow-up on Blaine's message regarding WebFinger. >> He raised three issues: >> >> 1) JSON vs. XML >> 2) JSON format >> 3) Direct vs. Indirect (i.e., single query response with "resource" >> parameter) >> >> I have no strong preferences to the point of derailing the project :-), >> but I would prefer: >> >> 1) The server is required to provide both XML and JSON formats, while the >> client can select what it wants >> > > -1 > > I thought issue #1 was for JSON ONLY? And only to reply if there was > anyone supporting XML. I didnt see any replies. I may have misunderstood > the whole thing tho. > > I came across this video recently, entitled "Lessons of JSON" > > http://inkdroid.org/journal/2012/04/30/lessons-of-json/ > > Douglas Crockford gives some insights into the advantages of JSON over XML. > > >> 2) The JSON format should be the JRD format as described in RFC 6415 >> > > I think I was the only person to reply to this point. > > I'm curious as to why a bespoke almost unused MIME type > > application/xrd+json > > Rather than, the commonly used: > > application/json > > As per SWD > > Is there a spec for JRD, other than Eran's blog post. What's the > licensing? > Ah I just found http://tools.ietf.org/html/rfc6415#appendix-A (thanks for the pointer) I'd still like to understand the motivation for creating a new flavor of JSON (and MIME type) as per (WF) rather than using standard JSON (as per SWD) > > >> 3) We should make the "resource" parameter a MUST in order to allow the >> client to be implemented such that it can make a single query to get the >> information it is seeking >> >> I believe this would satisfy the requirements from the OpenID Connect >> team. #3 would mean that current WebFinger servers are "broken" until they >> either: >> 1) Provide support in the WebFinger server code for the "resource" >> parameter >> 2) Use HTTP server re-writing rules (or similar) to handle the request. >> (See http://www.packetizer.com/**webfinger/server.htmlfor an example of how Apache can be used to allow a static site to support >> the "resource" parameter.) >> > > What are the typical values that resource can take? > > Is resource=user@host acceptable, or is a scheme required? > > In particular re acct: > > Is the new scheme "acct" still proposed? The documentation for the > account scheme is still incomplete as of > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > > Should it have its own RFC, or folded into the new joint spec? > Personally, I think documenting acct: is a bigger task than SWD itself. > > If, once documented and reviewed, there is a consensus is for acct: is > taken forward, should it be a new URI scheme or a URN? > > How does it relate to XMPP and email? Are there possible collisions? > > etc. etc. > > >> >> The "rel" parameter is presently listed as optional and I see no reason >> to mandate it. Mandating it only potentially reduces the size of the >> response. I think a SHOULD is enough. Static sites cannot support the >> "rel" parameter and they would likely have only a few link relations. >> >> How is this for a way forward? Any heartburn with this? >> >> Paul >> >> ______________________________**_________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/**listinfo/apps-discuss >> > > --bcaec50405d678b7f104bf0ae704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 May 2012 12:06, Melvin Carvalho <melvincarvalho@gmail.com> wrote:


On 2 May 2012 10:42, P= aul E. Jones <paulej@packetizer.com> wrote:
Folks,

I did not see (enough) follow-up on Blaine's message regarding WebFinge= r. =A0He raised three issues:

1) JSON vs. XML
2) JSON format
3) Direct vs. =A0Indirect (i.e., single query response with "resource&= quot; parameter)

I have no strong preferences to the point of derailing the project :-), but= I would prefer:

1) The server is required to provide both XML and JSON formats, while the c= lient can select what it wants

-1

I t= hought issue #1 was for JSON ONLY?=A0 And only to reply if there was anyone= supporting XML.=A0 I didnt see any replies.=A0 I may have misunderstood th= e whole thing tho.

I came across this video recently, entitled "Lessons of JSON"=

http://inkdroid.org/journal/2012/04/30/lessons-of-json/<= /a>

Douglas Crockford gives some insights into the advantages of JSON over = XML.
=A0
http://tools.ietf.org/html/rfc6415#appendix-A (thanks for the p= ointer)

I'd still like to understand the motivation for creating= a new flavor of JSON (and MIME type) as per (WF) rather than using standar= d JSON (as per SWD)
=A0
=A0
3) We should make the "resource" parameter a MUST in order to all= ow the client to be implemented such that it can make a single query to get= the information it is seeking

I believe this would satisfy the requirements from the OpenID Connect team.= =A0#3 would mean that current WebFinger servers are "broken" unt= il they either:
1) Provide support in the WebFinger server code for the "resource"= ; parameter
2) Use HTTP server re-writing rules (or similar) to handle the request. =A0= (See http://www.packetizer.com/webfinger/server.html for an e= xample of how Apache can be used to allow a static site to support the &quo= t;resource" parameter.)

What are the typical values that resource can t= ake?

Is resource=3Duser@host acceptable, or is a scheme required?
In particular re acct:

Is the new scheme "acct" still = proposed?=A0 The documentation for the account scheme is still incomplete a= s of http://tools.ietf.org/html/draft-jones-appsawg-webfinge= r-03

Should it have its own RFC, or folded into the new joint spec?=A0 Perso= nally, I think documenting acct: is a bigger task than SWD itself.

I= f, once documented and reviewed, there is a consensus is for acct: is taken= forward, should it be a new URI scheme or a URN?

How does it relate to XMPP and email?=A0 Are there possible collisions?=

etc. etc.
=A0

The "rel" parameter is presently listed as optional and I see no = reason to mandate it. =A0Mandating it only potentially reduces the size of = the response. I think a SHOULD is enough. =A0Static sites cannot support = =A0the "rel" parameter and they would likely have only a few link= relations.

How is this for a way forward? =A0Any heartburn with this?

Paul

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--bcaec50405d678b7f104bf0ae704-- From michiel@unhosted.org Wed May 2 03:14:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D81C21F8AF4 for ; Wed, 2 May 2012 03:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b8Ed4BkTI2W for ; Wed, 2 May 2012 03:14:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53B2321F8AF3 for ; Wed, 2 May 2012 03:14:41 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so893406pbc.31 for ; Wed, 02 May 2012 03:14:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NoWHVuZzTdiW/58tprNfWhhFzCdb34XvVi5HY+wPh98=; b=a/dzP0SVqkWVtpJ5uc8lokF2dSvE3ZUbUJV7Ba+pkZcJv8kT6zCwc7mRf/E/3Fg09X AF/mnKzK5XcuFQgM2b/UaFkIz6DyN6ldUS43WljvToyezxuPX9YR2nbwBxnaG0xK2QhS /1DUj/W/k/KzWSZ5QjUaS4aBcy5EkThEehE3T4/LUVjYk6+k9BqYp1VP4sYq81U9aKEJ +3opgWjhEh3yARVxwFF/iqwC2mCZIQNN4a+zteGRlumJp09Yn3jh47KvTBlmdt04iQnx 5GmXj+Xg1vajH3/x0H6lQowYKihYfrod6hsVpchhoHyfTnz+iWdw/xw9O3+kmxFlALak YkPA== MIME-Version: 1.0 Received: by 10.68.129.38 with SMTP id nt6mr4529608pbb.38.1335953681136; Wed, 02 May 2012 03:14:41 -0700 (PDT) Received: by 10.68.27.138 with HTTP; Wed, 2 May 2012 03:14:41 -0700 (PDT) X-Originating-IP: [89.247.181.2] In-Reply-To: <5E6BB662-7D95-4AC8-AFC3-1E8C352644F8@cisco.com> References: <4FA0F384.5050008@packetizer.com> <4E1F6AAD24975D4BA5B1680429673943664A51CE@TK5EX14MBXC284.redmond.corp.microsoft.com> <5E6BB662-7D95-4AC8-AFC3-1E8C352644F8@cisco.com> Date: Wed, 2 May 2012 12:14:41 +0200 Message-ID: From: Michiel de Jong To: Gonzalo Salgueiro Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnDT118L3nh5O8plCIUYO2dvviWmbUf8HT80LRulPR5LMv34cPBDxgPZdGDIDzk/JLsvblM Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 10:14:42 -0000 On Wed, May 2, 2012 at 11:32 AM, Gonzalo Salgueiro wrote: > it would be most productive if we produce an -04 version of the WebFinger draft that incorporates these two changes +1 From sm@elandsys.com Wed May 2 03:37:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3921F8A36 for ; Wed, 2 May 2012 03:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz-2+SGVb9jA for ; Wed, 2 May 2012 03:37:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E8C21F8A31 for ; Wed, 2 May 2012 03:37:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.171]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q42Ab9tT019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 03:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335955043; i=@elandsys.com; bh=Dfv4v73RWVbgy18z4liG6lgvt4Sb0icXWXhqGQg2YN0=; h=Date:To:From:Subject:Cc; b=hMs2WMTygFTvhgjKo/9QuJIdLAkOEhrxiriD5t3bF7U8l7kDFdiQZqOIHrbZVj8Gc IhdYpue8h03G1F+SDHCpwpwjaPdYfhvmjcPBl2V1jt69yfwyRaxVrVIsG0TD+1yr3v I8svE3noCOP0pYdVMlOAli2K+X21672a/L+MkC3E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335955043; i=@elandsys.com; bh=Dfv4v73RWVbgy18z4liG6lgvt4Sb0icXWXhqGQg2YN0=; h=Date:To:From:Subject:Cc; b=ZocBzkxt5Xa6EI2Q6ZJnK3ntXM6LGTsSJkiAGGgmaCX0RTq4ey6XS0l8A+rbzLqS4 2Flk3KOdEWgDZwkQY+oQiRsWF2yVTFjUx8D+803co64b5jIC86Bq5CM89EEByjHtvW zOUwpTgIzx9dZQOKITDLnDuYOmy4czL3RHz359sM= Message-Id: <6.2.5.6.2.20120502015143.0a1cbeb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 02 May 2012 03:23:53 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-l2vpn-arp-mediation.all@tools.ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-l2vpn-arp-mediation-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 10:37:33 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on AppsDir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-l2vpn-arp-mediation-19 Title: ARP Mediation for IP Interworking of Layer 2 VPN Reviewer: S. Moonesamy Review Date: May 2, 2012 IETF Last Call Date: April 12, 2012 Summary: I'll abstain from making any recommendation about publication as the L2VPN Working Group has been working on this draft since October 2004. This draft describes methods for ARP Mediation when different resolution protocols are used on either Attachment Circuit. It does not contain any Application considerations. I am not familiar with the subject. Major issues: It is not clear throughout the document whether "IP address" refers to IPv4 and IPv6 or IPv4 only. In Section 1: "In this document, we specify the procedures for VPWS services, which the PEs MUST implement in order to mediate the IP address resolution mechanism." BTW, VPWS is expanded on first use below that. It's difficult to figure out the procedures for that "MUST". In Section 4.1.2: "This document mandates that there MUST be only one CE per Attachment Circuit. However, customer facing access topologies may exist whereby more than one CE appears to be connected to the PE on a single Attachment Circuit." There is a requirement for only one CE per Attachment Circuit and yet it is mentioned that there may be cases where more than one CE appears to be connected. If there are cases when the requirement cannot be followed, why is it a requirement? In Section 8.1: "For greater security the LDP connection between two trusted PEs MUST be secured by each PE verifying the incoming connection against the configured address of the peer and authenticating the LDP messages using MD5 authentication, as described in section 2.9 of [RFC5036]." Isn't the MD5 authentication considered as obsolete? In Appendix A.1: "In an IP L2 interworking L2VPN, when an IGP on a CE connected to a broadcast link is cross-connected with an IGP on a CE connected to a point-to-point link, there are routing protocol related issues that MUST be addressed." Addressing protocol related issues is a vague requirement. Minor isues: In Section 2: "1. Discover the IP address of the locally attached CE device" Is this for IPv4 addresses only? In Section 3: "If the IP packet arrives at the ingress PE with multiple data link headers (for example in the case of bridged Ethernet PDU on an ATM Attachment Circuit), all data link headers MUST be removed from the IP packet before transmission over the PW." What is "PW"? Nits: I found the Abstract Section difficult to parse. There are four authors listed on the first page of the draft. However, there are 16 authors/editors listed in the Authors' Addresses section. Given that there is an IPR disclosure on this draft, can the document shepherd answer the following question: Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Please note that this review does not contain editorial comments. Regards, S. Moonesamy From paulej@packetizer.com Wed May 2 04:03:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BEE21F89A2 for ; Wed, 2 May 2012 04:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+LUt0VOeQLD for ; Wed, 2 May 2012 04:03:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 88CFC21F899F for ; Wed, 2 May 2012 04:03:46 -0700 (PDT) Received: from [156.106.218.62] ([156.106.218.62]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q42B3foq004962 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 May 2012 07:03:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335956625; bh=xHr1OEgWLOW7gSlwxsroryKNYw1zXJXQ2MYQ/ZdnMwI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=FVJxOw8RyEaB7V7M2kKqFvZ5exX03Cw70bpDnK1NDQ5UL4ANXTXW3+lW3EdLhOSDB +PLOUWD/0lAGsLtWNyNL+rmcoDLuKwLzO5QanG1rRpvvfM5ZW5oNxY1qENZzbkN0v4 fXXMxS/R3pdeFICkkvoCt9U2fcg8cT9qdgMiuWjM= Message-ID: <4FA11490.9010400@packetizer.com> Date: Wed, 02 May 2012 07:03:44 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melvin Carvalho References: <4FA0F384.5050008@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000501080109050606010603" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:03:47 -0000 This is a multi-part message in MIME format. --------------000501080109050606010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/2/2012 6:06 AM, Melvin Carvalho wrote: > > > On 2 May 2012 10:42, Paul E. Jones > wrote: > > Folks, > > I did not see (enough) follow-up on Blaine's message regarding > WebFinger. He raised three issues: > > 1) JSON vs. XML > 2) JSON format > 3) Direct vs. Indirect (i.e., single query response with > "resource" parameter) > > I have no strong preferences to the point of derailing the project > :-), but I would prefer: > > 1) The server is required to provide both XML and JSON formats, > while the client can select what it wants > > > -1 > > I thought issue #1 was for JSON ONLY? And only to reply if there was > anyone supporting XML. I didnt see any replies. I may have > misunderstood the whole thing tho. He did call for JSON only. However, RFC 6415 and current WebFinger servers use XML. So, I don't think we should simply disregard those facts. Supporting both on the server side is trivial, so I don't see a reason to not implement both. > I came across this video recently, entitled "Lessons of JSON" > > http://inkdroid.org/journal/2012/04/30/lessons-of-json/ > > Douglas Crockford gives some insights into the advantages of JSON over > XML. > > 2) The JSON format should be the JRD format as described in RFC 6415 > > > I think I was the only person to reply to this point. > > I'm curious as to why a bespoke almost unused MIME type > > application/xrd+json > > Rather than, the commonly used: > > application/json > > As per SWD The media type "xrd+json" would not be right since a JRD is not XML. We could define jrd+json, but this starts us down the path of having a gazillion whatever+json definitions like there with +xml definitions. I'll note that there are no standards in the IETF presently that define a whatever+json. We would be the first and that gives me some concern. Is application/json an issue? > > Is there a spec for JRD, other than Eran's blog post. What's the > licensing? I noted you found this in your follow-up. It is in RFC 6415, as you noted. > 3) We should make the "resource" parameter a MUST in order to > allow the client to be implemented such that it can make a single > query to get the information it is seeking > > I believe this would satisfy the requirements from the OpenID > Connect team. #3 would mean that current WebFinger servers are > "broken" until they either: > 1) Provide support in the WebFinger server code for the "resource" > parameter > 2) Use HTTP server re-writing rules (or similar) to handle the > request. (See http://www.packetizer.com/webfinger/server.html for > an example of how Apache can be used to allow a static site to > support the "resource" parameter.) > > > What are the typical values that resource can take? The resource parameter would take any valid URI. > > Is resource=user@host acceptable, or is a scheme required? It should always have a scheme, otherwise it would have no specific meaning. > > In particular re acct: > > Is the new scheme "acct" still proposed? The documentation for the > account scheme is still incomplete as of > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 "acct" has been proposed for a long time now and documented in the WebFinger draft. Why do you say it is incomplete? What is missing, exactly? > Should it have its own RFC, or folded into the new joint spec? > Personally, I think documenting acct: is a bigger task than SWD itself. Since I don't know what you feel is missing, it's hard to argue otherwise :-) We could move the acct URI to a different draft, but what would be the value? It would just require people to hunt down even more documents. > If, once documented and reviewed, there is a consensus is for acct: is > taken forward, should it be a new URI scheme or a URN? Please note that "acct" is already implemented. I think we should leave it as-is. > How does it relate to XMPP and email? Are there possible collisions? This is precisely why we need "acct". One's email address is one URI (mailto:) and one's XMPP address is another (xmpp:). The "acct" URI refers to a user account and not their email address or XMPP address, etc. You might query my Google+ account, for example, and discover that I have several different email addresses and XMPP addresses, but I have one Google+ account. Paul --------------000501080109050606010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/2/2012 6:06 AM, Melvin Carvalho wrote:


On 2 May 2012 10:42, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

I did not see (enough) follow-up on Blaine's message regarding WebFinger.  He raised three issues:

1) JSON vs. XML
2) JSON format
3) Direct vs.  Indirect (i.e., single query response with "resource" parameter)

I have no strong preferences to the point of derailing the project :-), but I would prefer:

1) The server is required to provide both XML and JSON formats, while the client can select what it wants

-1

I thought issue #1 was for JSON ONLY?  And only to reply if there was anyone supporting XML.  I didnt see any replies.  I may have misunderstood the whole thing tho.

He did call for JSON only.  However, RFC 6415 and current WebFinger servers use XML.  So, I don't think we should simply disregard those facts.  Supporting both on the server side is trivial, so I don't see a reason to not implement both.

I came across this video recently, entitled "Lessons of JSON"

http://inkdroid.org/journal/2012/04/30/lessons-of-json/

Douglas Crockford gives some insights into the advantages of JSON over XML.
 
2) The JSON format should be the JRD format as described in RFC 6415

I think I was the only person to reply to this point.

I'm curious as to why a bespoke almost unused MIME type

application/xrd+json

Rather than, the commonly used:

application/json

As per SWD

The media type "xrd+json" would not be right since a JRD is not XML.  We could define jrd+json, but this starts us down the path of having a gazillion whatever+json definitions like there with +xml definitions.  I'll note that there are no standards in the IETF presently that define a whatever+json.  We would be the first and that gives me some concern.  Is application/json an issue?


Is there a spec for JRD, other than Eran's blog post.  What's the licensing?

I noted you found this in your follow-up. It is in RFC 6415, as you noted.
 
3) We should make the "resource" parameter a MUST in order to allow the client to be implemented such that it can make a single query to get the information it is seeking

I believe this would satisfy the requirements from the OpenID Connect team.  #3 would mean that current WebFinger servers are "broken" until they either:
1) Provide support in the WebFinger server code for the "resource" parameter
2) Use HTTP server re-writing rules (or similar) to handle the request.  (See http://www.packetizer.com/webfinger/server.html for an example of how Apache can be used to allow a static site to support the "resource" parameter.)

What are the typical values that resource can take?

The resource parameter would take any valid URI.


Is resource=user@host acceptable, or is a scheme required?

It should always have a scheme, otherwise it would have no specific meaning.


In particular re acct:

Is the new scheme "acct" still proposed?  The documentation for the account scheme is still incomplete as of http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03

"acct" has been proposed for a long time now and documented in the WebFinger draft.  Why do you say it is incomplete?  What is missing, exactly?

Should it have its own RFC, or folded into the new joint spec?  Personally, I think documenting acct: is a bigger task than SWD itself.

Since I don't know what you feel is missing, it's hard to argue otherwise :-)  We could move the acct URI to a different draft, but what would be the value?  It would just require people to hunt down even more documents.

If, once documented and reviewed, there is a consensus is for acct: is taken forward, should it be a new URI scheme or a URN?

Please note that "acct" is already implemented.  I think we should leave it as-is.

How does it relate to XMPP and email?  Are there possible collisions?

This is precisely why we need "acct".  One's email address is one URI (mailto:) and one's XMPP address is another (xmpp:).  The "acct" URI refers to a user account and not their email address or XMPP address, etc.  You might query my Google+ account, for example, and discover that I have several different email addresses and XMPP addresses, but I have one Google+ account.

Paul

--------------000501080109050606010603-- From paulej@packetizer.com Wed May 2 04:05:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBD221F8A94 for ; Wed, 2 May 2012 04:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExMUHRmIMC9F for ; Wed, 2 May 2012 04:05:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03321F89A9 for ; Wed, 2 May 2012 04:05:44 -0700 (PDT) Received: from [156.106.218.62] ([156.106.218.62]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q42B5fac005025 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 May 2012 07:05:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335956743; bh=e52Gas+XmdqyLbIPzjt2ot7PLdvp25lFg3ppAJ5oRGQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=XUkfhIytNcFLzpksWfIoEZyxW9Z5Y8ey4qJmmtqZk5WP31gPnq7UR//iRM/yHj2Rn R+brphqcGpfVm/0yssC8DRfmD9Zh39JsE/8HFUEzwYHjM4ip71L63APy1LABw7dpaQ izmjX3+/Qat1ZIz1mh2p/L4d7KS1nfdxpDEG0tng= Message-ID: <4FA11509.3090104@packetizer.com> Date: Wed, 02 May 2012 07:05:45 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melvin Carvalho References: <4FA0F384.5050008@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070607020102010709070209" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:05:45 -0000 This is a multi-part message in MIME format. --------------070607020102010709070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/2/2012 6:11 AM, Melvin Carvalho wrote: > > Rather than, the commonly used: > > application/json > > As per SWD > > Is there a spec for JRD, other than Eran's blog post. What's the > licensing? > > > Ah I just found http://tools.ietf.org/html/rfc6415#appendix-A (thanks > for the pointer) > > I'd still like to understand the motivation for creating a new flavor > of JSON (and MIME type) as per (WF) rather than using standard JSON > (as per SWD) Why do you say this is a new flavor of JSON? It's not. It also uses the application/json media type as defined in RFC 4627. Paul --------------070607020102010709070209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/2/2012 6:11 AM, Melvin Carvalho wrote:
Rather than, the commonly used:

application/json

As per SWD

Is there a spec for JRD, other than Eran's blog post.  What's the licensing?

Ah I just found http://tools.ietf.org/html/rfc6415#appendix-A (thanks for the pointer)

I'd still like to understand the motivation for creating a new flavor of JSON (and MIME type) as per (WF) rather than using standard JSON (as per SWD)
 

Why do you say this is a new flavor of JSON?  It's not.  It also uses the application/json media type as defined in RFC 4627.

Paul

--------------070607020102010709070209-- From melvincarvalho@gmail.com Wed May 2 04:08:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EB621F8AD6 for ; Wed, 2 May 2012 04:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJvWI6swkRVm for ; Wed, 2 May 2012 04:08:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A343721F8A95 for ; Wed, 2 May 2012 04:08:01 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so377432vcb.31 for ; Wed, 02 May 2012 04:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ePUvHIGZr1i1J5GuDv5x3fCeSqsMxD5A10wsdv5P9y8=; b=cRfgQps9eopBN9q3QXDuBsZIYYfzGLCdwHd4ZJRDt3TQHcuJnPRfP4UH+B7rvlPWsa CJjtVV3zhd4v2s8mO7A3ZoyEsE9PdIZqhqXRsaCC1faZh8ZSslv2WOpogBAJlMJK4qyt 1rh8pofYBXsMzvbOBoCB+MqqZDGNRjlLxrOyRed2P7cQAzQNY5IuTc5njwjWN5hIurvA LdCJ+msxlY9cHkezAlC9ZRb1tt7O/f0T7pl8IDXtnA4YGr+/nHmzsVhjA05m+LnJLOiR y6DHGByEBJG+C+1PQK5XY59ypCA64NlrGuaSXMpJ5SSAiXZG7USjN7fg9Wf8bzc4Z4Kk Uk9A== MIME-Version: 1.0 Received: by 10.52.90.178 with SMTP id bx18mr14032966vdb.123.1335956880958; Wed, 02 May 2012 04:08:00 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Wed, 2 May 2012 04:08:00 -0700 (PDT) In-Reply-To: <4FA0F384.5050008@packetizer.com> References: <4FA0F384.5050008@packetizer.com> Date: Wed, 2 May 2012 13:08:00 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf3071cffa5325f004bf0bb308 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:08:02 -0000 --20cf3071cffa5325f004bf0bb308 Content-Type: text/plain; charset=ISO-8859-1 On 2 May 2012 10:42, Paul E. Jones wrote: > Folks, > > I did not see (enough) follow-up on Blaine's message regarding WebFinger. > He raised three issues: > > 1) JSON vs. XML > 2) JSON format > 3) Direct vs. Indirect (i.e., single query response with "resource" > parameter) > > I have no strong preferences to the point of derailing the project :-), > but I would prefer: > > 1) The server is required to provide both XML and JSON formats, while the > client can select what it wants > 2) The JSON format should be the JRD format as described in RFC 6415 > 3) We should make the "resource" parameter a MUST in order to allow the > client to be implemented such that it can make a single query to get the > information it is seeking > > I believe this would satisfy the requirements from the OpenID Connect > team. #3 would mean that current WebFinger servers are "broken" until they > either: > 1) Provide support in the WebFinger server code for the "resource" > parameter > 2) Use HTTP server re-writing rules (or similar) to handle the request. > (See http://www.packetizer.com/**webfinger/server.htmlfor an example of how Apache can be used to allow a static site to support > the "resource" parameter.) > > The "rel" parameter is presently listed as optional and I see no reason to > mandate it. Mandating it only potentially reduces the size of the > response. I think a SHOULD is enough. Static sites cannot support the > "rel" parameter and they would likely have only a few link relations. > > How is this for a way forward? Any heartburn with this? > One thing that would be a kind of joint problem statement, of the main thing that's trying to be solved. I think this started out as a way for webmail providers to give auxiliary "follow your nose" style data linkage, using the "well known" pattern. It's sort of morphed a bit into a few different things, such as a generic discovery method for the net, a new uri scheme, an account identity system for the net, serialization formats. All these things *can* be important, but there's already solutions in many places, and overlap with existing technology. The recent WWW 2012 conference has shown that structured data is now incoporated in somewhere between 25% and 32% of the web, eg using RDFa and microdta. Do we think it's productive to push yet another data lookup format? http://www.bbc.co.uk/blogs/researchanddevelopment/2012/04/notes-from-the-www12-conferenc.shtml It would be awesome if we can main pain point, or problem statement that these specs can solve, find out what the easy wins are, solve those with minimum fuss, imho. > > Paul > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --20cf3071cffa5325f004bf0bb308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 May 2012 10:42, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

I did not see (enough) follow-up on Blaine's message regarding WebFinge= r. =A0He raised three issues:

1) JSON vs. XML
2) JSON format
3) Direct vs. =A0Indirect (i.e., single query response with "resource&= quot; parameter)

I have no strong preferences to the point of derailing the project :-), but= I would prefer:

1) The server is required to provide both XML and JSON formats, while the c= lient can select what it wants
2) The JSON format should be the JRD format as described in RFC 6415
3) We should make the "resource" parameter a MUST in order to all= ow the client to be implemented such that it can make a single query to get= the information it is seeking

I believe this would satisfy the requirements from the OpenID Connect team.= =A0#3 would mean that current WebFinger servers are "broken" unt= il they either:
1) Provide support in the WebFinger server code for the "resource"= ; parameter
2) Use HTTP server re-writing rules (or similar) to handle the request. =A0= (See http://www.packetizer.com/webfinger/server.html for an e= xample of how Apache can be used to allow a static site to support the &quo= t;resource" parameter.)

The "rel" parameter is presently listed as optional and I see no = reason to mandate it. =A0Mandating it only potentially reduces the size of = the response. I think a SHOULD is enough. =A0Static sites cannot support = =A0the "rel" parameter and they would likely have only a few link= relations.

How is this for a way forward? =A0Any heartburn with this?
=

One thing that would be a kind of joint problem statement, of the = main thing that's trying to be solved.

I think this started out = as a way for webmail providers to give auxiliary "follow your nose&quo= t; style data linkage, using the "well known" pattern.

It's sort of morphed a bit into a few different things, such as a g= eneric discovery method for the net, a new uri scheme,=A0 an account identi= ty system for the net, serialization formats.

All these things *can*= be important, but there's already solutions in many places, and overla= p with existing technology.=A0 The recent WWW 2012 conference has shown tha= t structured data is now incoporated in somewhere between 25% and 32% of th= e web, eg using RDFa and microdta.=A0 Do we think it's productive to pu= sh yet another data lookup format?

http://www.bbc.co.uk/blogs/researchandd= evelopment/2012/04/notes-from-the-www12-conferenc.shtml

It would= be awesome if we can main pain point, or problem statement that these spec= s can solve, find out what the easy wins are, solve those with minimum fuss= , imho.
=A0

Paul

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf3071cffa5325f004bf0bb308-- From melvincarvalho@gmail.com Wed May 2 04:14:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B09821F8AFB for ; Wed, 2 May 2012 04:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydPMG0IQgHz9 for ; Wed, 2 May 2012 04:14:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56B4C21F8AFA for ; Wed, 2 May 2012 04:14:41 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so382206vcb.31 for ; Wed, 02 May 2012 04:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KxOGxRbzsZe/ekXP3b/nnLqszYflNWLOB2+UqhuqPTo=; b=d3892uv8ac/FL1Pls6Wsg7jGfa4Ajva+K5U8bG3nvTEU/723jQFdzy/v8ykJziDchS 1PES0+OP+ezVmKuyt7KEcS0SLdInkiMWh0vP4HU2B39shPO7lN3x4VEWLye/Inh9TlrF SRwVZswABWo+hHOU96gpCl8REY9p/v7t4mhbNO/fjtkpqpendNBIgUFv0TEf8nOOCXGh jOODsEyG6p14rdVyAI4mO92g6wTfWp5dHehxZpoZ0nLEJKWXl0qmb6QvYFMdReGr8pxV ND17Rtgkg0seV5bEswmZ3p+2MMiZifsMER2jy//qxgRSjMiKdJjbOkTR6TsPZ7rH4P/j B1AQ== MIME-Version: 1.0 Received: by 10.52.37.102 with SMTP id x6mr16334160vdj.72.1335957280768; Wed, 02 May 2012 04:14:40 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Wed, 2 May 2012 04:14:40 -0700 (PDT) In-Reply-To: <4FA11490.9010400@packetizer.com> References: <4FA0F384.5050008@packetizer.com> <4FA11490.9010400@packetizer.com> Date: Wed, 2 May 2012 13:14:40 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf3079bb4627c45704bf0bcb82 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:14:42 -0000 --20cf3079bb4627c45704bf0bcb82 Content-Type: text/plain; charset=ISO-8859-1 On 2 May 2012 13:03, Paul E. Jones wrote: > On 5/2/2012 6:06 AM, Melvin Carvalho wrote: > > > > On 2 May 2012 10:42, Paul E. Jones wrote: > >> Folks, >> >> I did not see (enough) follow-up on Blaine's message regarding WebFinger. >> He raised three issues: >> >> 1) JSON vs. XML >> 2) JSON format >> 3) Direct vs. Indirect (i.e., single query response with "resource" >> parameter) >> >> I have no strong preferences to the point of derailing the project :-), >> but I would prefer: >> >> 1) The server is required to provide both XML and JSON formats, while the >> client can select what it wants >> > > -1 > > I thought issue #1 was for JSON ONLY? And only to reply if there was > anyone supporting XML. I didnt see any replies. I may have misunderstood > the whole thing tho. > > > He did call for JSON only. However, RFC 6415 and current WebFinger > servers use XML. So, I don't think we should simply disregard those > facts. Supporting both on the server side is trivial, so I don't see a > reason to not implement both. > > > I came across this video recently, entitled "Lessons of JSON" > > http://inkdroid.org/journal/2012/04/30/lessons-of-json/ > > Douglas Crockford gives some insights into the advantages of JSON over XML. > > >> 2) The JSON format should be the JRD format as described in RFC 6415 >> > > I think I was the only person to reply to this point. > > I'm curious as to why a bespoke almost unused MIME type > > application/xrd+json > > Rather than, the commonly used: > > application/json > > As per SWD > > > The media type "xrd+json" would not be right since a JRD is not XML. We > could define jrd+json, but this starts us down the path of having a > gazillion whatever+json definitions like there with +xml definitions. I'll > note that there are no standards in the IETF presently that define a > whatever+json. We would be the first and that gives me some concern. Is > application/json an issue? > > > > Is there a spec for JRD, other than Eran's blog post. What's the > licensing? > > > I noted you found this in your follow-up. It is in RFC 6415, as you noted. > > > > 3) We should make the "resource" parameter a MUST in order to allow the >> client to be implemented such that it can make a single query to get the >> information it is seeking >> >> I believe this would satisfy the requirements from the OpenID Connect >> team. #3 would mean that current WebFinger servers are "broken" until they >> either: >> 1) Provide support in the WebFinger server code for the "resource" >> parameter >> 2) Use HTTP server re-writing rules (or similar) to handle the request. >> (See http://www.packetizer.com/webfinger/server.html for an example of >> how Apache can be used to allow a static site to support the "resource" >> parameter.) >> > > What are the typical values that resource can take? > > > The resource parameter would take any valid URI. > > > > Is resource=user@host acceptable, or is a scheme required? > > > It should always have a scheme, otherwise it would have no specific > meaning. > > > > In particular re acct: > > Is the new scheme "acct" still proposed? The documentation for the > account scheme is still incomplete as of > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > > > "acct" has been proposed for a long time now and documented in the > WebFinger draft. Why do you say it is incomplete? What is missing, > exactly? > Ah apologies I had been looking at a previous version: QUESTION: Do we want to restrict the acct: URI to only be user@domain and borrow the syntax from, say, the SIP spec? Or, do we want to reference addr-spec as we have it now? I see this is no longer in the current draft. I guess this is now resolved, let me look thru the current draft in more detail. > > > Should it have its own RFC, or folded into the new joint spec? > Personally, I think documenting acct: is a bigger task than SWD itself. > > > Since I don't know what you feel is missing, it's hard to argue otherwise > :-) We could move the acct URI to a different draft, but what would be the > value? It would just require people to hunt down even more documents. > > > If, once documented and reviewed, there is a consensus is for acct: is > taken forward, should it be a new URI scheme or a URN? > > > Please note that "acct" is already implemented. I think we should leave > it as-is. > > > How does it relate to XMPP and email? Are there possible collisions? > > > This is precisely why we need "acct". One's email address is one URI > (mailto:) and one's XMPP address is another (xmpp:). The "acct" URI > refers to a user account and not their email address or XMPP address, etc. > You might query my Google+ account, for example, and discover that I have > several different email addresses and XMPP addresses, but I have one > Google+ account. > > Paul > > --20cf3079bb4627c45704bf0bcb82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 May 2012 13:03, Paul E. Jones <paulej@packetizer.com> wrote:
=20 =20 =20
On 5/2/2012 6:06 AM, Melvin Carvalho wrote:


On 2 May 2012 10:42, Paul E. Jones <p= aulej@packetizer.com> wrote:
Folks,

I did not see (enough) follow-up on Blaine's message regardin= g WebFinger. =A0He raised three issues:

1) JSON vs. XML
2) JSON format
3) Direct vs. =A0Indirect (i.e., single query response with "resource" parameter)

I have no strong preferences to the point of derailing the project :-), but I would prefer:

1) The server is required to provide both XML and JSON formats, while the client can select what it wants

-1

I thought issue #1 was for JSON ONLY?=A0 And only to reply if there was anyone supporting XML.=A0 I didnt see any replies.=A0 I may have misunderstood the whole thing tho.

He did call for JSON only.=A0 However, RFC 6415 and current WebFinger servers use XML.=A0 So, I don't think we should simply disregard th= ose facts.=A0 Supporting both on the server side is trivial, so I don't see a reason to not implement both.


I came across this video recently, entitled "Lessons of JSON"

http://inkdroid.org/journal/2012/04/30/lessons-of-json= /

Douglas Crockford gives some insights into the advantages of JSON over XML.
=A0
2) The JSON format should be the JRD format as described in RFC 6415

I think I was the only person to reply to this point.

I'm curious as to why a bespoke almost unused MIME type

application/xrd+json

Rather than, the commonly used:

application/json

As per SWD

The media type "xrd+json" would not be right since a JRD is n= ot XML.=A0 We could define jrd+json, but this starts us down the path of having a gazillion whatever+json definitions like there with +xml definitions.=A0 I'll note that there are no standards in the IETF presently that define a whatever+json.=A0 We would be the first and that gives me some concern.=A0 Is application/json an issue?



Is there a spec for JRD, other than Eran's blog post.=A0 What= 's the licensing?

I noted you found this in your follow-up. It is in RFC 6415, as you noted.

=A0
3) We should make the "resource" parameter a MUST in or= der to allow the client to be implemented such that it can make a single query to get the information it is seeking

I believe this would satisfy the requirements from the OpenID Connect team. =A0#3 would mean that current WebFinger servers are "broken" until they either:
1) Provide support in the WebFinger server code for the "resource" parameter
2) Use HTTP server re-writing rules (or similar) to handle the request. =A0(See http://www.packetizer.com/webfinger/server.ht= ml for an example of how Apache can be used to allow a static site to support the "resource" parameter.)

What are the typical values that resource can take?

The resource parameter would take any valid URI.



Is resource=3Duser@host acceptable, or is a scheme required?

It should always have a scheme, otherwise it would have no specific meaning.



In particular re acct:

Is the new scheme "acct" still proposed?=A0 The documen= tation for the account scheme is still incomplete as of h= ttp://tools.ietf.org/html/draft-jones-appsawg-webfinger-03

"acct" has been proposed for a long time now and documented i= n the WebFinger draft.=A0 Why do you say it is incomplete?=A0 What is missing= , exactly?

Ah apologies I had been looking at = a previous version:

   QUESTION: Do we want t=
o restrict the acct: URI to only be user@domain
   and borrow the syntax from, say, the SIP spec?  Or, do we want to
   reference addr-spec as we have it now?

I see this is no longer = in the current draft.=A0 I guess this is now resolved, let me look thru the= current draft in more detail.
=A0


Should it have its own RFC, or folded into the new joint spec?=A0 Personally, I think documenting acct: is a bigger task than SWD itself.

Since I don't know what you feel is missing, it's hard to argue otherwise :-)=A0 We could move the acct URI to a different draft, but what would be the value?=A0 It would just require people to hunt down even more documents.


If, once documented and reviewed, there is a consensus is for acct: is taken forward, should it be a new URI scheme or a URN?

Please note that "acct" is already implemented.=A0 I think we= should leave it as-is.


How does it relate to XMPP and email?=A0 Are there possible collisions?

This is precisely why we need "acct".=A0 One's email addr= ess is one URI (mailto:) and one's XMPP address is another (xmpp:).=A0 The &qu= ot;acct" URI refers to a user account and not their email address or XMPP address, etc.=A0 You might query my Google+ account, for example, and discover that I have several different email addresses and XMPP addresses, but I have one Google+ account.

Paul


--20cf3079bb4627c45704bf0bcb82-- From melvincarvalho@gmail.com Wed May 2 04:18:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2421F8A49 for ; Wed, 2 May 2012 04:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9M2wXwjorOt for ; Wed, 2 May 2012 04:18:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1957D21F89EB for ; Wed, 2 May 2012 04:18:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so383238vbb.31 for ; Wed, 02 May 2012 04:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IQwVPO2AHbLnwu+DrVueYT7aj+oTyxMM2AgvNgPXF0k=; b=lU04unL30Nz8sUPS2+VT4wh29Eek1nqJsc+uCE6TV1r3M+DtU/ICULipuievIZXKA6 6ChI3p5vTEtOVoYN+RAeMZzlfDNSDZNR2Rvpzfg2r7MuNxT7Y/ueoWCaPV3U+G7E9Wwg gOqE/OebCMxEvQaAm7gxpBsK+jgxoxfraeOQg67dVEkDRywHzVQNghNMsMlDmErj9mvf LLpZSEskqGOIQwi4His+iTgXqaL5q/8Lb3/Jc+XktYRbInbQLzid0tlHtnvdRv4Py9Fx OebJrujs+PdRqMx7k+8XJz5bTBe9lrZlGzo1/XX4QRFwmDUFa6KGe5gR0WUE6/Y8dESg /DGQ== MIME-Version: 1.0 Received: by 10.52.37.102 with SMTP id x6mr16343013vdj.72.1335957501817; Wed, 02 May 2012 04:18:21 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Wed, 2 May 2012 04:18:21 -0700 (PDT) In-Reply-To: <4FA11490.9010400@packetizer.com> References: <4FA0F384.5050008@packetizer.com> <4FA11490.9010400@packetizer.com> Date: Wed, 2 May 2012 13:18:21 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf3079bb4654b19604bf0bd860 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:18:24 -0000 --20cf3079bb4654b19604bf0bd860 Content-Type: text/plain; charset=ISO-8859-1 On 2 May 2012 13:03, Paul E. Jones wrote: > On 5/2/2012 6:06 AM, Melvin Carvalho wrote: > > > > On 2 May 2012 10:42, Paul E. Jones wrote: > >> Folks, >> >> I did not see (enough) follow-up on Blaine's message regarding WebFinger. >> He raised three issues: >> >> 1) JSON vs. XML >> 2) JSON format >> 3) Direct vs. Indirect (i.e., single query response with "resource" >> parameter) >> >> I have no strong preferences to the point of derailing the project :-), >> but I would prefer: >> >> 1) The server is required to provide both XML and JSON formats, while the >> client can select what it wants >> > > -1 > > I thought issue #1 was for JSON ONLY? And only to reply if there was > anyone supporting XML. I didnt see any replies. I may have misunderstood > the whole thing tho. > > > He did call for JSON only. However, RFC 6415 and current WebFinger > servers use XML. So, I don't think we should simply disregard those > facts. Supporting both on the server side is trivial, so I don't see a > reason to not implement both. > > > I came across this video recently, entitled "Lessons of JSON" > > http://inkdroid.org/journal/2012/04/30/lessons-of-json/ > > Douglas Crockford gives some insights into the advantages of JSON over XML. > > >> 2) The JSON format should be the JRD format as described in RFC 6415 >> > > I think I was the only person to reply to this point. > > I'm curious as to why a bespoke almost unused MIME type > > application/xrd+json > > Rather than, the commonly used: > > application/json > > As per SWD > > > The media type "xrd+json" would not be right since a JRD is not XML. We > could define jrd+json, but this starts us down the path of having a > gazillion whatever+json definitions like there with +xml definitions. I'll > note that there are no standards in the IETF presently that define a > whatever+json. We would be the first and that gives me some concern. Is > application/json an issue? > > > > Is there a spec for JRD, other than Eran's blog post. What's the > licensing? > > > I noted you found this in your follow-up. It is in RFC 6415, as you noted. > > > > 3) We should make the "resource" parameter a MUST in order to allow the >> client to be implemented such that it can make a single query to get the >> information it is seeking >> >> I believe this would satisfy the requirements from the OpenID Connect >> team. #3 would mean that current WebFinger servers are "broken" until they >> either: >> 1) Provide support in the WebFinger server code for the "resource" >> parameter >> 2) Use HTTP server re-writing rules (or similar) to handle the request. >> (See http://www.packetizer.com/webfinger/server.html for an example of >> how Apache can be used to allow a static site to support the "resource" >> parameter.) >> > > What are the typical values that resource can take? > > > The resource parameter would take any valid URI. > > > > Is resource=user@host acceptable, or is a scheme required? > > > It should always have a scheme, otherwise it would have no specific > meaning. > > > > In particular re acct: > > Is the new scheme "acct" still proposed? The documentation for the > account scheme is still incomplete as of > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 > > > "acct" has been proposed for a long time now and documented in the > WebFinger draft. Why do you say it is incomplete? What is missing, > exactly? > > > Should it have its own RFC, or folded into the new joint spec? > Personally, I think documenting acct: is a bigger task than SWD itself. > > > Since I don't know what you feel is missing, it's hard to argue otherwise > :-) We could move the acct URI to a different draft, but what would be the > value? It would just require people to hunt down even more documents. > > > If, once documented and reviewed, there is a consensus is for acct: is > taken forward, should it be a new URI scheme or a URN? > > > Please note that "acct" is already implemented. I think we should leave > it as-is. > > > How does it relate to XMPP and email? Are there possible collisions? > > > This is precisely why we need "acct". One's email address is one URI > (mailto:) and one's XMPP address is another (xmpp:). The "acct" URI > refers to a user account and not their email address or XMPP address, etc. > You might query my Google+ account, for example, and discover that I have > several different email addresses and XMPP addresses, but I have one > Google+ account. > Thanks for the response, makes a lot of sense. > Paul > > --20cf3079bb4654b19604bf0bd860 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 May 2012 13:03, Paul E. Jones <paulej@packetizer.com> wrote:
=20 =20 =20
On 5/2/2012 6:06 AM, Melvin Carvalho wrote:


On 2 May 2012 10:42, Paul E. Jones <p= aulej@packetizer.com> wrote:
Folks,

I did not see (enough) follow-up on Blaine's message regardin= g WebFinger. =A0He raised three issues:

1) JSON vs. XML
2) JSON format
3) Direct vs. =A0Indirect (i.e., single query response with "resource" parameter)

I have no strong preferences to the point of derailing the project :-), but I would prefer:

1) The server is required to provide both XML and JSON formats, while the client can select what it wants

-1

I thought issue #1 was for JSON ONLY?=A0 And only to reply if there was anyone supporting XML.=A0 I didnt see any replies.=A0 I may have misunderstood the whole thing tho.

He did call for JSON only.=A0 However, RFC 6415 and current WebFinger servers use XML.=A0 So, I don't think we should simply disregard th= ose facts.=A0 Supporting both on the server side is trivial, so I don't see a reason to not implement both.


I came across this video recently, entitled "Lessons of JSON"

http://inkdroid.org/journal/2012/04/30/lessons-of-json= /

Douglas Crockford gives some insights into the advantages of JSON over XML.
=A0
2) The JSON format should be the JRD format as described in RFC 6415

I think I was the only person to reply to this point.

I'm curious as to why a bespoke almost unused MIME type

application/xrd+json

Rather than, the commonly used:

application/json

As per SWD

The media type "xrd+json" would not be right since a JRD is n= ot XML.=A0 We could define jrd+json, but this starts us down the path of having a gazillion whatever+json definitions like there with +xml definitions.=A0 I'll note that there are no standards in the IETF presently that define a whatever+json.=A0 We would be the first and that gives me some concern.=A0 Is application/json an issue?



Is there a spec for JRD, other than Eran's blog post.=A0 What= 's the licensing?

I noted you found this in your follow-up. It is in RFC 6415, as you noted.

=A0
3) We should make the "resource" parameter a MUST in or= der to allow the client to be implemented such that it can make a single query to get the information it is seeking

I believe this would satisfy the requirements from the OpenID Connect team. =A0#3 would mean that current WebFinger servers are "broken" until they either:
1) Provide support in the WebFinger server code for the "resource" parameter
2) Use HTTP server re-writing rules (or similar) to handle the request. =A0(See http://www.packetizer.com/webfinger/server.ht= ml for an example of how Apache can be used to allow a static site to support the "resource" parameter.)

What are the typical values that resource can take?

The resource parameter would take any valid URI.



Is resource=3Duser@host acceptable, or is a scheme required?

It should always have a scheme, otherwise it would have no specific meaning.



In particular re acct:

Is the new scheme "acct" still proposed?=A0 The documen= tation for the account scheme is still incomplete as of h= ttp://tools.ietf.org/html/draft-jones-appsawg-webfinger-03

"acct" has been proposed for a long time now and documented i= n the WebFinger draft.=A0 Why do you say it is incomplete?=A0 What is missing= , exactly?


Should it have its own RFC, or folded into the new joint spec?=A0 Personally, I think documenting acct: is a bigger task than SWD itself.

Since I don't know what you feel is missing, it's hard to argue otherwise :-)=A0 We could move the acct URI to a different draft, but what would be the value?=A0 It would just require people to hunt down even more documents.


If, once documented and reviewed, there is a consensus is for acct: is taken forward, should it be a new URI scheme or a URN?

Please note that "acct" is already implemented.=A0 I think we= should leave it as-is.


How does it relate to XMPP and email?=A0 Are there possible collisions?

This is precisely why we need "acct".=A0 One's email addr= ess is one URI (mailto:) and one's XMPP address is another (xmpp:).=A0 The &qu= ot;acct" URI refers to a user account and not their email address or XMPP address, etc.=A0 You might query my Google+ account, for example, and discover that I have several different email addresses and XMPP addresses, but I have one Google+ account.

Thanks for = the response, makes a lot of sense.


Paul


--20cf3079bb4654b19604bf0bd860-- From paulej@packetizer.com Wed May 2 04:36:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A1C21F8992 for ; Wed, 2 May 2012 04:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJupSftnrzQX for ; Wed, 2 May 2012 04:36:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55F21F898F for ; Wed, 2 May 2012 04:36:42 -0700 (PDT) Received: from [156.106.218.62] ([156.106.218.62]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q42BaeCO005780 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 May 2012 07:36:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1335958601; bh=xRswRCLaxdmcpc2ssJxh5biq2W/0XYT0SjHi/qbhLEo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=McfuZsHrBMUS30rsHtyWxcGDrgwQrYKuJfevV1qAzjDjCQRjp03Qy00yPijiUS02H 9OP0wxEEzRxH4Yyhq/9CNKc06DB7+FyH1rNu7veQxkaG7p3Qn/iLsrvdl3qmPY8KOb fSc0VOchwZ1GMZmbwZTFwv1rgzkkT4MfNyGvhM9c= Message-ID: <4FA11C4B.2000202@packetizer.com> Date: Wed, 02 May 2012 07:36:43 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melvin Carvalho References: <4FA0F384.5050008@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 11:36:43 -0000 On 5/2/2012 7:08 AM, Melvin Carvalho wrote: > One thing that would be a kind of joint problem statement, of the main > thing that's trying to be solved. Is this not understood? Keep in mind that this was not fabricated last week. I've been personally interacting with people working on WebFinger for a couple of years (or more) now. The idea is all about discovery. Given a URI, what can you learn about it? This resulted in the creation of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along the way. Definitely, the web linking document (RFC 5988) is also an important part of this. > I think this started out as a way for webmail providers to give > auxiliary "follow your nose" style data linkage, using the "well > known" pattern. I don't know where it all started, but I got my start with OpenID. I did not like entering https://openid.packetizer.com/paulej whenever I wanted to log in. Rather, I wanted to enter paulej@packetizer.com. I was referred by folks on the OpenID list to go look at WebFinger. And, here we are. > It's sort of morphed a bit into a few different things, such as a > generic discovery method for the net, a new uri scheme, an account > identity system for the net, serialization formats. I don't think it has morphed. These were things that needed to be defined to realize the vision. > All these things *can* be important, but there's already solutions in > many places, and overlap with existing technology. The recent WWW > 2012 conference has shown that structured data is now incoporated in > somewhere between 25% and 32% of the web, eg using RDFa and microdta. > Do we think it's productive to push yet another data lookup format? > > http://www.bbc.co.uk/blogs/researchanddevelopment/2012/04/notes-from-the-www12-conferenc.shtml > > It would be awesome if we can main pain point, or problem statement > that these specs can solve, find out what the easy wins are, solve > those with minimum fuss, imho. I'd argue there is nothing else in existence that can do what WebFinger does, modulo the competing SWD draft. That said, I think there is agreement to move forward with WebFinger to provide a single solution. Are you arguing for a different data format? I think it's worth highlighting the simplicity and beauty of the XRD/JRD representations. These formats primarily include a set of link relations. The link relations are the same syntax and possible values as one might use in the "Link" header in HTTP and tags in HTML. So, WebFinger ties in very nicely with the Web. Paul From mrex@sap.com Wed May 2 06:47:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5721F85D8; Wed, 2 May 2012 06:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIGaFtyU8YAQ; Wed, 2 May 2012 06:47:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0F21F85D7; Wed, 2 May 2012 06:47:43 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q42Dldqi011053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 15:47:40 +0200 (MEST) From: Martin Rex Message-Id: <201205021347.q42Dld6J017934@fs4113.wdf.sap.corp> To: ned.freed@mrochek.com (Ned Freed) Date: Wed, 2 May 2012 15:47:39 +0200 (MEST) In-Reply-To: <01OEZB9OC9VW0006TF@mauve.mrochek.com> from "Ned Freed" at May 1, 12 07:55:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 13:47:44 -0000 Ned Freed wrote: > > > I don't think is there a definite need e.g. for something that > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > that might or might not be needed but we won't know until its > > being done. > > But that's what it currently says is needed. > > > Nevertheless, how about if it said: > > > "Note that this document does not cover how to associate > > certificates with domain names for application protocols that depend > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > future documents will cover methods for making those associations. > > Those documents may or may not need to update this one." > > That's essentially the change I suggested making. Writing that those apps-protocol-specific documents (defining how to use a particular protocol with TLSA/DANE-protocol) might need to update the TLSA/DANE-protocol document is misleading (and IMHO should be avoided). http://tools.ietf.org/html/rfc2223#section-12 defines the "Updates:" metadata for RFCs to have a very narrow and purely editorial meaning. "Updates:" is meant to refer to those situations where a paragraph or section of a new document **completely** replaces the same paragraph or section of a previous RFC. It is probably much more common to "extend" an existing protocol or describe/define additional usage scenarios without changing the original specification, simply by using the extensibility of the original protocol. Normally, such "expected usage" should not use the editorial rfc2223-Updates: metadata. But the use of the Updates:&Obsoletes: meta-data tags in RFCs is not consistent, a number of RFC seem to ignore the rfc2223 definitions of what these headers are supposed to indicate. -Martin From mrex@sap.com Wed May 2 06:59:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0382121F85F2; Wed, 2 May 2012 06:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.127 X-Spam-Level: X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTEI5JflTUnx; Wed, 2 May 2012 06:59:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 41CB921F85E5; Wed, 2 May 2012 06:59:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q42DxXmp025332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 15:59:33 +0200 (MEST) From: Martin Rex Message-Id: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> To: marka@isc.org (Mark Andrews) Date: Wed, 2 May 2012 15:59:31 +0200 (MEST) In-Reply-To: <20120502033808.DC27A205548E@drugs.dv.isc.org> from "Mark Andrews" at May 2, 12 01:38:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 13:59:37 -0000 Mark Andrews wrote: > > Tony Finch writes: >> >> Ned Freed wrote: >>> >>> But even this may not be acceptable for all I know. It may turn out >>> that using DANE to secure the terminal A/AAAA records (modulo CNAMEs) >>> is actually an acceptable default for SRV/MX/NATPR-based services. >>> I could easily be wrong, but it seems to me that this is what all >>> this additional discussion is about. >> >> I don't think it's as simple as that because RFC 6125 says certificates >> should match the SRV owner name not the target name. See also Dave >> Cridland's comments about XMPP. > > Should != must. I think that is a misunderstanding. The XMPP document may explicitly account for a local policy to override the decision to continue communication because of a mismatch and chose "should" over "must" for that, assuming that MUST is unconditional and not subject to local policy. Some specifications in the security area (and PKIX in particular) use a different approach, using MUST all over the place, silently assuming that local policy overrides MUSTS in specs all the time... (and some of the language in DANE-protocol is the same, generously sprinkling MUST all over the place, and causing confusion about when a MUST is really a MUST (i.e. not subject to local policy). Personally, I prefer shoulds to musts for situations where local policy is supposed to apply. -Martin From marka@isc.org Wed May 2 07:12:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4783821F85D3; Wed, 2 May 2012 07:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHziZPcpsFf8; Wed, 2 May 2012 07:12:58 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id A60FC21F85AF; Wed, 2 May 2012 07:12:58 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 482B45F98E1; Wed, 2 May 2012 14:12:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:44e0:7e51:4c1e:891f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 61E35216C33; Wed, 2 May 2012 14:12:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5BFB4205A95B; Thu, 3 May 2012 00:12:35 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> In-reply-to: Your message of "Wed, 02 May 2012 15:59:31 +0200." <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> Date: Thu, 03 May 2012 00:12:35 +1000 Message-Id: <20120502141235.5BFB4205A95B@drugs.dv.isc.org> Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 14:12:59 -0000 In message <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp>, Martin Rex writes: > Mark Andrews wrote: > > > > Tony Finch writes: > >> > >> Ned Freed wrote: > >>> > >>> But even this may not be acceptable for all I know. It may turn out > >>> that using DANE to secure the terminal A/AAAA records (modulo CNAMEs) > >>> is actually an acceptable default for SRV/MX/NATPR-based services. > >>> I could easily be wrong, but it seems to me that this is what all > >>> this additional discussion is about. > >> > >> I don't think it's as simple as that because RFC 6125 says certificates > >> should match the SRV owner name not the target name. See also Dave > >> Cridland's comments about XMPP. > > > > Should != must. > > I think that is a misunderstanding. > > The XMPP document may explicitly account for a local policy to override > the decision to continue communication because of a mismatch and chose > "should" over "must" for that, assuming that MUST is unconditional > and not subject to local policy. > > Some specifications in the security area (and PKIX in particular) > use a different approach, using MUST all over the place, silently > assuming that local policy overrides MUSTS in specs all the time... > (and some of the language in DANE-protocol is the same, generously > sprinkling MUST all over the place, and causing confusion about > when a MUST is really a MUST (i.e. not subject to local policy). > > Personally, I prefer shoulds to musts for situations where local > policy is supposed to apply. > > -Martin This isn't a local policy issue. It's a appropriate fit for the protocol issue. Most protocols where you will be using SRV you can use the owner of the SRV record but there are some where it does not make sense. By forcing the security model to be too rigid you stop SRV being used in ways it was designed to be used. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Wed May 2 07:13:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F266B21F85DF; Wed, 2 May 2012 07:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDwge56nM2D2; Wed, 2 May 2012 07:13:48 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1594721F85D3; Wed, 2 May 2012 07:13:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39794) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SPaJM-000634-Ea (Exim 4.72) (return-path ); Wed, 02 May 2012 15:13:44 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPaJM-0000O6-Ax (Exim 4.67) (return-path ); Wed, 02 May 2012 15:13:44 +0100 Date: Wed, 2 May 2012 15:13:44 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> Message-ID: References: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, Mark Andrews , dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 14:13:49 -0000 Martin Rex wrote: > Mark Andrews wrote: > > > > Should != must. > > I think that is a misunderstanding. No, I think Mark is right. RFC 6125 is guidance for protocol designers, so the "should" is a recommendation about how to decide which identity is authenticated when adding TLS to a protocol. Whether local policy can override this decision is something else entirely. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Northwesterly 4 or 5, increasing 6 in north. Slight or moderate. Fair. Moderate or good. From marka@isc.org Tue May 1 20:38:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3951921E802C; Tue, 1 May 2012 20:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-a+nTkQPyT0; Tue, 1 May 2012 20:38:32 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id A507B21E8013; Tue, 1 May 2012 20:38:32 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B51AC5F990B; Wed, 2 May 2012 03:38:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:a15a:151c:b5dd:907]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 17FE0216C36; Wed, 2 May 2012 03:38:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id DC27A205548E; Wed, 2 May 2012 13:38:08 +1000 (EST) To: Tony Finch From: Mark Andrews References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> In-reply-to: Your message of "Tue, 01 May 2012 12:22:21 +0100." Date: Wed, 02 May 2012 13:38:08 +1000 Message-Id: <20120502033808.DC27A205548E@drugs.dv.isc.org> X-Mailman-Approved-At: Wed, 02 May 2012 08:03:08 -0700 Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 03:38:33 -0000 In message , Tony F inch writes: > Ned Freed wrote: > > > > But even this may not be acceptable for all I know. It may turn out that us > ing > > DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an > > acceptable default for SRV/MX/NATPR-based services. I could easily be wrong > , > > but it seems to me that this is what all this additional discussion is abou > t. > > I don't think it's as simple as that because RFC 6125 says certificates > should match the SRV owner name not the target name. See also Dave > Cridland's comments about XMPP. Should != must. None of the examples in RFC 6125 deal with a store and forward protocol that uses trusted third parties. SMTP is a example of such a protocol and if implements using SRV rather than MX it would be a exception. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Tue May 1 12:26:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F08421E80C5; Tue, 1 May 2012 12:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7XgCoUNGYwP; Tue, 1 May 2012 12:26:08 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB9A21E8084; Tue, 1 May 2012 12:26:08 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 596031B40057; Tue, 1 May 2012 15:26:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> Date: Tue, 1 May 2012 15:26:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 02 May 2012 08:03:32 -0700 Cc: Warren Kumari , apps-discuss@ietf.org, dane list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 19:26:09 -0000 [ -IESG] On May 1, 2012, at 3:18 PM, Paul Hoffman wrote: > On May 1, 2012, at 11:56 AM, Peter Saint-Andre wrote: >=20 >> On 5/1/12 11:02 AM, Tony Finch wrote: >>> Peter Saint-Andre wrote: >>>>=20 >>>> The change from "client-chosen port" to "client-define port" is >>>> mystifying to me. Even assuming that "client-defined" was meant, = it's >>>> not clear to me what a client-defined port is, and I see no = effective >>>> difference between the old text and the new text. >>>=20 >>> I think the mistake is to talk about the client here. The client = begins a >>> connection to the service's port at that IP address. >>=20 >> Usually, yes. Sometimes the client is configured to override the = default >> port for the given service, as Paul noted. >>=20 >> Could we just say "It then begins a connection to a particular port = at >> that address"? Perhaps the method for determining the port isn't = really >> relevant in this spec. >=20 > Works for me. What do others think? >=20 > Current: > It then begins a connection to a client-defined port at that address, = and sends an initial message there. > Proposed: > It then begins a connection to a particular port at that address, and = sends an initial message there. LGTM. W >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From sm@resistor.net Wed May 2 08:35:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64221E8020 for ; Wed, 2 May 2012 08:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZySf2-W44UzH for ; Wed, 2 May 2012 08:35:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CDC21E801E for ; Wed, 2 May 2012 08:35:02 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q42FYt7m019652 for ; Wed, 2 May 2012 08:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335972900; i=@resistor.net; bh=ZhS1b+cLyIAvb2fUA8/pPMF5LnzbYaej06B7PtsKoHM=; h=Date:To:From:Subject:Cc; b=Jd3e+MJ6d7A0opksN+HsueDQzL7fOJIIl5XfspBqEasdDTSzKsYavN9t1hDS56TbJ GnNhQIki3t3T5Qlgiqo+BFrygOyu9xPQHhUihsFSF4m/0643JfIwTB9bytJPuRCOzh sEXtBJouE29hm00QIe1uUe6kScp31dcGCBratM5c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335972900; i=@resistor.net; bh=ZhS1b+cLyIAvb2fUA8/pPMF5LnzbYaej06B7PtsKoHM=; h=Date:To:From:Subject:Cc; b=iyKCV8NEm0aFFuBa3vHQO6v0j1+xfYN6ZqfJr88owR2m2WL7yNOR01bDKXMbbWrFM r2Pp/FGGpEIG6TfrV61Qru7Qy+9DeTKYXVnt68Cor9bTnbQo+LvknmgTwZRrf9kYa5 71f+6ai9pcPBF5ZWtUupJPLbA1KoLRtw86184rtY= Message-Id: <6.2.5.6.2.20120502074325.0ababa28@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 02 May 2012 08:25:05 -0700 To: apps-discuss@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:35:03 -0000 Hello, I have a few comments on draft-ietf-appsawg-http-forwarded-02. I am ignoring the non-privacy angle for now. In Section 5.5: "IANA MUST in such cases be notified, and parameters should be registered according to [RFC3864]." Isn't the "MUST" a little too much? Section 8.2 discusses about "Information leak". There is a lack of discussion about privacy considerations. Is the information provided by this header field considered as personal identifiable information? Is the leakage only about revealing NAT information and proxy setup? Is this header field only used by internal nodes? Regards, -sm From ben@niven-jenkins.co.uk Wed May 2 08:59:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B871411E8085 for ; Wed, 2 May 2012 08:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8kw0OGzcgZt for ; Wed, 2 May 2012 08:59:19 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id A275021F8593 for ; Wed, 2 May 2012 08:59:18 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SPbws-0000Tp-8x; Wed, 02 May 2012 16:58:38 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4FA02AEA.1080407@isode.com> Date: Wed, 2 May 2012 16:59:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <29236FD5-51E7-4AC5-88EA-6B956E453D8A@niven-jenkins.co.uk> References: <4FA02AEA.1080407@isode.com> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: John Sullivan Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:59:19 -0000 Colleagues, I'm forwarding the following comments on = draft-ietf-appsawg-http-forwarded-02 on behalf of John (cc'd) who is our = resident HTTP expert but doesn't subscribe to the apps-discuss list. Thanks Ben =3D=3D=3D Start of John's comments: 0. First, I approve of the proposal in general: it is a big improvement over the current situation with multiple non-standardised headers partially/incompletely implemented by different software. 1. The ABNF gives: forwarded-pair =3D token "=3D" ( token / quoted-string ) token =3D 1*( /[-!#$%&'*+.^_`|~0-9A-Z]/ ) # httpbis-p1 S3.2.4 It is a happy coincidence that an IPv4address without an optional port happens to fall within the token syntax and therefore does not need to be a quoted-string, but neither an IPv4address with the optional port (which involves ":" which is not in tchar) or an IPv6address with or without port (which involve "[", "]" and ":" none of which are in tchar) are valid tokens and MUST be sent as quoted-string. What might casually seem to some to be the same syntax element therefore has different quoting/escaping rules depending on its exact makeup. Generators need to beware. Some might take the view that it is safest and easiest to simply use quoted-string in all cases, so consumers also need to beware that even an IPv4address with no port might be sent as a quoted-string. I think this should be explicitly called out, given this draft gets it wrong itself (see below). 2. The example in S4 is both wrong and odd. Forwarded: For=3D192.0.2.43,"for=3D[2001:db8:cafe::17]:47011" Forwarded: proto=3Dhttps;by=3D198.51.100.60 By #rule this expands to a 3-element list For=3D192.0.2.43 "for=3D[2001:db8:cafe::17]:47011" proto=3Dhttps;by=3D198.51.100.60 The second element does not match the ABNF: the first quote should be after the "=3D". The third element, while valid, looks like it might have been intended to be a run-on of the second thus creating a 2-element list where the second element has 3 parameters. (It's not clear how a client send an IPv6 request to an IPv4 endpoint though!) If this is deliberate then fine, but it perhaps makes for a confusing example. 3. S5.1 ("by" parameter) says: This is primarily added by reverse proxies that wish to forward this information to the backend server. I would add that this is especially useful for multi-homed proxies where the address that the backend server sees the forwarded request coming from is not the same as the address the proxy received the request on. (Where the two addresses are the same it seems superfluous.) 4. S5.2 ("for" parameter) says: The last proxy's IP address, and optionally a port number, are, however, readily available as the remote IP address of the TCP/IP connection. As above, the inbound address is not necessarily the same as the outbound address of the proxy. The "by" parameter where present might be a more valuable source of the "proxy's IP address". 5. S6.1 (address identifiers) says: The IPv6address SHOULD comply with textual representation recommendations [RFC5952] (e.g., lowercase, zero compression). But RFC 5952 defines a standard mechanism for generating the shortest (most compressed) textual representation of an IPv6 literal. 6. S7 says: As an example, the header field Forwarded: for=3D192.0.2.43,for=3D[2001:db8:cafe::17],for=3Dunknown= This is not valid syntax. The IPv6address contains non-tchars and must be transmitted as a quoted-string. 7. S7 also says: Note that this header field is relevant on a per request basis and MUST NOT be cached. It's not entirely clear where this comes from. Request headers are not normally cached, unless the origin invokes the Vary mechanism. Is it intended that this should disable the ability of an origin to say "Vary: Forwarded"? I can't see why this needs to be done (and in any case won't work with intermediates unaware of this specification.) Also note that this header field MUST NOT be preserved across redirects. This seems to presume an intermediate which follows redirects = internally, preserving the original request state for each sub-request, and presents the final target as a response to the original incoming request. This seems to be an inadvisable thing to do in any case. (I had a vague idea it was prohibited, but can't find specific language in httpbis that provides guidance in either direction - apart from perhaps the p1-S3.1.1 direction to issue 301 responses to invalid request-lines rather than transparently fixing them. That seems closely related.) Instead, it might be worth noting when the incoming Forwarded header should be preserved or discarded: * Obviously a directly forwarded request should preserve/extend it. * If a single incoming request causes an intermediate to make multiple related inbound requests, then presumably one is a more direct analog of the original request and should preserve/extend the header, whereas the others are "internal" and should filter it out. * Unless of course the intermediate has detected a content mismatch in a 304 response and is following the httpbis-p4 S4.1 instructions to repeat the request unconditionally, in which case the new request is still basically a direct consequence of the origin request and the header should probably be kept. 8. Because Via is well established and mandatory and this is new and optional, consumers should also beware that the elements of Via may not match the elements of Forwarded: so although proto=3D may be present one will probably not be able to infer the corresponding HTTP version number, or the software version taken from Via of a particular intermediate identified within Forwarded. This remaining mismatch of capabilities (which within the X-Forwarded-* family this specification is intended to address) is perhaps unfortunate. =3D=3D=3D End of John's comments On 1 May 2012, at 19:26, Alexey Melnikov wrote: > Dear WG participants, > I would like to initiate WG Last Call on = draft-ietf-appsawg-http-forwarded-02.txt ("Forwarded HTTP Extension"). = Please send your reviews, as well as expressions of support regarding = document readiness for IESG (or not) either to the mailing list, or = directly to WG chairs (Murray Kucherawy and myself). = Comments like "I've read the document and it is Ok to publish" or "I've = read the document and it has the following issues" are useful and would = be gratefully accepted by chairs. >=20 > The WGLC will end on Friday, May 18th. >=20 > Thank you, > Alexey as an APPSAWG co-chair. >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ben@niven-jenkins.co.uk Wed May 2 09:24:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638E421F861F for ; Wed, 2 May 2012 09:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn9tJbSUhPqr for ; Wed, 2 May 2012 09:24:07 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id C204921F8617 for ; Wed, 2 May 2012 09:24:07 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SPcLN-00005f-Ah; Wed, 02 May 2012 17:23:57 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Wed, 2 May 2012 17:23:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> References: To: Ted Hardie X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-ietf-alto-protocol.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 16:24:08 -0000 Ted, On 26 Apr 2012, at 22:40, Ted Hardie wrote: > In section 7.2.2, the document says: >=20 > "Note that it is possible for an ALTO Server to employ caching for = the > response to a POST request. This can be accomplished by returning = an > HTTP 303 status code ("See Other") indicating to the ALTO Client = that > the resulting Cost Map is available via a GET request to an = alternate > URL (which may be cached)." >=20 > The phrase "employ caching" is ambiguous here, as the results of the > initial POST are not cacheable even in the case of a 303; only > the results of the later GET request are cachable. I do not believe that this is the case, from Section 6.5 of = draft-ietf-httpbis-p2-semantics-19 (RFC2616 has similar text to the = first paragraph): Responses to POST requests are only cacheable when they include explicit freshness information (see Section 2.3.1 of [Part6]). A cached POST response with a Content-Location header field (see Section 6.7 of [Part3]) whose value is the effective Request URI MAY be used to satisfy subsequent GET and HEAD requests. Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. Ben > Since cachability > is a major reason cited for the re-use of HTTP, some additional text > on the use cache control directives ("public" and "Max-age" seem > particularly important in this context) might also be useful. From ned.freed@mrochek.com Wed May 2 09:27:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D2C21F8637; Wed, 2 May 2012 09:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvxOYpTQCjSo; Wed, 2 May 2012 09:27:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB4121F85F9; Wed, 2 May 2012 09:27:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF03JXNYZK000RFH@mauve.mrochek.com>; Wed, 2 May 2012 09:27:47 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF030DGDDC0006TG@mauve.mrochek.com>; Wed, 2 May 2012 09:27:45 -0700 (PDT) Message-id: <01OF03JVQP0C0006TG@mauve.mrochek.com> Date: Wed, 02 May 2012 09:13:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 02 May 2012 15:47:39 +0200 (MEST)" <201205021347.q42Dld6J017934@fs4113.wdf.sap.corp> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OEZB9OC9VW0006TF@mauve.mrochek.com> <201205021347.q42Dld6J017934@fs4113.wdf.sap.corp> To: Martin Rex Cc: ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 16:27:53 -0000 > Ned Freed wrote: > > > > > I don't think is there a definite need e.g. for something that > > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > > that might or might not be needed but we won't know until its > > > being done. > > > > But that's what it currently says is needed. > > > > > Nevertheless, how about if it said: > > > > > "Note that this document does not cover how to associate > > > certificates with domain names for application protocols that depend > > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > > future documents will cover methods for making those associations. > > > Those documents may or may not need to update this one." > > > > That's essentially the change I suggested making. > Writing that those apps-protocol-specific documents (defining how to > use a particular protocol with TLSA/DANE-protocol) might need to update the > TLSA/DANE-protocol document is misleading (and IMHO should be avoided). > http://tools.ietf.org/html/rfc2223#section-12 > defines the "Updates:" metadata for RFCs to have a very narrow and purely > editorial meaning. "Updates:" is meant to refer to those situations > where a paragraph or section of a new document **completely** replaces > the same paragraph or section of a previous RFC. That section doesn't say or even imply that the change has to be purely editorial in nature. (The word "editorial" appears nowhere in the section and neither do the words "paragraph" or "section".) And even if it did, the facts are that Updates: is routinely used by documents that make a substantial technical change to a previous document. A particularly relevant example of this is the EAI specification RFC 6532, which states that it "Updates: RFC 2045" and the nature of this update is to remove a MUST NOT, which is just about as substantial a technical change as you can make. So if there's a bug here (and I don't think there is), the bug is in RFC 2223. Not in this use of Updates:. > It is probably much more common to "extend" an existing protocol or > describe/define additional usage scenarios without changing the original > specification, simply by using the extensibility of the original protocol. Sure, but it is also common to make a technical change and call it an update. You may not like that, but that's how it works. > Normally, such "expected usage" should not use the editorial > rfc2223-Updates: metadata. But the use of the Updates:&Obsoletes: > meta-data tags in RFCs is not consistent, a number of RFC seem to > ignore the rfc2223 definitions of what these headers are supposed > to indicate. Again, if there's any inconsistency, it's in RFC 2223. Ned From ted.ietf@gmail.com Wed May 2 09:28:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8E21F8609 for ; Wed, 2 May 2012 09:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMZYd-zr+qhj for ; Wed, 2 May 2012 09:28:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BACD21F85F9 for ; Wed, 2 May 2012 09:28:50 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so717044vcb.31 for ; Wed, 02 May 2012 09:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TTOHctkNMR0ZrKxYuSHpWtkj1k9++lI5PVanwKsy19M=; b=GA0x4Qie184b/EMZJJ6k9QQOBjDWzOfzj9nKzoBRsolFeIexHnjiYWLAIw7REQjNv+ 1zbsccOaqgS88iPdyRLImU1f7TeG5MVqVNmxejFviHlV6TAjLSmb8bGKgTgO+P99cZF4 wnbAj7/Nda7Q5YJPbBTc/lEuFLf2kLOePFc7wwSPztIzPXdK2P5Sr4jqHoeh4nN7N/jl jxzDyBEzoiOdFXwqIhGJnvyHxToImzDOPYphEczP+lmV5WNZ/7btYeU7cerf5Fi7b99X kshyIdbst3O6rq1ioeWLOoiWrHYv+r4x3qdb3jajeCQuL1boTjnr5HsqG25LjUhLyuaX xCqA== MIME-Version: 1.0 Received: by 10.52.38.167 with SMTP id h7mr21805655vdk.109.1335976129817; Wed, 02 May 2012 09:28:49 -0700 (PDT) Received: by 10.52.162.99 with HTTP; Wed, 2 May 2012 09:28:49 -0700 (PDT) In-Reply-To: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> Date: Wed, 2 May 2012 09:28:49 -0700 Message-ID: From: Ted Hardie To: Ben Niven-Jenkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-alto-protocol.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 16:28:50 -0000 On Wed, May 2, 2012 at 9:23 AM, Ben Niven-Jenkins wrote: > Ted, > I do not believe that this is the case, from Section 6.5 of draft-ietf-ht= tpbis-p2-semantics-19 (RFC2616 has similar text to the first paragraph): > > =A0 Responses to POST requests are only cacheable when they include > =A0 explicit freshness information (see Section 2.3.1 of [Part6]). =A0A > =A0 cached POST response with a Content-Location header field (see > =A0 Section 6.7 of [Part3]) whose value is the effective Request URI MAY > =A0 be used to satisfy subsequent GET and HEAD requests. > > =A0 Note that POST caching is not widely implemented. =A0However, the 303 > =A0 (See Other) response can be used to direct the user agent to retrieve > =A0 a cacheable resource. > > Ben It is not the cacheability of the results of post request that I was referring to, but the cacheability of the results of a 303. See 10.3.4 of RFC 2616: The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable. regards, Ted Hardie From msk@cloudmark.com Wed May 2 09:31:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4906911E808F for ; Wed, 2 May 2012 09:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gbvQidAN3+t for ; Wed, 2 May 2012 09:31:46 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 54BC111E8088 for ; Wed, 2 May 2012 09:31:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 54Xh1j0040as01C014XhRp; Wed, 02 May 2012 09:31:41 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Dv3UCRD+ c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=s95_sykgwzEA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=9BiPPiKm7Yj52aEd308A:9 a=vRDB3pZP63VHWajDq4MA:7 a=CjuIK1q_8ugA:10 a=PzHz5ke4CpwA:10 a=lZB815dzVvQA:10 a=5EL2pNwa7gye9ggt:21 a=i0cP_n_-k16rA8KA:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Wed, 2 May 2012 09:31:16 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Apps Area Directorate Report for April 2012 Thread-Index: AQHNKC4uBW2RS6pMXkKSsD5J36Ixzpa2ilYAgAAmqqA= Date: Wed, 2 May 2012 16:31:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810A524@exch-mbx901.corp.cloudmark.com> References: <6.2.5.6.2.20120501223143.0a4e9a30@elandnews.com> <6.2.5.6.2.20120502000504.09882378@resistor.net> In-Reply-To: <6.2.5.6.2.20120502000504.09882378@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335976301; bh=1V88FDI/eXSFJpc5/RZ18eKAXuXdwVIMiojYCqu5hrI=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=W8bcAMXW5tiPZxPnsP9eFxsH33ytrI+bXWhFWae68IBXNLB4lpAdYYGBOPP8FkDTx aZXt4WwIKWMm3w9Y2V/Elx0uPkrUvq7rQJj59O/2bCQxOdCanBrrOZUpKkeVNhfAmc pExfilOS7kyc2PZ0fc+bVcpM5JCjcSHxaKgA/y1g= Subject: Re: [apps-discuss] Apps Area Directorate Report for April 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 16:31:47 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of S Moonesamy > Sent: Wednesday, May 02, 2012 12:11 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Apps Area Directorate Report for April 2012 >=20 > I forgot to include the following review in the report for April 2012: >=20 > Reviewer I-D >=20 > Jiankang Yao draft-claise-export-application-info-in-ipfix-05 >=20 > The total number of review for last month is 19. I apologize to > Jiankang for the omission. You also left out my review of draft-ietf-eai-rfc5721bis! :-) http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05280.html -MSK From sm@elandsys.com Wed May 2 09:53:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5179821E804B for ; Wed, 2 May 2012 09:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeSyJBZefwyu for ; Wed, 2 May 2012 09:53:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C27721E8044 for ; Wed, 2 May 2012 09:53:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.171]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q42GrVRM016574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 May 2012 09:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335977623; i=@elandsys.com; bh=q90xi6L5VTAKR10xavAeo6V3QHG7EX/y8hA5WtaVWEU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=S1XNx7y0iop0YqQs+6cqVae5OjyywMbttdkhuOPB/zez0bn315BfaBZVlWtpFoUwm ItnFuYTJmMkpPGCilypP6C60wfdhzA8T0Z/p19ZulnnrtRngpftzbliZHnLtJjkori edGpLNi05KKigLd5RcTq9Mu4vBEunC05qHBjV15E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335977623; i=@elandsys.com; bh=q90xi6L5VTAKR10xavAeo6V3QHG7EX/y8hA5WtaVWEU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=jfwoEtU7S9Yj2ikhz9EyjS6iCDhYjs5HFf3a66sPAv1y9ExMmcA1J1RwobvMs03Jd AQLF/VFqc4+/8Ai1RlVA3oE7dq37Nc+C9HzpGz0NI9sCx6cLW3P6EXgVU0NQWHU+mX UHCFv6GERHCkykkMQqToKFyjjqBd0sRJ9UIoP6jk= Message-Id: <6.2.5.6.2.20120502093653.0acd0128@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 02 May 2012 09:53:13 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <9452079D1A51524AA5749AD23E00392810A524@exch-mbx901.corp.cl oudmark.com> References: <6.2.5.6.2.20120501223143.0a4e9a30@elandnews.com> <6.2.5.6.2.20120502000504.09882378@resistor.net> <9452079D1A51524AA5749AD23E00392810A524@exch-mbx901.corp.cloudmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Apps Area Directorate Report for April 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 16:53:48 -0000 Hi Murray, At 09:31 02-05-2012, Murray S. Kucherawy wrote: >You also left out my review of draft-ietf-eai-rfc5721bis! :-) I apologize for the omission. Thanks for pointing it out. It helps to keep the AppsDir tracker ( http://trac.tools.ietf.org/area/app/trac/wiki/tracker ) up-to-date. I'll also acknowledge your effort as you performed two AppsDir reviews last month. Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From ben@niven-jenkins.co.uk Wed May 2 10:39:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFD21F8557 for ; Wed, 2 May 2012 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.074 X-Spam-Level: X-Spam-Status: No, score=-103.074 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKYtBDEUgxOg for ; Wed, 2 May 2012 10:39:07 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD5321F8555 for ; Wed, 2 May 2012 10:39:07 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SPdW5-0004UM-4Q; Wed, 02 May 2012 18:39:05 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Wed, 2 May 2012 18:39:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> To: Ted Hardie X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-ietf-alto-protocol.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 17:39:08 -0000 On 2 May 2012, at 17:28, Ted Hardie wrote: > On Wed, May 2, 2012 at 9:23 AM, Ben Niven-Jenkins > wrote: >> Ted, >=20 >> I do not believe that this is the case, from Section 6.5 of = draft-ietf-httpbis-p2-semantics-19 (RFC2616 has similar text to the = first paragraph): >>=20 >> Responses to POST requests are only cacheable when they include >> explicit freshness information (see Section 2.3.1 of [Part6]). A >> cached POST response with a Content-Location header field (see >> Section 6.7 of [Part3]) whose value is the effective Request URI = MAY >> be used to satisfy subsequent GET and HEAD requests. >>=20 >> Note that POST caching is not widely implemented. However, the 303 >> (See Other) response can be used to direct the user agent to = retrieve >> a cacheable resource. >>=20 >> Ben >=20 > It is not the cacheability of the results of post request that I was > referring to, but > the cacheability of the results of a 303. Ah, I see. Yes I see your issue with the text now.=20 I believe there is an implicit assumption on the part of the authors = that in this model (receive a POST and return a 303) that the ALTO = server could be doing some level of "ALTO-application level caching" to = avoid repeating expensive queries by determining that a given POST would = execute the same query as a previous POST and therefore rather than run = the query again, just return a 303 to a resource on the ALTO server that = contains the results of the previous (identical) query. But as I'm not an author I'll crawl back under my rock now. Ben > See 10.3.4 of RFC 2616: >=20 > The 303 response MUST NOT be cached, but the response to the second > (redirected) request might be cacheable. >=20 > regards, >=20 > Ted Hardie From msk@cloudmark.com Wed May 2 10:48:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C0C21F85CD for ; Wed, 2 May 2012 10:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frYBSwyZrgt8 for ; Wed, 2 May 2012 10:48:09 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id C32F121F85C9 for ; Wed, 2 May 2012 10:48:09 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 55oU1j0010ZaKgw015oUtM; Wed, 02 May 2012 10:48:34 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Dv3UCRD+ c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=5SqQFJvkn3sA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=D_u2ATCz6vtTo4ItkiYA:9 a=CjuIK1q_8ugA:10 a=_RhRFcbxBZMA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 2 May 2012 10:48:02 -0700 From: "Murray S. Kucherawy" To: Julian Reschke Thread-Topic: ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec) Thread-Index: AQHNKIu4kW6hhbexxk28TNX+IGDrBA== Date: Wed, 2 May 2012 17:48:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> In-Reply-To: <4FA03F4D.3050606@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335980914; bh=+P8QEJ1gvwck6EoJ+KqN2sNulfQamdFCBgaNCljwKRg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Hof1xSL4lyfcNW3o3FWgXWj20QUA7/JLvqVDzIgGjUkZP5CAmbS6yzwzAGqUtITX1 a5kD3gXTQYC5YQrDQD5rDaDqY602Fn45I2D9RT0M+vNnDCUhYW0ffkQMS8sk6bK5y4 KpnoXwJEBhaIAjoPPhn4duCJ2Yhyex/YD0nlNpHc= Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: [apps-discuss] ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 17:48:10 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, May 01, 2012 12:54 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-tran= sport-sec@tools.ietf.org > Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transpor= t-sec >=20 > Technically it *does* point to the authoritative definition. The real issue here is that we don't have a (ahem) standard way to import A= BNF definitions from other documents. The specific problem in this case to= me is twofold: 1) Section 4 of RFC5234 specifies that the prose-val construction is a mech= anism of "last resort", which I take to mean one uses it only when the thin= g you need to describe is sufficiently complicated that it's easier to desc= ribe in English than in ABNF. I don't think "1*DIGIT" qualifies, nor does = an import from another document because we do it all the time with a non-AB= NF sentence. (Now, if that admonition in RFC5234 needs clarification, then= let's do that.) 2) There's a common axiom that says it's safer to refer to a definition rat= her than to copy it. I understand that we're up against reader convenience= here, which can suffer when a copy isn't used, especially when the definit= ions being recycled are scattered throughout many documents. Although I'm = infinitely confident the string "1*DIGIT" was copied correctly from RFC2616= to this draft, I'm concerned that approval of this use will eventually lea= d to a case where some author uses prose-val to copy something more complex= in the name of reader convenience, and get it wrong, and now we have two d= ocuments that don't agree on the definition of something. That may or may = not have serious side effects. What I would prefer in this case is to say one of these: "delta-seconds" in defined in Section 3.3.2 of RFC2616. delta-seconds =3D I strongly prefer the former. I still think the latter is an improper use = of prose-val, but at least the ABNF itself isn't copied there. To address the larger question, we definitely have to have some conversatio= n about the right way to do this in general. Perhaps another draft that up= dates RFC5234 which presents a consensus view of the right, safe, convenien= t way to do so would be useful. Perhaps further we just say that what you'= re doing here is the new official way to do so, where the ABNF inside the p= rose-val is a convenience copy with the understanding that the referenced d= efinition is authoritative if somehow they diverged. =20 For example, we could standardize on a prose-val whose contents are of the = form: name =3D < [ABNF] "from " [ "Section " 1*DIGIT *( "." 1*DIGIT) " of " ] "R= FC" 1*DIGIT > This would be interpreted as: "name" is defined in the specified RFC, possi= bly down to the specified Section. If ABNF is there, it is a convenience c= opy; the referenced document contains the official definition of "name". A= nd people would just discourage the convenience copy in cases where it's no= n-trivial. (We'd have to bang on this a bit to allow importing from docume= nts that aren't RFCs, but you get the idea.) I'd be happy to write that up as something that updates 5234 if people thin= k that's a good idea. -MSK From mrex@sap.com Wed May 2 10:50:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1391D21F85C9; Wed, 2 May 2012 10:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEyxtuCE54gK; Wed, 2 May 2012 10:50:54 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 384C721F85C6; Wed, 2 May 2012 10:50:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q42Hoq01001031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 19:50:52 +0200 (MEST) From: Martin Rex Message-Id: <201205021750.q42HopRD001898@fs4113.wdf.sap.corp> To: ned.freed@mrochek.com (Ned Freed) Date: Wed, 2 May 2012 19:50:51 +0200 (MEST) In-Reply-To: <01OF03JVQP0C0006TG@mauve.mrochek.com> from "Ned Freed" at May 2, 12 09:13:44 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: mrex@sap.com, ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 17:50:55 -0000 Ned Freed wrote: > > > Ned Freed wrote: > > > > > > > I don't think is there a definite need e.g. for something that > > > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > > > that might or might not be needed but we won't know until its > > > > being done. > > > > > > But that's what it currently says is needed. > > > > > > > Nevertheless, how about if it said: > > > > > > > "Note that this document does not cover how to associate > > > > certificates with domain names for application protocols that depend > > > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > > > future documents will cover methods for making those associations. > > > > Those documents may or may not need to update this one." > > > > > > That's essentially the change I suggested making. > > > > Writing that those apps-protocol-specific documents (defining how to > > use a particular protocol with TLSA/DANE-protocol) might need to update the > > TLSA/DANE-protocol document is misleading (and IMHO should be avoided). > > > http://tools.ietf.org/html/rfc2223#section-12 > > > defines the "Updates:" metadata for RFCs to have a very narrow and purely > > editorial meaning. "Updates:" is meant to refer to those situations > > where a paragraph or section of a new document **completely** replaces > > the same paragraph or section of a previous RFC. > > That section doesn't say or even imply that the change has to be purely > editorial in nature. (The word "editorial" appears nowhere in the section and > neither do the words "paragraph" or "section".) The rfc2223 document title is "Instruction to RFC Authors". The Updates: header has a purely editorial meaning for the *new* document, but the result can certainly be very technical for the *old* document! Updates: should only be used if the change is supposed to apply not only to implementations of the *new* document, but that all new implementors of the *old* (=updated) document should ignore certain parts of the old document and use the new document instead. But in order for this to work, - a section in the new document is *REQUIRED* which list exactly which pieces of the *old* (=updated) document are completely replaced by which pieces of the new document - retaining full interop with old implementations based on only the full spec, and clear distinction of features that were added or dropped in the updated parts. > > > It is probably much more common to "extend" an existing protocol or > > describe/define additional usage scenarios without changing the original > > specification, simply by using the extensibility of the original protocol. > > Sure, but it is also common to make a technical change and call it an update. > You may not like that, but that's how it works. That is not necessarily a contradiction. But there is a certain mess in the meta-data of published RFCs. Publishing a change to specification will not magically change the behaviour of an installed base, therefore "changes" need to account for the reality of life. -Martin From mrex@sap.com Wed May 2 11:07:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D0F11E808F; Wed, 2 May 2012 11:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91A3DKLZFFbU; Wed, 2 May 2012 11:07:47 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05511E8081; Wed, 2 May 2012 11:07:46 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q42I7jWr003159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 20:07:45 +0200 (MEST) From: Martin Rex Message-Id: <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Wed, 2 May 2012 20:07:44 +0200 (MEST) In-Reply-To: from "Tony Finch" at May 2, 12 03:13:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: mrex@sap.com, apps-discuss@ietf.org, marka@isc.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 18:07:48 -0000 Tony Finch wrote: > > Martin Rex wrote: > > Mark Andrews wrote: > > > > > > Should != must. > > > > I think that is a misunderstanding. > > No, I think Mark is right. RFC 6125 is guidance for protocol designers, > so the "should" is a recommendation about how to decide which identity is > authenticated when adding TLS to a protocol. Whether local policy can > override this decision is something else entirely. The idea behind this should is that it completely obviates the need of a secure directory and secure lookup service and is easier to understand and configure and therefore easier to operate securely. The idea behind DANE is that it can be implemented and evaluated as a module, and provides a similar service as a public CA that issues DV-validated SSL certs. If there are apps protocols that would like to perform fancy name transformations on the that is passed as input to an implementation of DANE-protocol, then this apps protocol will have to specify (and implement) the security for any such name transformations when they are not based on a trusted local source, because the DANE module does not know about (and therefore does not care about) any such transformations. Any necessity of such name transformations is likely to also cause problems with obtaining and using "traditional" PKIX certificates (TLSA usage types 0&1). Apps which currently have such a PKIX-problem first ought to fix their architecture so that the TLSA usage 0&1 vs 2&3 becomes a true option for the consumer of the technology, rather than focus on subverting usage type 2&3 only and leaving the problems that preclude TLSA usages 0&1 unsolved. -Martin From ned.freed@mrochek.com Wed May 2 11:23:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2101421E8063; Wed, 2 May 2012 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1Q68pbXJjH1; Wed, 2 May 2012 11:23:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 571ED21E804A; Wed, 2 May 2012 11:23:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF07L2359S000WLL@mauve.mrochek.com>; Wed, 2 May 2012 11:23:14 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Wed, 2 May 2012 11:23:11 -0700 (PDT) Message-id: <01OF07L047040006TF@mauve.mrochek.com> Date: Wed, 02 May 2012 11:10:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 02 May 2012 19:50:51 +0200 (MEST)" <201205021750.q42HopRD001898@fs4113.wdf.sap.corp> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OF03JVQP0C0006TG@mauve.mrochek.com> <201205021750.q42HopRD001898@fs4113.wdf.sap.corp> To: Martin Rex Cc: mrex@sap.com, ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 18:23:19 -0000 > Ned Freed wrote: > > > > > Ned Freed wrote: > > > > > > > > > I don't think is there a definite need e.g. for something that > > > > > says how to use DANE with XMPP or SMTP to update the TLSA RFC - > > > > > that might or might not be needed but we won't know until its > > > > > being done. > > > > > > > > But that's what it currently says is needed. > > > > > > > > > Nevertheless, how about if it said: > > > > > > > > > "Note that this document does not cover how to associate > > > > > certificates with domain names for application protocols that depend > > > > > on SRV, NAPTR, and similar DNS resource records. It is expected that > > > > > future documents will cover methods for making those associations. > > > > > Those documents may or may not need to update this one." > > > > > > > > That's essentially the change I suggested making. > > > > > > > Writing that those apps-protocol-specific documents (defining how to > > > use a particular protocol with TLSA/DANE-protocol) might need to update the > > > TLSA/DANE-protocol document is misleading (and IMHO should be avoided). > > > > > http://tools.ietf.org/html/rfc2223#section-12 > > > > > defines the "Updates:" metadata for RFCs to have a very narrow and purely > > > editorial meaning. "Updates:" is meant to refer to those situations > > > where a paragraph or section of a new document **completely** replaces > > > the same paragraph or section of a previous RFC. > > > > That section doesn't say or even imply that the change has to be purely > > editorial in nature. (The word "editorial" appears nowhere in the section and > > neither do the words "paragraph" or "section".) > The rfc2223 document title is "Instruction to RFC Authors". The Updates: > header has a purely editorial meaning for the *new* document, but the > result can certainly be very technical for the *old* document! And that's quite simply nonsense. It has a technical meaning in both cases. In the new document it's informing the reader that this document changes or adds to a previous specification. > Updates: should only be used if the change is supposed to apply not only > to implementations of the *new* document, but that all new implementors of > the *old* (=updated) document should ignore certain parts of the old > document and use the new document instead. Which is exactly the sense in which it is being used here. Although I think it unlikely given how limited DANE is, it is nevertheless possible that some subsequent use of TLSA will require tweaking of something in the DANE specification. We're not omnipotent and we don't always get every detail right. Of course this brings up the question as to when the level of change rises to the point where an revision that obsoletes the original is required. This is a judgement call that needs to be made on a case-by-case basis. > But in order for this to work, > - a section in the new document is *REQUIRED* which list exactly > which pieces of the *old* (=updated) document are completely > replaced by which pieces of the new document I rather suspect I can find any number of examples where that wasn't done, but yes, I agree that it is best done this way. RFC 6532 certainly used this approach. But this actually supports the notion that we use be using the term "updates" here, to make it clear that if changes are made they need to be done this way. > - retaining full interop with old implementations based on only > the full spec, and clear distinction of features that were > added or dropped in the updated parts. This, OTOH, is unduly constraining. The RFC 6532 is again on point - it made a change (allowing nested encodings) that could conceivably cause interoperability problems, although that is believed to be unlikely. Such cases should be rare, and when they do come up full consideration needs to be given to the consequences, but saying it should never be allowed under any circumstances is excessive. > > > > > It is probably much more common to "extend" an existing protocol or > > > describe/define additional usage scenarios without changing the original > > > specification, simply by using the extensibility of the original protocol. > > > > Sure, but it is also common to make a technical change and call it an update. > > You may not like that, but that's how it works. > That is not necessarily a contradiction. > But there is a certain mess in the meta-data of published RFCs. > Publishing a change to specification will not magically change > the behaviour of an installed base, therefore "changes" need to > account for the reality of life. On this, at least, we agree. But the bigger problem is how to clean it up. On that score I'm a bit sort on helpful suggestions. Ned From julian.reschke@gmx.de Wed May 2 11:34:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926DF21E8054 for ; Wed, 2 May 2012 11:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.062 X-Spam-Level: X-Spam-Status: No, score=-103.062 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62X5xWIRe8LH for ; Wed, 2 May 2012 11:34:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7692811E8083 for ; Wed, 2 May 2012 11:34:07 -0700 (PDT) Received: (qmail invoked by alias); 02 May 2012 18:34:06 -0000 Received: from p5DD96838.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.104.56] by mail.gmx.net (mp070) with SMTP; 02 May 2012 20:34:06 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX192yUdWFVt2IeXqnf+Hp0TZeX6r+WCvxzC/xq9mD6 h/qogz947+Gd+g Message-ID: <4FA17E13.5070207@gmx.de> Date: Wed, 02 May 2012 20:33:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 18:34:08 -0000 On 2012-05-02 19:48, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Tuesday, May 01, 2012 12:54 PM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-sec@tools.ietf.org >> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec >> >> Technically it *does* point to the authoritative definition. > > The real issue here is that we don't have a (ahem) standard way to import ABNF definitions from other documents. The specific problem in this case to me is twofold: Exactly. It would be good to have that. > 1) Section 4 of RFC5234 specifies that the prose-val construction is a mechanism of "last resort", which I take to mean one uses it only when the thing you need to describe is sufficiently complicated that it's easier to describe in English than in ABNF. I don't think "1*DIGIT" qualifies, nor does an import from another document because we do it all the time with a non-ABNF sentence. (Now, if that admonition in RFC5234 needs clarification, then let's do that.) The choices we have are: a) import "by value" (copy the ABNF rule) b) import "by reference" For b), I see two options: b1) have a prose rule for the imported ABNF rule, or b2) just say it in prose. The advantage of b1 over b2 is that an ABNF checker can check whether the ABNF is complete (for some value of "complete"). I believe that using the prose rule for that is strictly better than having an incomplete ABNF, but it would certainly be cool to have something better than that. > 2) There's a common axiom that says it's safer to refer to a definition rather than to copy it. I understand that we're up against reader convenience here, which can suffer when a copy isn't used, especially when the definitions being recycled are scattered throughout many documents. Although I'm infinitely confident the string "1*DIGIT" was copied correctly from RFC2616 to this draft, I'm concerned that approval of this use will eventually lead to a case where some author uses prose-val to copy something more complex in the name of reader convenience, and get it wrong, and now we have two documents that don't agree on the definition of something. That may or may not have serious side effects. > > What I would prefer in this case is to say one of these: > > "delta-seconds" in defined in Section 3.3.2 of RFC2616. > > delta-seconds = > > I strongly prefer the former. I still think the latter is an improper use of prose-val, but at least the ABNF itself isn't copied there. > > To address the larger question, we definitely have to have some conversation about the right way to do this in general. Perhaps another draft that updates RFC5234 which presents a consensus view of the right, safe, convenient way to do so would be useful. Perhaps further we just say that what you're doing here is the new official way to do so, where the ABNF inside the prose-val is a convenience copy with the understanding that the referenced definition is authoritative if somehow they diverged. > > For example, we could standardize on a prose-val whose contents are of the form: > > name =< [ABNF] "from " [ "Section " 1*DIGIT *( "." 1*DIGIT) " of " ] "RFC" 1*DIGIT> Something like that, yes. It would help automated checkers a lot. > This would be interpreted as: "name" is defined in the specified RFC, possibly down to the specified Section. If ABNF is there, it is a convenience copy; the referenced document contains the official definition of "name". And people would just discourage the convenience copy in cases where it's non-trivial. (We'd have to bang on this a bit to allow importing from documents that aren't RFCs, but you get the idea.) > > I'd be happy to write that up as something that updates 5234 if people think that's a good idea. Best regards, Julian From mrex@sap.com Wed May 2 11:53:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84B011E80B2; Wed, 2 May 2012 11:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.231 X-Spam-Level: X-Spam-Status: No, score=-9.231 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6-udFn5t6DH; Wed, 2 May 2012 11:53:20 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CF94D11E80B1; Wed, 2 May 2012 11:53:19 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q42IrIZV028717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 20:53:18 +0200 (MEST) From: Martin Rex Message-Id: <201205021853.q42IrHJJ005341@fs4113.wdf.sap.corp> To: ned.freed@mrochek.com (Ned Freed) Date: Wed, 2 May 2012 20:53:17 +0200 (MEST) In-Reply-To: <01OF07L047040006TF@mauve.mrochek.com> from "Ned Freed" at May 2, 12 11:10:49 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: mrex@sap.com, ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 18:53:20 -0000 Ned Freed wrote: > > > Updates: should only be used if the change is supposed to apply not only > > to implementations of the *new* document, but that all new implementors of > > the *old* (=updated) document should ignore certain parts of the old > > document and use the new document instead. > > Which is exactly the sense in which it is being used here. Although > I think it unlikely given how limited DANE is, it is nevertheless > possible that some subsequent use of TLSA will require tweaking of > something in the DANE specification. We're not omnipotent and we > don't always get every detail right. Just the opposite. Quite similar to rfc6125, DANE-protocol assumes that you already have a trustworthy hostname for which to retrieve the certificate association. This way, DANE-protocol can be put into a black block module for the caller and does not need to be updated or changed depending on the usage scenario. It would even be possible to tunnel the TLSA+DNSSEC records for performing DANE-protocol through a TLS extension instead of looking it up in a combined TLS+DANE module in a fashion that is completely opaque to the application caller. What some of the app specs (other than HTTPS) may have to specify _and_ implement, in order to be able to use DANE, is how to securely obtain a hostname&port which can be used as input to an implementation of DANE-protocol or input to rfc6125 matching for PKIX-based matching to DV-validated server certificates. But such an apps-specific spec is _not_ an update to DANE itself, in spite of refering to DANE. It is irrelevant to the DANE software module. New TLS cipher suites usually do not update or change TLS, new crypto algorithms usually do not update or change PKIX, new mime-types ususally do not update HTTP or the internet message format. > > > - retaining full interop with old implementations based on only > > the full spec, and clear distinction of features that were > > added or dropped in the updated parts. > > This, OTOH, is unduly constraining. Not at all. Maybe you're misreading this. It says that anything that claims to update an earlier document must explain where and how it does that, an in particular outline omissions and mark additions as such, so that it will be clear to the reader of the document. Example: http://tools.ietf.org/html/rfc5321#section-1.2 -Martin From ben@niven-jenkins.co.uk Wed May 2 12:24:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D1221E80A8 for ; Wed, 2 May 2012 12:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FNXty0LBz71 for ; Wed, 2 May 2012 12:24:50 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id A3F6711E809D for ; Wed, 2 May 2012 12:24:42 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SPfAH-0000Sa-5L; Wed, 02 May 2012 20:24:41 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Wed, 2 May 2012 20:24:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> To: Richard Alimi X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-ietf-alto-protocol.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 19:24:51 -0000 Rich, Ted, On 2 May 2012, at 18:49, Richard Alimi wrote: > On Wed, May 2, 2012 at 10:39 AM, Ben Niven-Jenkins > wrote: >>=20 >> On 2 May 2012, at 17:28, Ted Hardie wrote: >>>=20 >>> It is not the cacheability of the results of post request that I was >>> referring to, but >>> the cacheability of the results of a 303. >>=20 >> Ah, I see. Yes I see your issue with the text now. >>=20 >> I believe there is an implicit assumption on the part of the authors = that in this model (receive a POST and return a 303) that the ALTO = server could be doing some level of "ALTO-application level caching" to = avoid repeating expensive queries by determining that a given POST would = execute the same query as a previous POST and therefore rather than run = the query again, just return a 303 to a resource on the ALTO server that = contains the results of the previous (identical) query. >>=20 >=20 > The word 'caching' was meant to apply to the response the ALTO Client > that actually contained the data it was looking for (that is, the > following GET). An ALTO Server could also internally cache the > results to avoid repeated computation, but that was meant to be > implicit since this text was referring to the protocol messaging. >=20 > I understand Ted's point about the ambiguity in the text 'employ > caching for the response to a POST request'. We can clean that up to > indicate that the caching is for the ALTO-level response (as returned > by the following GET) and not the response to the POST itself. >=20 >> But as I'm not an author I'll crawl back under my rock now. >=20 > No - come back! :) As you asked so nicely, I wonder if the following (slightly wordy) = change would address Ted's comment: OLD: Note that it is possible for an ALTO Server to employ caching for the response to a POST request. This can be accomplished by returning an HTTP 303 status code ("See Other") indicating to the ALTO Client that the resulting Cost Map is available via a GET request to an alternate URL (which may be cached). NEW: Note that it is possible for an ALTO Server to leverage caching HTTP = intermediaries for responses to both GET and POST requests by including = explicit freshness information (see Section 2.3.1 of [HTTPBIS Part6]). Caching of POST requests is not widely implemented by HTTP = intermediaries, however an alternative approach is for an ALTO Server, = in response to POST requests, to return an HTTP 303 status code ("See = Other") indicating to the ALTO Client that the resulting Cost Map is = available via a GET request to an alternate URL. HTTP intermediaries = that do not support caching of POST requests could then cache the = response to the GET request from the ALTO Client following the alternate = URL in the 303 response (if the response to the subsequent GET request = contains explicit freshness information). END Ted went on to say: > Since cachability > is a major reason cited for the re-use of HTTP, some additional text > on the use cache control directives ("public" and "Max-age" seem > particularly important in this context) might also be useful. I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would = suffice? Ben From vkg@bell-labs.com Wed May 2 12:28:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4421E8056 for ; Wed, 2 May 2012 12:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.799 X-Spam-Level: X-Spam-Status: No, score=-107.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXas+dgM+MPx for ; Wed, 2 May 2012 12:28:06 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 50A7111E809D for ; Wed, 2 May 2012 12:28:06 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q42JS2cM006448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 14:28:02 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q42JS118006844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 May 2012 14:28:02 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q42JS0nT020718; Wed, 2 May 2012 14:28:01 -0500 (CDT) Message-ID: <4FA18BF6.3080704@bell-labs.com> Date: Wed, 02 May 2012 14:33:10 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ben Niven-Jenkins , Francois Le Faucheur References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "draft-ietf-cdni-problem-statement@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-cdni-problem-statement-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 19:28:07 -0000 On 04/30/2012 03:03 PM, Ben Niven-Jenkins wrote: > Francois, Vijay, > > See below for responses/comments and see attached for the current working > text. [...] Ben, Francois: Thanks for addressing my review in the manner you suggested. I have no further comments on the draft. It is good to go from my side. Ciao, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From ben@niven-jenkins.co.uk Wed May 2 12:29:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E724921E80B7; Wed, 2 May 2012 12:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.885 X-Spam-Level: X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=-2.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leLKUg2Doo+T; Wed, 2 May 2012 12:29:44 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 17E4A21E80B6; Wed, 2 May 2012 12:29:44 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SPfF8-0007Js-Vh; Wed, 02 May 2012 20:29:43 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> Date: Wed, 2 May 2012 20:29:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DC76AEC-2DCE-4DE4-B92C-C37F160DA7FF@niven-jenkins.co.uk> References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Richard Alimi , draft-ietf-alto-protocol.all@tools.ietf.org, alto , apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 19:29:45 -0000 cc'ing ALTO as Vijay suggested. Ben On 2 May 2012, at 20:24, Ben Niven-Jenkins wrote: > Rich, Ted, >=20 > On 2 May 2012, at 18:49, Richard Alimi wrote: >=20 >> On Wed, May 2, 2012 at 10:39 AM, Ben Niven-Jenkins >> wrote: >>>=20 >>> On 2 May 2012, at 17:28, Ted Hardie wrote: >>>>=20 >>>> It is not the cacheability of the results of post request that I = was >>>> referring to, but >>>> the cacheability of the results of a 303. >>>=20 >>> Ah, I see. Yes I see your issue with the text now. >>>=20 >>> I believe there is an implicit assumption on the part of the authors = that in this model (receive a POST and return a 303) that the ALTO = server could be doing some level of "ALTO-application level caching" to = avoid repeating expensive queries by determining that a given POST would = execute the same query as a previous POST and therefore rather than run = the query again, just return a 303 to a resource on the ALTO server that = contains the results of the previous (identical) query. >>>=20 >>=20 >> The word 'caching' was meant to apply to the response the ALTO Client >> that actually contained the data it was looking for (that is, the >> following GET). An ALTO Server could also internally cache the >> results to avoid repeated computation, but that was meant to be >> implicit since this text was referring to the protocol messaging. >>=20 >> I understand Ted's point about the ambiguity in the text 'employ >> caching for the response to a POST request'. We can clean that up to >> indicate that the caching is for the ALTO-level response (as returned >> by the following GET) and not the response to the POST itself. >>=20 >>> But as I'm not an author I'll crawl back under my rock now. >>=20 >> No - come back! :) >=20 > As you asked so nicely, I wonder if the following (slightly wordy) = change would address Ted's comment: >=20 > OLD: > Note that it is possible for an ALTO Server to employ caching for = the > response to a POST request. This can be accomplished by returning = an > HTTP 303 status code ("See Other") indicating to the ALTO Client = that > the resulting Cost Map is available via a GET request to an = alternate > URL (which may be cached). > NEW: > Note that it is possible for an ALTO Server to leverage caching HTTP = intermediaries for responses to both GET and POST requests by including = explicit freshness information (see Section 2.3.1 of [HTTPBIS Part6]). >=20 > Caching of POST requests is not widely implemented by HTTP = intermediaries, however an alternative approach is for an ALTO Server, = in response to POST requests, to return an HTTP 303 status code ("See = Other") indicating to the ALTO Client that the resulting Cost Map is = available via a GET request to an alternate URL. HTTP intermediaries = that do not support caching of POST requests could then cache the = response to the GET request from the ALTO Client following the alternate = URL in the 303 response (if the response to the subsequent GET request = contains explicit freshness information). > END >=20 > Ted went on to say: >> Since cachability >> is a major reason cited for the re-use of HTTP, some additional text >> on the use cache control directives ("public" and "Max-age" seem >> particularly important in this context) might also be useful. >=20 > I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would = suffice? >=20 > Ben >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From fielding@gbiv.com Wed May 2 12:32:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DE021E80BD; Wed, 2 May 2012 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.009 X-Spam-Level: X-Spam-Status: No, score=-106.009 tagged_above=-999 required=5 tests=[AWL=-3.410, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJd4y3uoxPKq; Wed, 2 May 2012 12:32:40 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6421E8056; Wed, 2 May 2012 12:32:40 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 1A1662AC07A; Wed, 2 May 2012 12:32:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=xgrHMQnursLACXgB tVS+x63EGzggrYWDpwgHeQgnifClaM4g3WRz52lNJ604vPSwmyBc58qrRM/+U+RT 9KV6YD9zNvd2QFTDwT9wAfQ6BKMfWGx6N4pFLjvzhpaeshOoxlwrE8yZFkbY0Uzu VFjXbvA9i7EgeFDRO8I/OId11ko= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=SDGvZ0OzO3ZRMborggBvoT64Kvs=; b=g8Rk5yVTB0zF6hGd56uw76UlTD6Q U9zYlDO3Psc4XSpQ5C0bkqg8DKWheErP8GoAoNScO+x8a5FQechdYdMsK0SNYZFf 7Rl1iWUbB1sUxs8TrWlJDFud9WYLI3EBFIpIKLnRyhLOrRysoAdiw5Y5tLqHLT0w ++5j6opLbmxoeSw= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 7EB8D2AC0A9; Wed, 2 May 2012 12:32:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> Date: Wed, 2 May 2012 12:32:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1257) Cc: Julian Reschke , IETF WebSec WG , IETF Apps Discuss Subject: Re: [apps-discuss] ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 19:32:41 -0000 On May 2, 2012, at 10:48 AM, Murray S. Kucherawy wrote: > 2) There's a common axiom that says it's safer to refer to a = definition rather than to copy it. I think we should recognize that as a false axiom and move on. We should refer to orthogonal definitions that are subject to independent change control -- e.g., protocol elements that are defined in another spec because they change at a different rate than the referring spec or are used by multiple specs. We should copy a definition by value if the referring spec depends on the definition (does not allow the parser to change even if some other spec were to define it and later extend it). My preference is to not use prose definitions at all -- I used them as a crutch when I first started writing IETF specs in 1994, and they burned me every time. And if we go down the slippery slope, I would love to have a formal definition of set reduction, as in ALPHA =3D ALPHANUM - DIGIT since I very commonly need rules that only differ by one or two characters being removed from the allowed set. ....Roy= From julian.reschke@gmx.de Wed May 2 14:14:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F257B11E80C0 for ; Wed, 2 May 2012 14:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buh0SJEZOU0T for ; Wed, 2 May 2012 14:14:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 18E1311E808F for ; Wed, 2 May 2012 14:14:01 -0700 (PDT) Received: (qmail invoked by alias); 02 May 2012 21:14:00 -0000 Received: from p5DD96838.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.104.56] by mail.gmx.net (mp031) with SMTP; 02 May 2012 23:14:00 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+oBb9zV3KoibnHuM+UVqLO4CuR/RiJyURWEbe/88 iqAE74xkNaoFgY Message-ID: <4FA1A395.7090704@gmx.de> Date: Wed, 02 May 2012 23:13:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Roy T. Fielding" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> In-Reply-To: <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG , IETF Apps Discuss Subject: Re: [apps-discuss] ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 21:14:03 -0000 On 2012-05-02 21:32, Roy T. Fielding wrote: > ... > And if we go down the slippery slope, I would love to have a > formal definition of set reduction, as in > > ALPHA = ALPHANUM - DIGIT > ... +1000 From marka@isc.org Wed May 2 16:25:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9121E8053; Wed, 2 May 2012 16:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drOFqVMTMBTf; Wed, 2 May 2012 16:25:32 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 35E7B21E802B; Wed, 2 May 2012 16:25:32 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 0AA905F9943; Wed, 2 May 2012 23:25:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8533:73c:dc1:bdbb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E5278216C33; Wed, 2 May 2012 23:25:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0F806205C037; Thu, 3 May 2012 09:25:05 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp> In-reply-to: Your message of "Wed, 02 May 2012 20:07:44 +0200." <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp> Date: Thu, 03 May 2012 09:25:05 +1000 Message-Id: <20120502232506.0F806205C037@drugs.dv.isc.org> Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 23:25:33 -0000 In message <201205021807.q42I7iZW002794@fs4113.wdf.sap.corp>, Martin Rex writes: > Tony Finch wrote: > > > > Martin Rex wrote: > > > Mark Andrews wrote: > > > > > > > > Should != must. > > > > > > I think that is a misunderstanding. > > > > No, I think Mark is right. RFC 6125 is guidance for protocol designers, > > so the "should" is a recommendation about how to decide which identity is > > authenticated when adding TLS to a protocol. Whether local policy can > > override this decision is something else entirely. > > The idea behind this should is that it completely obviates the need of a > secure directory and secure lookup service and is easier to understand > and configure and therefore easier to operate securely. Indeed, but it is not the only model of usage. Pushing the RFC 6125 model onto MX would just be wrong. Sometimes you do need the secure directory and secure lookup. Having each protcol specify the security model it is using is a good thing. For MX and STARTTLS, DANE can stop downgrade attacks on the MX targets. You can't just intercept port 25 traffic and get away with it in a world where DANE exists like you can with plain PKIX. You have to manipulate the DNS and hope that the client MTA is not checking by using DNSSEC. MTA's can now know whether that should be expecting to see STARTTLS on not in the EHOL response. If they don't they see it then they should abort the connection even if the MX records themselves were not secure. > The idea behind DANE is that it can be implemented and evaluated > as a module, and provides a similar service as a public CA that issues > DV-validated SSL certs. That is part of what DANE provides. It also provides protection from downgrade attacks by indicating that TLS is available. It also provides protection from rogue CA's and rogue states that get global wildcard certs. These are adjucts to PKIX. > If there are apps protocols that would like to perform fancy name > transformations on the that is passed as input to an implementation > of DANE-protocol, then this apps protocol will have to specify > (and implement) the security for any such name transformations > when they are not based on a trusted local source, because the > DANE module does not know about (and therefore does not care about) > any such transformations. > > Any necessity of such name transformations is likely to also cause > problems with obtaining and using "traditional" PKIX certificates > (TLSA usage types 0&1). Apps which currently have such a PKIX-problem > first ought to fix their architecture so that the TLSA usage 0&1 vs 2&3 > becomes a true option for the consumer of the technology, rather > than focus on subverting usage type 2&3 only and leaving the problems > that preclude TLSA usages 0&1 unsolved. Just because you don't like the alternate security model that doesn't make it wrong or require that protocol to be fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ned.freed@mrochek.com Wed May 2 19:25:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BEE21E801B; Wed, 2 May 2012 19:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8HmrgHiYYkk; Wed, 2 May 2012 19:25:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 48CC721E8019; Wed, 2 May 2012 19:25:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF0OFIAT6O000YTV@mauve.mrochek.com>; Wed, 2 May 2012 19:25:07 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Wed, 2 May 2012 19:25:04 -0700 (PDT) Message-id: <01OF0OFG3VOI0006TF@mauve.mrochek.com> Date: Wed, 02 May 2012 19:10:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 02 May 2012 20:53:17 +0200 (MEST)" <201205021853.q42IrHJJ005341@fs4113.wdf.sap.corp> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OF07L047040006TF@mauve.mrochek.com> <201205021853.q42IrHJJ005341@fs4113.wdf.sap.corp> To: Martin Rex Cc: mrex@sap.com, ned.freed@mrochek.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 02:25:13 -0000 > Ned Freed wrote: > > > > > Updates: should only be used if the change is supposed to apply not only > > > to implementations of the *new* document, but that all new implementors of > > > the *old* (=updated) document should ignore certain parts of the old > > > document and use the new document instead. > > > > Which is exactly the sense in which it is being used here. Although > > I think it unlikely given how limited DANE is, it is nevertheless > > possible that some subsequent use of TLSA will require tweaking of > > something in the DANE specification. We're not omnipotent and we > > don't always get every detail right. > Just the opposite. So you're saying that it is flatly impossible that DANE contains some assertion or restriction or whatever that will interfere with some future protocol use of TLSA? Please cite your proof of this, because I'm a wee bit skeptical. Remember, just because we're allowing something to be done doesn't mean it ever will be done. This is known as "covering our bases". Morever, as Mark Andrews has pointed out in another thread, it is also entirely possible that DANE may be used to implement different security models than the one the specification currently describes. > Quite similar to rfc6125, DANE-protocol assumes that you already have a > trustworthy hostname for which to retrieve the certificate association. > This way, DANE-protocol can be put into a black block module for the > caller and does not need to be updated or changed depending on the > usage scenario. It would even be possible to tunnel the TLSA+DNSSEC > records for performing DANE-protocol through a TLS extension instead > of looking it up in a combined TLS+DANE module in a fashion that is > completely opaque to the application caller. I fail to see the slightest relevance. > What some of the app specs (other than HTTPS) may have to specify _and_ > implement, in order to be able to use DANE, is how to securely obtain > a hostname&port which can be used as input to an implementation of > DANE-protocol or input to rfc6125 matching for PKIX-based matching > to DV-validated server certificates. > But such an apps-specific spec is _not_ an update to DANE itself, > in spite of refering to DANE. It is irrelevant to the DANE software module. In other words, by giving a single example where you claim it won't be necessary to update DANE, you have shown that it any possible protocol, including future ones we haven't even thought of, developed in the future won't need to either? > New TLS cipher suites usually do not update or change TLS, new crypto > algorithms usually do not update or change PKIX, new mime-types ususally > do not update HTTP or the internet message format. And by giving examples of things where extensibility was specifically planned into the underlying protocols, you have now proved that a protocol that contains no similar provisions will ... at this point I don't even know how to finish the sentence. This makes no sense whatsoever. > > > > > - retaining full interop with old implementations based on only > > > the full spec, and clear distinction of features that were > > > added or dropped in the updated parts. > > > > This, OTOH, is unduly constraining. > Not at all. Maybe you're misreading this. It says that anything that > claims to update an earlier document must explain where and how it does > that, an in particular outline omissions and mark additions as such, > so that it will be clear to the reader of the document. Misreading? More like miswriting, if it was you intention to say that. You said "retaining full interop with old implementations based on only the full spec", which is what I objected to. Your new paraphrase mentions none of that. > Example: http://tools.ietf.org/html/rfc5321#section-1.2 Both RFC 5321 and RFC 5322 and their predecessors went to considerable trouble to maintain compatibility with RFC 821 and RFC 822, preferring to mark a large number of features as deprecated rather than remove them. But this is not always possible, as was the case when the nested encoding restriction was removed so that message/global could be defined. Anyway, this has now gone well past the point of absurdity. I apologize to everyone who has read all of this for wasting their time on such a silly argument. This will be my final message on the topic. Ned From richard.alimi@gmail.com Wed May 2 22:23:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CA821F84CD; Wed, 2 May 2012 22:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8V9H3imZNNt; Wed, 2 May 2012 22:23:04 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCB721F84C4; Wed, 2 May 2012 22:23:04 -0700 (PDT) Received: by ggmi1 with SMTP id i1so187592ggm.31 for ; Wed, 02 May 2012 22:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=2bZ5O9dWMzE76JSWHbFTJK69UlfwOO2GLKpJnthNWW8=; b=BFAOYPW/Zb+ojCCOisI6sCqMgHtwmozRj8gDGJ9YRZuVlLT3feKPKrQhaulIu4RfN4 mOFeBrOCpvvadvd+ciDYE0gSQ64s0eoyfm3rXJh8mceeufOu9ZB4+fA0iYsCUs4i3o3Q sV1JU+TbXlopsOwBLJdyYHv2+hNCYEfD/Wt0wocwaxrpkAeugfJkAyxAKYypuFmfaOs6 EgYAR5iiXXJnDMHDCAhB4zSTURpU5eVQ25efdidNZVfw3GQxMYKsWSIsGJ0Mo2O4BEOy 1+vdugCvF8u/2GVH6fPG81zsHpHYl2dG05PW1xtanFFgzJccChvt4VFmsmCcDRtL22iv lgJw== Received: by 10.50.45.197 with SMTP id p5mr461296igm.20.1336022583866; Wed, 02 May 2012 22:23:03 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.206.146 with HTTP; Wed, 2 May 2012 22:22:43 -0700 (PDT) In-Reply-To: <4DC76AEC-2DCE-4DE4-B92C-C37F160DA7FF@niven-jenkins.co.uk> References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> <4DC76AEC-2DCE-4DE4-B92C-C37F160DA7FF@niven-jenkins.co.uk> From: Richard Alimi Date: Wed, 2 May 2012 22:22:43 -0700 X-Google-Sender-Auth: 15k_gtreUUrW-7CkbEFf6vGG6Ck Message-ID: To: Ben Niven-Jenkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Richard Alimi , draft-ietf-alto-protocol.all@tools.ietf.org, alto , apps-discuss@ietf.org Subject: Re: [apps-discuss] [alto] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 05:23:05 -0000 On Wed, May 2, 2012 at 12:29 PM, Ben Niven-Jenkins wrote: > cc'ing ALTO as Vijay suggested. Ben > > On 2 May 2012, at 20:24, Ben Niven-Jenkins wrote: > >> Rich, Ted, >> >> On 2 May 2012, at 18:49, Richard Alimi wrote: >> >>> On Wed, May 2, 2012 at 10:39 AM, Ben Niven-Jenkins >>> wrote: >>>> >>>> On 2 May 2012, at 17:28, Ted Hardie wrote: >>>>> >>>>> It is not the cacheability of the results of post request that I was >>>>> referring to, but >>>>> the cacheability of the results of a 303. >>>> >>>> Ah, I see. Yes I see your issue with the text now. >>>> >>>> I believe there is an implicit assumption on the part of the authors t= hat in this model (receive a POST and return a 303) that the ALTO server co= uld be doing some level of "ALTO-application level caching" to avoid repeat= ing expensive queries by determining that a given POST would execute the sa= me query as a previous POST and therefore rather than run the query again, = just return a 303 to a resource on the ALTO server that contains the result= s of the previous (identical) query. >>>> >>> >>> The word 'caching' was meant to apply to the response the ALTO Client >>> that actually contained the data it was looking for (that is, the >>> following GET). =A0An ALTO Server could also internally cache the >>> results to avoid repeated computation, but that was meant to be >>> implicit since this text was referring to the protocol messaging. >>> >>> I understand Ted's point about the ambiguity in the text 'employ >>> caching for the response to a POST request'. =A0We can clean that up to >>> indicate that the caching is for the ALTO-level response (as returned >>> by the following GET) and not the response to the POST itself. >>> >>>> But as I'm not an author I'll crawl back under my rock now. >>> >>> No - come back! :) >> >> As you asked so nicely, I wonder if the following (slightly wordy) chang= e would address Ted's comment: >> >> OLD: >> =A0 Note that it is possible for an ALTO Server to employ caching for th= e >> =A0 response to a POST request. =A0This can be accomplished by returning= an >> =A0 HTTP 303 status code ("See Other") indicating to the ALTO Client tha= t >> =A0 the resulting Cost Map is available via a GET request to an alternat= e >> =A0 URL (which may be cached). >> NEW: >> Note that it is possible for an ALTO Server to leverage caching HTTP int= ermediaries for responses to both GET and POST requests by including explic= it freshness information (see Section 2.3.1 of [HTTPBIS Part6]). >> >> Caching of POST requests is not widely implemented by HTTP intermediarie= s, however an alternative approach is for an ALTO Server, in response to PO= ST requests, to return an HTTP 303 status code ("See Other") indicating to = the ALTO Client that the resulting Cost Map is available via a GET request = to an alternate URL. HTTP intermediaries that do not support caching of POS= T requests could then cache the response to the GET request from the ALTO C= lient following the alternate URL in the 303 response (if the response to t= he subsequent GET request contains explicit freshness information). >> END This seems reasonable to me, except would it be appropriate to have this kind of document dependency? Would it be more appropriate to just reference RFC2616? >> >> Ted went on to say: >>> Since cachability >>> is a major reason cited for the re-use of HTTP, some additional text >>> on the use cache control directives ("public" and "Max-age" seem >>> particularly important in this context) might also be useful. >> >> I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would suffi= ce? Once upon a time, we used to have more detail about how to use HTTP (caching in particular) in the ALTO Protocol draft itself. The recommendation at that point was to strip out the large majority of it and rely on the reference to the HTTP specs being sufficient. That said, any pointers to help out implementers are fine with me as long as we don't to back to where we were before :) A concise hint or direct reference pointing to the cache control directives seems reasonable to me unless there are objections. Thanks for the feedback, Rich >> >> Ben >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto From brian.e.carpenter@gmail.com Wed May 2 23:39:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78BA21F85AD; Wed, 2 May 2012 23:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.547 X-Spam-Level: X-Spam-Status: No, score=-101.547 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRFAK6yAJjSh; Wed, 2 May 2012 23:39:29 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B028D21F8528; Wed, 2 May 2012 23:39:28 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so951113wgb.13 for ; Wed, 02 May 2012 23:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eyQz2wZyT49+gQhZz5zLwn/4WfoYActLSRf7EapuBoU=; b=rHcp663V9ZxzjsLV70YvrDOl4Au1cfRFgdn8kpNZukhbH9dFlWkD/qDGG+mY90TJxU xnDWPkINPl3cgbk6D4lUsnK1s7vTlRay0TNBMdGNdKuv2byJjzFewh5PAJ8amSFm4hi7 atfpMnOM2l1vDoNHHnAqCo/Z4erg3ZXtRVe4wF+t2bPzVxV5JhuTKoJbdRqukAiqdt3T VcJE40dLk95Sv/gH1lcZ8kHBTzyQO48u1fr4X/XVQqUnqO2WWweqiVhKkUVmLFoer1IZ 5+hVb3ejdsEEo9OmDGw4wKJwlHbm6kPBEv056s8madlabfPuVmRtTcCeiuGzSKPISCfF /7OQ== Received: by 10.216.134.155 with SMTP id s27mr696278wei.80.1336027167649; Wed, 02 May 2012 23:39:27 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-144.as13285.net. [2.102.217.144]) by mx.google.com with ESMTPS id n20sm379878wiw.5.2012.05.02.23.39.25 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 23:39:26 -0700 (PDT) Message-ID: <4FA22814.6020309@gmail.com> Date: Thu, 03 May 2012 07:39:16 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Roy T. Fielding" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> In-Reply-To: <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , IETF WebSec WG , IETF Apps Discuss Subject: Re: [apps-discuss] ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 06:39:30 -0000 Roy, On 2012-05-02 20:32, Roy T. Fielding wrote: > On May 2, 2012, at 10:48 AM, Murray S. Kucherawy wrote: >> 2) There's a common axiom that says it's safer to refer to a definition rather than to copy it. > > I think we should recognize that as a false axiom and move on. > > We should refer to orthogonal definitions that are subject to > independent change control -- e.g., protocol elements that are > defined in another spec because they change at a different > rate than the referring spec or are used by multiple specs. > > We should copy a definition by value if the referring spec > depends on the definition (does not allow the parser to change > even if some other spec were to define it and later extend it). But that is contrary to the general principle in the IETF of using normative references and *not* replicating normative material, to avoid mistakes. Both approaches have their advantages and disadvantages, but making ABNF an exception seems problematic, or at least a decision that can't be taken at Area level. > My preference is to not use prose definitions at all -- I used > them as a crutch when I first started writing IETF specs in 1994, > and they burned me every time. > > And if we go down the slippery slope, I would love to have a > formal definition of set reduction, as in > > ALPHA = ALPHANUM - DIGIT > > since I very commonly need rules that only differ by one or two > characters being removed from the allowed set. Would you call that "disinheritance" ? Brian From ben@niven-jenkins.co.uk Wed May 2 23:59:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B141221F8601; Wed, 2 May 2012 23:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JnybRZW3fik; Wed, 2 May 2012 23:59:32 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6621F85F8; Wed, 2 May 2012 23:59:32 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.3]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SPq02-0003n0-OA; Thu, 03 May 2012 07:58:51 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 3 May 2012 07:59:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> <4DC76AEC-2DCE-4DE4-B92C-C37F160DA7FF@niven-jenkins.co.uk> To: Richard Alimi X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Richard Alimi , draft-ietf-alto-protocol.all@tools.ietf.org, alto , apps-discuss@ietf.org Subject: Re: [apps-discuss] [alto] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 06:59:33 -0000 Rich, On 3 May 2012, at 06:22, Richard Alimi wrote: > On Wed, May 2, 2012 at 12:29 PM, Ben Niven-Jenkins > wrote: >>=20 >>> As you asked so nicely, I wonder if the following (slightly wordy) = change would address Ted's comment: >>>=20 >>> OLD: >>> Note that it is possible for an ALTO Server to employ caching for = the >>> response to a POST request. This can be accomplished by returning = an >>> HTTP 303 status code ("See Other") indicating to the ALTO Client = that >>> the resulting Cost Map is available via a GET request to an = alternate >>> URL (which may be cached). >>> NEW: >>> Note that it is possible for an ALTO Server to leverage caching HTTP = intermediaries for responses to both GET and POST requests by including = explicit freshness information (see Section 2.3.1 of [HTTPBIS Part6]). >>>=20 >>> Caching of POST requests is not widely implemented by HTTP = intermediaries, however an alternative approach is for an ALTO Server, = in response to POST requests, to return an HTTP 303 status code ("See = Other") indicating to the ALTO Client that the resulting Cost Map is = available via a GET request to an alternate URL. HTTP intermediaries = that do not support caching of POST requests could then cache the = response to the GET request from the ALTO Client following the alternate = URL in the 303 response (if the response to the subsequent GET request = contains explicit freshness information). >>> END >=20 > This seems reasonable to me, except would it be appropriate to have > this kind of document dependency? Would it be more appropriate to > just reference RFC2616? Up to you. HTTPBIS is in the process of putting the HTTPBIS specs = through WG LC so there is light at the end of the tunnel for them = popping out as RFCs. I referred to the HTTPBIS document because it's = easier to find an appropriate reference but similar material is in 2616. >>> Ted went on to say: >>>> Since cachability >>>> is a major reason cited for the re-use of HTTP, some additional = text >>>> on the use cache control directives ("public" and "Max-age" seem >>>> particularly important in this context) might also be useful. >>>=20 >>> I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would = suffice? >=20 > Once upon a time, we used to have more detail about how to use HTTP > (caching in particular) in the ALTO Protocol draft itself. The > recommendation at that point was to strip out the large majority of it > and rely on the reference to the HTTP specs being sufficient. I seem to remember being one of the people saying to strip it out and = just provide a reference :-) Ben >=20 > That said, any pointers to help out implementers are fine with me as > long as we don't to back to where we were before :) A concise hint or > direct reference pointing to the cache control directives seems > reasonable to me unless there are objections. >=20 > Thanks for the feedback, > Rich >=20 >>>=20 >>> Ben >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> _______________________________________________ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto From melvincarvalho@gmail.com Thu May 3 02:41:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1005021F8531 for ; Thu, 3 May 2012 02:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcA26yiZHo8T for ; Thu, 3 May 2012 02:41:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C817721F84F1 for ; Thu, 3 May 2012 02:41:19 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1336198vbb.31 for ; Thu, 03 May 2012 02:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XcxnbuiWZB3bEh46cIP7K4epSO3b6no01dSu3+eh5K0=; b=EeeE0nFPARSbow/IhhhOnDY/V7KtuDDHk0WPdYi60BrrUlQRrGHv9ASVNCbglbGFIE U/d1V1CiVDHa0DrGVBpyP3lV4zOiqki9dbCFwFz/rZqlKVvqGJjanfVc+PHQOiy9BNTG M8MVwccmGEkwuh5sn7bs1mW28WRAVc10bwRZXOTkhspii1T9urZuLdKZACUdPLIUMx9R +qKTA/9x7zX99B//+kmPKyfNpWcSLm41xJ1BX9J3WCKBFUivhGb6FpudAyJD2i3OGqsm cQLsbi2ESuRdD/gMfuEeMcMIyDbSw24hjkSBfYI+0A1WtY4G7eIiRJPY5OIQZVDwfc0d 0vyQ== MIME-Version: 1.0 Received: by 10.52.93.131 with SMTP id cu3mr567154vdb.122.1336034646216; Thu, 03 May 2012 01:44:06 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Thu, 3 May 2012 01:44:06 -0700 (PDT) In-Reply-To: <4FA11C4B.2000202@packetizer.com> References: <4FA0F384.5050008@packetizer.com> <4FA11C4B.2000202@packetizer.com> Date: Thu, 3 May 2012 10:44:06 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf307cfe6c7ecec204bf1dce47 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 09:41:21 -0000 --20cf307cfe6c7ecec204bf1dce47 Content-Type: text/plain; charset=ISO-8859-1 On 2 May 2012 13:36, Paul E. Jones wrote: > On 5/2/2012 7:08 AM, Melvin Carvalho wrote: > >> One thing that would be a kind of joint problem statement, of the main >> thing that's trying to be solved. >> > > Is this not understood? Keep in mind that this was not fabricated last > week. I've been personally interacting with people working on WebFinger > for a couple of years (or more) now. The idea is all about discovery. > Given a URI, what can you learn about it? This resulted in the creation > of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along the > way. Definitely, the web linking document (RFC 5988) is also an important > part of this. > > > I think this started out as a way for webmail providers to give auxiliary >> "follow your nose" style data linkage, using the "well known" pattern. >> > > I don't know where it all started, but I got my start with OpenID. I did > not like entering https://openid.packetizer.com/**paulejwhenever I wanted to log in. Rather, I wanted to enter > paulej@packetizer.com. I was referred by folks on the OpenID list to go > look at WebFinger. And, here we are. Yes I do remember the transition from Yadis to OpenID through 1.1 and to 2.0. As you say there was a marked change. Seems to be two polarizing world views. One is to use email style identifiers to describe things, the other is to use HTTP URIs to describe things. The UI choice need not necessarily influence the backend architecture. For example, facebook open graph uses HTTP URIs to define a profile, but allows login with an email style identifier. > > > It's sort of morphed a bit into a few different things, such as a generic >> discovery method for the net, a new uri scheme, an account identity system >> for the net, serialization formats. >> > > I don't think it has morphed. These were things that needed to be defined > to realize the vision. > > > All these things *can* be important, but there's already solutions in >> many places, and overlap with existing technology. The recent WWW 2012 >> conference has shown that structured data is now incoporated in somewhere >> between 25% and 32% of the web, eg using RDFa and microdta. Do we think >> it's productive to push yet another data lookup format? >> >> http://www.bbc.co.uk/blogs/**researchanddevelopment/2012/** >> 04/notes-from-the-www12-**conferenc.shtml >> >> It would be awesome if we can main pain point, or problem statement that >> these specs can solve, find out what the easy wins are, solve those with >> minimum fuss, imho. >> > > I'd argue there is nothing else in existence that can do what WebFinger > does, modulo the competing SWD draft. That said, I think there is agreement > to move forward with WebFinger to provide a single solution. > I dont have any problem with moving forward with the WF draft, perhaps taking the best features from both specs, is a great idea. I'm just interested on whether the combined problem statement will change, and the extent to which, there will be any focus on email based lookup. As an aside, in answer to your specific point. Im curious, are you saying that SPARQL, which has been a W3C rec, for a number of years, is incapable of a query such as the ones covered by SWD or WF? > > Are you arguing for a different data format? I think it's worth > highlighting the simplicity and beauty of the XRD/JRD representations. > These formats primarily include a set of link relations. The link > relations are the same syntax and possible values as one might use in the > "Link" header in HTTP and tags in HTML. So, WebFinger ties in very > nicely with the Web. > Not trying to form opinion here. Just to understand. In structured data, things can change pretty quickly, and we're all trying to hit a moving target. I do think it's sometimes helpful to look at what other technologies are starting to gain adoption, in order to get a bigger picture of the whole landscape, or how it might look in a few years. > > Paul > > > --20cf307cfe6c7ecec204bf1dce47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 May 2012 13:36, Paul E. Jones <paulej@packetizer.com> wrote:
On 5/2/2012 7:08 AM, Melvin Carvalho wrote:
One thing that would be a kind of joint problem statement, of the main thin= g that's trying to be solved.

Is this not understood? =A0Keep in mind that this was not fabricated last w= eek. =A0I've been personally interacting with people working on WebFing= er for a couple of years (or more) now. =A0The idea is all about discovery.= =A0Given a URI, what can you learn about it? =A0This resulted in the creat= ion of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along t= he way. =A0Definitely, the web linking document (RFC 5988) is also an impor= tant part of this.


I think this started out as a way for webmail providers to give auxiliary &= quot;follow your nose" style data linkage, using the "well known&= quot; pattern.

I don't know where it all started, but I got my start with OpenID. =A0I= did not like entering https://openid.packetizer.com/paulej whenever I w= anted to log in. =A0Rather, I wanted to enter paulej@packetizer.com. =A0I was referred = by folks on the OpenID list to go look at WebFinger. =A0And, here we are.

Yes I do remember the transition from Yadis to OpenID through 1.1 = and to 2.0.=A0 As you say there was a marked change.

Seems to be two= polarizing world views.=A0 One is to use email style identifiers to descri= be things, the other is to use HTTP URIs to describe things.=A0 The UI choi= ce need not necessarily influence the backend architecture.=A0 For example,= facebook open graph uses HTTP URIs to define a profile, but allows login w= ith an email style identifier.
=A0


It's sort of morphed a bit into a few different things, such as a gener= ic discovery method for the net, a new uri scheme, =A0an account identity s= ystem for the net, serialization formats.

I don't think it has morphed. =A0These were things that needed to be de= fined to realize the vision.


All these things *can* be important, but there's already solutions in m= any places, and overlap with existing technology. =A0The recent WWW 2012 co= nference has shown that structured data is now incoporated in somewhere bet= ween 25% and 32% of the web, eg using RDFa and microdta. =A0Do we think it&= #39;s productive to push yet another data lookup format?

http://www.bbc.co.uk/blog= s/researchanddevelopment/2012/04/notes-from-the-www12-= conferenc.shtml

It would be awesome if we can main pain point, or problem statement that th= ese specs can solve, find out what the easy wins are, solve those with mini= mum fuss, imho.

I'd argue there is nothing else in existence that can do what WebFinger= does, modulo the competing SWD draft. That said, I think there is agreemen= t to move forward with WebFinger to provide a single solution.

I dont have any problem with moving forward with the WF draft, per= haps taking the best features from both specs, is a great idea.=A0 I'm = just interested on whether the combined problem statement will change, and = the extent to which, there will be any focus on email based lookup.

As an aside, in answer to your specific point.=A0 Im curious, are you s= aying that SPARQL, which has been a W3C rec, for a number of years, is inca= pable of a query such as the ones covered by SWD or WF?
=A0

Are you arguing for a different data format? =A0I think it's worth high= lighting the simplicity and beauty of the XRD/JRD representations. =A0These= formats primarily include a set of link relations. =A0The link relations a= re the same syntax and possible values as one might use in the "Link&q= uot; header in HTTP and <link> tags in HTML. =A0So, WebFinger ties in= very nicely with the Web.

Not trying to form opinion here.=A0 Jus= t to understand.=A0 In structured data, things can change pretty quickly, a= nd we're all trying to hit a moving target.=A0 I do think it's some= times helpful to look at what other technologies are starting to gain adopt= ion, in order to get a bigger picture of the whole landscape, or how it mig= ht look in a few years.
=A0

Paul



--20cf307cfe6c7ecec204bf1dce47-- From ben@niven-jenkins.co.uk Thu May 3 03:32:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3D921F85BB for ; Thu, 3 May 2012 03:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.979 X-Spam-Level: X-Spam-Status: No, score=-102.979 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j+HJIjFgi5x for ; Thu, 3 May 2012 03:32:06 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 26DDD21F85AA for ; Thu, 3 May 2012 03:32:05 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SPtKO-0000IO-7W; Thu, 03 May 2012 11:32:04 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4FA18BF6.3080704@bell-labs.com> Date: Thu, 3 May 2012 11:31:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9169BFAE-7D25-4F9A-85DE-810E046864BE@niven-jenkins.co.uk> References: <4FA18BF6.3080704@bell-labs.com> To: Vijay K. Gurbani X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: Ben Niven-Jenkins , Francois Le Faucheur , "draft-ietf-cdni-problem-statement@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-cdni-problem-statement-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 10:32:06 -0000 On 2 May 2012, at 20:33, Vijay K. Gurbani wrote: > On 04/30/2012 03:03 PM, Ben Niven-Jenkins wrote: >> Francois, Vijay, >>=20 >> See below for responses/comments and see attached for the current = working >> text. [...] >=20 > Ben, Francois: Thanks for addressing my review in the manner you > suggested. >=20 > I have no further comments on the draft. It is good to go from my = side. Thanks, I uploaded a new version that addresses your comments and = includes some other edits by Francois. http://www.ietf.org/id/draft-ietf-cdni-problem-statement-05.txt Ben From paulej@packetizer.com Thu May 3 06:24:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA92C21F8595 for ; Thu, 3 May 2012 06:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2RyeN3Vi0MM for ; Thu, 3 May 2012 06:24:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 85CCA21F8592 for ; Thu, 3 May 2012 06:24:28 -0700 (PDT) Received: from [156.106.246.73] ([156.106.246.73]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q43DOP1d018182 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 May 2012 09:24:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336051467; bh=oGO6LPXRvXbPzUuam/vDBu12TKAr17XIMQH5RblhSSA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=IB4R7r8iMW4sD6I5zLu0Ub9z5hLu3jtwi14bL31fr9fEH313b5j0KtNf3UgThHdV8 szEdi1Ri9ZgEQiC18n0XsqKqwO4plQ+19HH5CWwqenhhBITIBii1MyedSYEWixVe4Y sdcsn+vSP8/B/kqr9gL/XCxqxXPqgvNfYhRkRxpE= Message-ID: <4FA2870D.1090407@packetizer.com> Date: Thu, 03 May 2012 09:24:29 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melvin Carvalho References: <4FA0F384.5050008@packetizer.com> <4FA11C4B.2000202@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020607030003030707070204" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 13:24:29 -0000 This is a multi-part message in MIME format. --------------020607030003030707070204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/3/2012 4:44 AM, Melvin Carvalho wrote: > > > On 2 May 2012 13:36, Paul E. Jones > wrote: > > On 5/2/2012 7:08 AM, Melvin Carvalho wrote: > > One thing that would be a kind of joint problem statement, of > the main thing that's trying to be solved. > > > Is this not understood? Keep in mind that this was not fabricated > last week. I've been personally interacting with people working > on WebFinger for a couple of years (or more) now. The idea is all > about discovery. Given a URI, what can you learn about it? This > resulted in the creation of the XRD spec, RFC 5785, RFC 6415 and > perhaps other documents along the way. Definitely, the web > linking document (RFC 5988) is also an important part of this. > > > I think this started out as a way for webmail providers to > give auxiliary "follow your nose" style data linkage, using > the "well known" pattern. > > > I don't know where it all started, but I got my start with OpenID. > I did not like entering https://openid.packetizer.com/paulej > whenever I wanted to log in. Rather, I wanted to enter > paulej@packetizer.com . I was > referred by folks on the OpenID list to go look at WebFinger. > And, here we are. > > > Yes I do remember the transition from Yadis to OpenID through 1.1 and > to 2.0. As you say there was a marked change. > > Seems to be two polarizing world views. One is to use email style > identifiers to describe things, the other is to use HTTP URIs to > describe things. The UI choice need not necessarily influence the > backend architecture. For example, facebook open graph uses HTTP URIs > to define a profile, but allows login with an email style identifier. Yeah, I agree with you entirely. This is a topic for the OpenID list, perhaps, but I had no objection to having OpenID use a URI. I just didn't want to enter it by hand :-) Thus, using WebFinger as a discovery protocol to facilitate the mapping of a email-style address into an OpenID URI made a lot of sense. > > > It's sort of morphed a bit into a few different things, such > as a generic discovery method for the net, a new uri scheme, > an account identity system for the net, serialization formats. > > > I don't think it has morphed. These were things that needed to be > defined to realize the vision. > > > All these things *can* be important, but there's already > solutions in many places, and overlap with existing > technology. The recent WWW 2012 conference has shown that > structured data is now incoporated in somewhere between 25% > and 32% of the web, eg using RDFa and microdta. Do we think > it's productive to push yet another data lookup format? > > http://www.bbc.co.uk/blogs/researchanddevelopment/2012/04/notes-from-the-www12-conferenc.shtml > > It would be awesome if we can main pain point, or problem > statement that these specs can solve, find out what the easy > wins are, solve those with minimum fuss, imho. > > > I'd argue there is nothing else in existence that can do what > WebFinger does, modulo the competing SWD draft. That said, I think > there is agreement to move forward with WebFinger to provide a > single solution. > > > I dont have any problem with moving forward with the WF draft, perhaps > taking the best features from both specs, is a great idea. I'm just > interested on whether the combined problem statement will change, and > the extent to which, there will be any focus on email based lookup. > > As an aside, in answer to your specific point. Im curious, are you > saying that SPARQL, which has been a W3C rec, for a number of years, > is incapable of a query such as the ones covered by SWD or WF? I'm not sure if it is capable or not, but I get the impression that SPARQL was not designed for that purpose. I suppose if there is a way to query for multiple data elements and the entirety of what one might want to query is located at a known location, perhaps it could. WebFinger is intended to allow on to issue a query for any URI against the associated domain, including acct:, mailto:, https:, etc. And the response is a simple set of link relations. The process is so trivial I can implement a "server" using static files and use "curl" to fetch the data set. Can SPARQL get information for any URI as WebFinger can? For certain, if it can it does so with a lot more complexity. I would need to see some examples, since those in the spec don't seem to be aligned with what WF or SWD do. > > Are you arguing for a different data format? I think it's worth > highlighting the simplicity and beauty of the XRD/JRD > representations. These formats primarily include a set of link > relations. The link relations are the same syntax and possible > values as one might use in the "Link" header in HTTP and > tags in HTML. So, WebFinger ties in very nicely with the Web. > > > Not trying to form opinion here. Just to understand. In structured > data, things can change pretty quickly, and we're all trying to hit a > moving target. I do think it's sometimes helpful to look at what > other technologies are starting to gain adoption, in order to get a > bigger picture of the whole landscape, or how it might look in a few > years. This is one reason I think XRD/JRD are good, too. One might represent data in a variety of formats (e.g., Portable Contacts vs. hCard vs. vCard vs. xcard). WF does not dictate the format in which useful information is presented. What it does is merely provide a pointer to that information. It's that simplicity and data independence which I find appealing, as I can continue to use WF long after formats holding user data become obsolete. Paul --------------020607030003030707070204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/3/2012 4:44 AM, Melvin Carvalho wrote:


On 2 May 2012 13:36, Paul E. Jones <paulej@packetizer.com> wrote:
On 5/2/2012 7:08 AM, Melvin Carvalho wrote:
One thing that would be a kind of joint problem statement, of the main thing that's trying to be solved.

Is this not understood?  Keep in mind that this was not fabricated last week.  I've been personally interacting with people working on WebFinger for a couple of years (or more) now.  The idea is all about discovery.  Given a URI, what can you learn about it?  This resulted in the creation of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along the way.  Definitely, the web linking document (RFC 5988) is also an important part of this.


I think this started out as a way for webmail providers to give auxiliary "follow your nose" style data linkage, using the "well known" pattern.

I don't know where it all started, but I got my start with OpenID.  I did not like entering https://openid.packetizer.com/paulej whenever I wanted to log in.  Rather, I wanted to enter paulej@packetizer.com.  I was referred by folks on the OpenID list to go look at WebFinger.  And, here we are.

Yes I do remember the transition from Yadis to OpenID through 1.1 and to 2.0.  As you say there was a marked change.

Seems to be two polarizing world views.  One is to use email style identifiers to describe things, the other is to use HTTP URIs to describe things.  The UI choice need not necessarily influence the backend architecture.  For example, facebook open graph uses HTTP URIs to define a profile, but allows login with an email style identifier.

Yeah, I agree with you entirely.  This is a topic for the OpenID list, perhaps, but I had no objection to having OpenID use a URI.  I just didn't want to enter it by hand :-)  Thus, using WebFinger as a discovery protocol to facilitate the mapping of a email-style address into an OpenID URI made a lot of sense.

 


It's sort of morphed a bit into a few different things, such as a generic discovery method for the net, a new uri scheme,  an account identity system for the net, serialization formats.

I don't think it has morphed.  These were things that needed to be defined to realize the vision.


All these things *can* be important, but there's already solutions in many places, and overlap with existing technology.  The recent WWW 2012 conference has shown that structured data is now incoporated in somewhere between 25% and 32% of the web, eg using RDFa and microdta.  Do we think it's productive to push yet another data lookup format?

http://www.bbc.co.uk/blogs/researchanddevelopment/2012/04/notes-from-the-www12-conferenc.shtml

It would be awesome if we can main pain point, or problem statement that these specs can solve, find out what the easy wins are, solve those with minimum fuss, imho.

I'd argue there is nothing else in existence that can do what WebFinger does, modulo the competing SWD draft. That said, I think there is agreement to move forward with WebFinger to provide a single solution.

I dont have any problem with moving forward with the WF draft, perhaps taking the best features from both specs, is a great idea.  I'm just interested on whether the combined problem statement will change, and the extent to which, there will be any focus on email based lookup.

As an aside, in answer to your specific point.  Im curious, are you saying that SPARQL, which has been a W3C rec, for a number of years, is incapable of a query such as the ones covered by SWD or WF?

I'm not sure if it is capable or not, but I get the impression that SPARQL was not designed for that purpose.  I suppose if there is a way to query for multiple data elements and the entirety of what one might want to query is located at a known location, perhaps it could.  WebFinger is intended to allow on to issue a query for any URI against the associated domain, including acct:, mailto:, https:, etc.  And the response is a simple set of link relations.  The process is so trivial I can implement a "server" using static files and use "curl" to fetch the data set.  Can SPARQL get information for any URI as WebFinger can?  For certain, if it can it does so with a lot more complexity.  I would need to see some examples, since those in the spec don't seem to be aligned with what WF or SWD do.

 

Are you arguing for a different data format?  I think it's worth highlighting the simplicity and beauty of the XRD/JRD representations.  These formats primarily include a set of link relations.  The link relations are the same syntax and possible values as one might use in the "Link" header in HTTP and <link> tags in HTML.  So, WebFinger ties in very nicely with the Web.

Not trying to form opinion here.  Just to understand.  In structured data, things can change pretty quickly, and we're all trying to hit a moving target.  I do think it's sometimes helpful to look at what other technologies are starting to gain adoption, in order to get a bigger picture of the whole landscape, or how it might look in a few years.

This is one reason I think XRD/JRD are good, too.  One might represent data in a variety of formats (e.g., Portable Contacts vs. hCard vs. vCard vs. xcard).  WF does not dictate the format in which useful information is presented.  What it does is merely provide a pointer to that information.  It's that simplicity and data independence which I find appealing, as I can continue to use WF long after formats holding user data become obsolete.

Paul
--------------020607030003030707070204-- From vkg@bell-labs.com Thu May 3 06:33:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5722B21F85A7; Thu, 3 May 2012 06:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.742 X-Spam-Level: X-Spam-Status: No, score=-107.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP9AVZ40-ymG; Thu, 3 May 2012 06:33:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 981AA21F848F; Thu, 3 May 2012 06:33:34 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q43DXTZA028702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 May 2012 08:33:29 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q43DXRF3019614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2012 08:33:28 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q43DXQHC019257; Thu, 3 May 2012 08:33:27 -0500 (CDT) Message-ID: <4FA28A5D.4050904@bell-labs.com> Date: Thu, 03 May 2012 08:38:37 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Richard Alimi References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> <4DC76AEC-2DCE-4DE4-B92C-C37F160DA7FF@niven-jenkins.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: draft-ietf-alto-protocol.all@tools.ietf.org, alto , apps-discuss@ietf.org, Richard Alimi Subject: Re: [apps-discuss] [alto] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 13:33:35 -0000 On 05/03/2012 01:59 AM, Ben Niven-Jenkins wrote: >> This seems reasonable to me, except would it be appropriate to >> have this kind of document dependency? Would it be more >> appropriate to just reference RFC2616? > > Up to you. HTTPBIS is in the process of putting the HTTPBIS specs > through WG LC so there is light at the end of the tunnel for them > popping out as RFCs. I referred to the HTTPBIS document because it's > easier to find an appropriate reference but similar material is in > 2616. If the reference to HTTPBIS is informative, then we are not gated by HTTPBIS reaching the terminal state of RFC assignment. So the question to Rich A. would be whether he thinks that the reference we put in fits better as Informative or Normative. If the former, then we can move ahead without any delays. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From flefauch@cisco.com Thu May 3 02:16:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390F921F846D for ; Thu, 3 May 2012 02:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.477 X-Spam-Level: X-Spam-Status: No, score=-9.477 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-kser7rY00o for ; Thu, 3 May 2012 02:16:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A877221F854C for ; Thu, 3 May 2012 02:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=255829; q=dns/txt; s=iport; t=1336036591; x=1337246191; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=K/Rqe7COy6bQfpVUzTRfvuESoRWJvq9cTI9Q9EAxFYw=; b=giVLJGUMQVhr7zqFJMAHf9Qlu50TiuZ0hIuD5yZO0jRG7ABuGnBEJ1r+ +oIFFmoDk7a/8S7Xqn6F5d1gSiPWEiEreWYOcAWc9JIaPvGEerqd7moI7 odSLxwiES8biwcfE5yT8y8C985lvBDsEVQ5NApLR0oBmtafmZrFrgLw0e A=; X-Files: image001.jpg, green.gif, draft-ietf-cdni-problem-statement-05-v2.docx : 11041, 87, 164644 X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="xml'?docx'72,48?scan'72,48,48,72,208,145,147,217?rels'72,48,48,72,208,145,147,217?jpeg'72,48,48,72,208,145,147,217,145?gif'72,48,48,72,208,145,147,217,145,147?jpg'72,48,48,72,208,145,147,217,145,147,145"; a="72334405" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 03 May 2012 09:16:30 +0000 Received: from ams-flefauch-8714.cisco.com (ams-flefauch-8714.cisco.com [10.55.161.197]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q439GJQ1018098; Thu, 3 May 2012 09:16:19 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_FEE4D563-470E-4E6D-A204-13D66C260625" From: Francois Le Faucheur In-Reply-To: <4FA18BF6.3080704@bell-labs.com> Date: Thu, 3 May 2012 11:16:21 +0200 Message-Id: <4EC5BC79-4A5F-4E69-A045-1F82776DF4CE@cisco.com> References: <4FA18BF6.3080704@bell-labs.com> To: Niven-Jenkins Ben X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 03 May 2012 08:05:16 -0700 Cc: "Vijay K. Gurbani" , Le Faucheur Francois , draft-ietf-cdni-problem-statement@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-cdni-problem-statement-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 09:16:54 -0000 --Apple-Mail=_FEE4D563-470E-4E6D-A204-13D66C260625 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ben, Attached is a slightly edited version (changes showing up with change = bars). They are purely editorial, except one change: which is I moved = and tweaked the text addressing Vijay's comment suggesting we better = expand the interplay relationships between the 4 entity. I think this = text needs to be moved somewhere towards the end of paragraph 2 , = instead of before paragraph 2, because paragraph 2 is where we first = introduce the notion of interconnecting CDNs, and that notion is = required to expand the full interplay relationship.=20 Also, I have the following comment/questions: *** ALTO reference. In section 4.1, you added a ref to the ALTO-Charter. I wonder if this is = a permanent enough ref (i.e. does charter URI remain as is if WG = concludes)? How about referring an ALTO RFC (e.g. ALTO Problem = Statement)? I know we already refer to the charter in the discussion on relationship = to ALTO, but that has been moved to the Appendix , precisely to avoid = issues of instability. *** adding scp in list of example protocols: Is there a clear reference we can use for SCP? If yes, we should = probably include it. If not, I wonder if we really need to include that = example. =20 *** Ack section: A few sentences I introduced in the security considerations section are = heavily inspired by some text in the Framework document., So we we may = want to add Larry Peterson's name in the Ack section (or alternatively = ack that we leveraged some work of framework doc re security = considerations). Cheers Francois On 2 May 2012, at 21:33, Vijay K. Gurbani wrote: > On 04/30/2012 03:03 PM, Ben Niven-Jenkins wrote: >> Francois, Vijay, >>=20 >> See below for responses/comments and see attached for the current = working >> text. [...] >=20 > Ben, Francois: Thanks for addressing my review in the manner you > suggested. >=20 > I have no further comments on the draft. It is good to go from my = side. >=20 > Ciao, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ Francois Le Faucheur Distinguished Engineer Service Provider Video Technology Group =20 flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail=_FEE4D563-470E-4E6D-A204-13D66C260625 Content-Type: multipart/mixed; boundary="Apple-Mail=_979BA0D0-ECBF-48EB-9EE4-68FE977276F1" --Apple-Mail=_979BA0D0-ECBF-48EB-9EE4-68FE977276F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Ben,

Attached is a slightly edited version (changes = showing up with change bars). They are purely editorial, except one = change: which is I moved and tweaked the text addressing Vijay's comment = suggesting we better expand the interplay relationships between the 4 = entity. I think this text needs to be moved somewhere towards the end of = paragraph 2 , instead of before paragraph 2, because paragraph 2 is = where we first introduce the notion of interconnecting CDNs, and that = notion is required to expand the full interplay = relationship. 

Also, I have the following = comment/questions:

*** ALTO = reference.
In section 4.1, you added a ref to the = ALTO-Charter. I wonder if this is a permanent enough ref (i.e. does = charter URI remain as is if WG concludes)? How about referring an = ALTO RFC (e.g. ALTO Problem Statement)?
I know we already = refer to the charter in the discussion on relationship to ALTO, but that = has been moved to the Appendix , precisely to avoid issues of = instability.

*** adding scp in list of example = protocols:
Is there a clear reference we can use for SCP? If = yes, we should probably include it. If not, I wonder if we really need = to include that example.
 
*** Ack = section:
A few sentences I introduced in the security = considerations section are heavily inspired by some text in the = Framework document., So we we may want to add Larry Peterson's name = in the Ack section (or alternatively ack that we leveraged some work of = framework doc re security = considerations).

Cheers

Francois


On 2 May 2012, at = 21:33, Vijay K. Gurbani wrote:

On = 04/30/2012 03:03 PM, Ben Niven-Jenkins wrote:
Francois, Vijay,

See below for = responses/comments and see attached for the current = working
text. =  [...]

Ben, Francois: Thanks for addressing my = review in the manner you
suggested.

I have no further comments = on the draft.  It is good to go from my side.

Ciao,

- = vijay
--
Vijay K. Gurbani, Bell Laboratories, = Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois = 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-luc= ent.com
Web:   http://ect.bell-labs.com/who/vk= g/



Francois Le = Faucheur
Distinguished = Engineer
Service Provider Video Technology Group =   

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 

= --Apple-Mail=_979BA0D0-ECBF-48EB-9EE4-68FE977276F1 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail=_979BA0D0-ECBF-48EB-9EE4-68FE977276F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

 Think before you = print.
--Apple-Mail=_979BA0D0-ECBF-48EB-9EE4-68FE977276F1-- --Apple-Mail=_FEE4D563-470E-4E6D-A204-13D66C260625-- From ondrej.sury@nic.cz Thu May 3 07:35:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F298A21F8625; Thu, 3 May 2012 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+4jlUNg5UgR; Thu, 3 May 2012 07:35:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFFA21F8621; Thu, 3 May 2012 07:35:50 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id C06A513F9E9; Thu, 3 May 2012 16:35:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336055749; bh=BaG9XbwRAGI7E9PuyyzuIUm8kCjXaI1tm8ET27VlB1M=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TaGmlFLOWsq+h+ctxUxnYp/mdy309ssBuV/dGs7MbzgGOYRX4PHejEB49UXn9KvVA Jp5T3XM39aMAFQT6ELVFckTZbTHZvKG+tdmv7U6eRxSbs6PbiRKyV8W0CgE7J7EVGg xehQ1JLnDKUK8p5KPv0yyt0iNPNo/6Tm/35eu0Uo= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 3 May 2012 16:35:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7394F7B6-F351-49E8-9728-F732A679DC18@nic.cz> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA031D1.50006@stpeter.im> <3F51E575-D6DC-44B0-A17B-AD8B228CD404@vpnc.org> To: Warren Kumari X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 03 May 2012 08:05:33 -0700 Cc: Paul Hoffman , apps-discuss@ietf.org, dane list Subject: [apps-discuss] Client-defined port -> particular port (was: [dane] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:35:51 -0000 On 1. 5. 2012, at 21:26, Warren Kumari wrote: >=20 > [ -IESG] > On May 1, 2012, at 3:18 PM, Paul Hoffman wrote: >=20 >> On May 1, 2012, at 11:56 AM, Peter Saint-Andre wrote: >>=20 >>> On 5/1/12 11:02 AM, Tony Finch wrote: >>>> Peter Saint-Andre wrote: >>>>>=20 >>>>> The change from "client-chosen port" to "client-define port" is >>>>> mystifying to me. Even assuming that "client-defined" was meant, = it's >>>>> not clear to me what a client-defined port is, and I see no = effective >>>>> difference between the old text and the new text. >>>>=20 >>>> I think the mistake is to talk about the client here. The client = begins a >>>> connection to the service's port at that IP address. >>>=20 >>> Usually, yes. Sometimes the client is configured to override the = default >>> port for the given service, as Paul noted. >>>=20 >>> Could we just say "It then begins a connection to a particular port = at >>> that address"? Perhaps the method for determining the port isn't = really >>> relevant in this spec. >>=20 >> Works for me. What do others think? >>=20 >> Current: >> It then begins a connection to a client-defined port at that address, = and sends an initial message there. >> Proposed: >> It then begins a connection to a particular port at that address, and = sends an initial message there. >=20 > LGTM. +1 -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu May 3 08:03:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1721F858D; Thu, 3 May 2012 08:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOgSol47tVyf; Thu, 3 May 2012 08:03:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8121F84D1; Thu, 3 May 2012 08:03:41 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 57D7913F9E9; Thu, 3 May 2012 17:03:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336057415; bh=y4DD9JEMYJPj2hCGMW/85OGQk3mg7VWZ8NgcWUIwIVE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pIH9WNpGkZ4trScvWgOC/F0gaPycer7rtn5g5H2NYl1F+tlbhxopCy2Ml9IKKBTTx GOYflkenzPXu/FarprM673FCL9nQ7SnNveNeTLLAgABXbYPM55udowza2+yGk/ZhgB b2+mNKhXasCiNEpG7kQmrPAGmPm+3pskgAfPEHj4= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F9F479A.10501@stpeter.im> Date: Thu, 3 May 2012 17:03:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3AF93C00-67F1-46EB-880F-2B72F1B72E6C@nic.cz> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 03 May 2012 08:05:48 -0700 Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:03:42 -0000 On 1. 5. 2012, at 4:16, Peter Saint-Andre wrote: > On 4/30/12 6:52 PM, Ned Freed wrote: >>=20 >>>> Again, I'm not taking any position on the interaction of TLSA = records and >>>> services that use SRV or SRV-like mechanisms. That said, I think = most of the >>>> comments are essentially saying that not discussing how TLSA = records would >>>> interact with such services at all - even if that discussion is = simply to say >>>> that those services need to specify how they are going to use TLSA = records - >>>> is a mistake. And I have to say that is a pretty compelling = argument. >>=20 >>> Could well be. What changes to the text in 1.3 of -20 do you think >>> are needed if any? >>=20 >>> " Note that this document does not cover how to = associate >>> certificates with domain names for application protocols that = depend >>> on SRV, NAPTR, and similar DNS resource records; it is expected = that >>> later updates to this document might cover methods for making = those >>> associations." >>=20 >> Well, to be blunt, I think that by trying to avoid solving the = problem now >> while not giving up control over future solutions this ends up being >> unacceptable to everyone.=20 >>=20 >> What if a service comes along that uses SRV records and wants to = specify how >> TLSA records are used to secure them? According to this text, it = can't - the >> clear implication here is that this has to be done by revising the = DANE >> specification itself. >>=20 >> And what about existing services like email where it is arguably the = case that >> simply using TLSA records to secure the A/AAAA targets MX records is >> sufficient? A very short "secure email transport" specification could >> be writte that refers to the DANE specification, but this would also = seem >> to forbid that. >>=20 >> I would much rather see a note that simply refers to future = specification work >> being needed, not specifically to a DANE revision being needed. >=20 > I had the same concern but then I realized that "later updates to this > document might cover methods for making those associations" could be > construed as referring to add-on documents that would officially = update > the DANE-RFC-to-be, not as saying that such changes would need to be > made in the single DANEbis document that would cover all possible uses > of the TLSA RR. Hear, hear! (Just remembers how many RFCs which states "Updates: = RFCNNNN" we have...) O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ralimi@google.com Wed May 2 10:50:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CC921F85C6 for ; Wed, 2 May 2012 10:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJkdWXSi2PHH for ; Wed, 2 May 2012 10:50:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7751921F85C0 for ; Wed, 2 May 2012 10:50:12 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so751587lbb.31 for ; Wed, 02 May 2012 10:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=dKcbkuOf0gtcd1D83B+EaV97B9rCOdTK1q4E/uLOAv8=; b=g6ClM44rd4PaOgl4slFckFUlo+uIXIZhpnRYUk++ZCCnnCMPqj5tu/qejg7vYtndLF 4OtKUeeYemOcQ2xMBj2zMOaL/WIQLzE7XMmA0voroYtG3JwQeg5Uje9bUcgGWtrCaEiU 0UExi78k4WtHSPhh4GySKDyr5rjEcaUdOIZ8M6jJd1cSwF96J+3swJmymeQN/YBIVtvv fkqhMFC05u7tGUuhh7iBAEr4QA4Kj0KHQAef6P5/1i3Tkh+tHp/09At4DzHTqPAchAJK Kj83nyc5Db9OUOqYWNcWpI7NfgAnolIWTVH/R6VkG/wvopD/IVkr/H6iGGOZfyjTuZXF RbYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=dKcbkuOf0gtcd1D83B+EaV97B9rCOdTK1q4E/uLOAv8=; b=l9iDmRebkyNG814FZyKsUQ1wd+FxLTy7+0pPHFtX+wcmnw9f8tWL+OeVivZBoAv0lP ovxN72LZ0Lzw9dmAKFILgHdmWHZJ/Uujc5bLF9mEjR72NAzT9Vd3EXnTyT8hEVYY59wq ebSj0Z0aHvjT0EhBHlGMvjc+sFCFFrNO7pm0l4GkKu3tUtX/vJxaDuNKxCFw6iLNLzWg mOe/j2uLgH6Ofm4+/sQdrrCmbaif+9OmhkhZb5EP1zPjFI8V0celP9UCwaGMGUDmkWE3 NAo+4UyLmdajGI5tR3GD914/w2pig8tmTbBOUK3YWsqhTZQaNgLcT6nxaQrQ4VEzlsOd c4cQ== Received: by 10.152.124.76 with SMTP id mg12mr21456516lab.6.1335981011494; Wed, 02 May 2012 10:50:11 -0700 (PDT) Received: by 10.152.124.76 with SMTP id mg12mr21456505lab.6.1335981011333; Wed, 02 May 2012 10:50:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.134.97 with HTTP; Wed, 2 May 2012 10:49:40 -0700 (PDT) In-Reply-To: <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> From: Richard Alimi Date: Wed, 2 May 2012 10:49:40 -0700 Message-ID: To: Ben Niven-Jenkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlqD/klio/+TOuJ/ZWt48Wd81J8SHZazwb7IZi+4DREidwnzhit9wBDWVTFpK3Npywhq9xzrlhZdCdBsLBXyYXM3ieYXp7w0qDsqdj3ed+MkNLiJVL7Eu9yydKv4OpwtB+qw8X4rhPBEDR7eCmGov1bPWgmEw== X-Mailman-Approved-At: Thu, 03 May 2012 08:05:59 -0700 Cc: draft-ietf-alto-protocol.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 17:50:13 -0000 On Wed, May 2, 2012 at 10:39 AM, Ben Niven-Jenkins wrote: > > On 2 May 2012, at 17:28, Ted Hardie wrote: > >> On Wed, May 2, 2012 at 9:23 AM, Ben Niven-Jenkins >> wrote: >>> Ted, >> >>> I do not believe that this is the case, from Section 6.5 of draft-ietf-= httpbis-p2-semantics-19 (RFC2616 has similar text to the first paragraph): >>> >>> =A0 Responses to POST requests are only cacheable when they include >>> =A0 explicit freshness information (see Section 2.3.1 of [Part6]). =A0A >>> =A0 cached POST response with a Content-Location header field (see >>> =A0 Section 6.7 of [Part3]) whose value is the effective Request URI MA= Y >>> =A0 be used to satisfy subsequent GET and HEAD requests. >>> >>> =A0 Note that POST caching is not widely implemented. =A0However, the 3= 03 >>> =A0 (See Other) response can be used to direct the user agent to retrie= ve >>> =A0 a cacheable resource. >>> >>> Ben >> >> It is not the cacheability of the results of post request that I was >> referring to, but >> the cacheability of the results of a 303. > > Ah, I see. Yes I see your issue with the text now. > > I believe there is an implicit assumption on the part of the authors that= in this model (receive a POST and return a 303) that the ALTO server could= be doing some level of "ALTO-application level caching" to avoid repeating= expensive queries by determining that a given POST would execute the same = query as a previous POST and therefore rather than run the query again, jus= t return a 303 to a resource on the ALTO server that contains the results o= f the previous (identical) query. > The word 'caching' was meant to apply to the response the ALTO Client that actually contained the data it was looking for (that is, the following GET). An ALTO Server could also internally cache the results to avoid repeated computation, but that was meant to be implicit since this text was referring to the protocol messaging. I understand Ted's point about the ambiguity in the text 'employ caching for the response to a POST request'. We can clean that up to indicate that the caching is for the ALTO-level response (as returned by the following GET) and not the response to the POST itself. > But as I'm not an author I'll crawl back under my rock now. No - come back! :) Rich > > Ben > >> =A0See 10.3.4 of RFC 2616: >> >> The 303 response MUST NOT be cached, but the response to the second >> (redirected) request might be cacheable. >> >> regards, >> >> Ted Hardie > From fanf2@hermes.cam.ac.uk Thu May 3 08:32:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7FD21F84F8; Thu, 3 May 2012 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+35Akn5dDgN; Thu, 3 May 2012 08:32:11 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3900221F8498; Thu, 3 May 2012 08:32:11 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40250) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SPy0n-0001RH-Do (Exim 4.72) (return-path ); Thu, 03 May 2012 16:32:09 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SPy0n-0006Eu-8d (Exim 4.67) (return-path ); Thu, 03 May 2012 16:32:09 +0100 Date: Thu, 3 May 2012 16:32:09 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> Message-ID: References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:32:12 -0000 Richard L. Barnes wrote: > > Oh, this discussion again. If you want real assurance that an > outsourced mail server is authorized to operate a mail server, then you > need: > 1. DNSSEC on the MX record (in which case the hosting provider can use his own cert) > 2. Certificate reissuance whenever the set of customers changes (as Jakob notes) You don't need both of these. If you do (1) then the server certificate identifies the MX target host name, so (2) is not necessary. (2) is only necessary if you put the mail domain (MX owner) in the cert, but if you do that then DNSSEC for the MX lookup isn't necessary. Tony. -- f.anthony.n.finch http://dotat.at/ Humber: Northeast 4 or 5. Slight. Occasional rain, fog patches. Moderate or good, occasionally very poor. From ietfdbh@comcast.net Thu May 3 09:27:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6521321F85D8 for ; Thu, 3 May 2012 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cFq+LWCRIkz for ; Thu, 3 May 2012 09:27:27 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8496621F85B7 for ; Thu, 3 May 2012 09:27:27 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id 5UHc1j0050xGWP854UTD4J; Thu, 03 May 2012 16:27:13 +0000 Received: from [192.168.1.120] ([68.98.94.120]) by omta12.westchester.pa.mail.comcast.net with comcast id 5USU1j00W2bpJkL3YUSc7z; Thu, 03 May 2012 16:27:22 +0000 User-Agent: Microsoft-MacOutlook/14.2.0.120402 Date: Thu, 03 May 2012 09:26:28 -0700 From: David Harrington To: Ben Niven-Jenkins , Richard Alimi Message-ID: Thread-Topic: [alto] [apps-discuss] Review of draft-ietf-alto-protocol-11.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Richard Alimi , draft-ietf-alto-protocol.all@tools.ietf.org, alto , apps-discuss@ietf.org Subject: Re: [apps-discuss] [alto] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 16:27:28 -0000 I would also recommend providing a reference rather than duplicating specification, so there is no possibility of conflict between this and the normative spec. -- David Harrington Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 5/2/12 11:59 PM, "Ben Niven-Jenkins" wrote: >Rich, > >On 3 May 2012, at 06:22, Richard Alimi wrote: > >> On Wed, May 2, 2012 at 12:29 PM, Ben Niven-Jenkins >> wrote: >>> >>>> As you asked so nicely, I wonder if the following (slightly wordy) >>>>change would address Ted's comment: >>>> >>>> OLD: >>>> Note that it is possible for an ALTO Server to employ caching for >>>>the >>>> response to a POST request. This can be accomplished by returning >>>>an >>>> HTTP 303 status code ("See Other") indicating to the ALTO Client >>>>that >>>> the resulting Cost Map is available via a GET request to an >>>>alternate >>>> URL (which may be cached). >>>> NEW: >>>> Note that it is possible for an ALTO Server to leverage caching HTTP >>>>intermediaries for responses to both GET and POST requests by >>>>including explicit freshness information (see Section 2.3.1 of >>>>[HTTPBIS Part6]). >>>> >>>> Caching of POST requests is not widely implemented by HTTP >>>>intermediaries, however an alternative approach is for an ALTO Server, >>>>in response to POST requests, to return an HTTP 303 status code ("See >>>>Other") indicating to the ALTO Client that the resulting Cost Map is >>>>available via a GET request to an alternate URL. HTTP intermediaries >>>>that do not support caching of POST requests could then cache the >>>>response to the GET request from the ALTO Client following the >>>>alternate URL in the 303 response (if the response to the subsequent >>>>GET request contains explicit freshness information). >>>> END >> >> This seems reasonable to me, except would it be appropriate to have >> this kind of document dependency? Would it be more appropriate to >> just reference RFC2616? > >Up to you. HTTPBIS is in the process of putting the HTTPBIS specs through >WG LC so there is light at the end of the tunnel for them popping out as >RFCs. I referred to the HTTPBIS document because it's easier to find an >appropriate reference but similar material is in 2616. > >>>> Ted went on to say: >>>>> Since cachability >>>>> is a major reason cited for the re-use of HTTP, some additional text >>>>> on the use cache control directives ("public" and "Max-age" seem >>>>> particularly important in this context) might also be useful. >>>> >>>> I wonder whether a reference to Section 3.2 of HTTPBIS Part6 would >>>>suffice? >> >> Once upon a time, we used to have more detail about how to use HTTP >> (caching in particular) in the ALTO Protocol draft itself. The >> recommendation at that point was to strip out the large majority of it >> and rely on the reference to the HTTP specs being sufficient. > >I seem to remember being one of the people saying to strip it out and >just provide a reference :-) > >Ben > >> >> That said, any pointers to help out implementers are fine with me as >> long as we don't to back to where we were before :) A concise hint or >> direct reference pointing to the cache control directives seems >> reasonable to me unless there are objections. >> >> Thanks for the feedback, >> Rich >> >>>> >>>> Ben >>>> >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >>> _______________________________________________ >>> alto mailing list >>> alto@ietf.org >>> https://www.ietf.org/mailman/listinfo/alto > >_______________________________________________ >alto mailing list >alto@ietf.org >https://www.ietf.org/mailman/listinfo/alto From rbarnes@bbn.com Thu May 3 08:25:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C923521F867A; Thu, 3 May 2012 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jZqOrXxFh9a; Thu, 3 May 2012 08:25:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1763621F866D; Thu, 3 May 2012 08:25:46 -0700 (PDT) Received: from dhcp-192-1-255-166.col.bbn.com ([192.1.255.166]:54441) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPxu8-00088f-GT; Thu, 03 May 2012 11:25:16 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> Date: Thu, 3 May 2012 11:25:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 03 May 2012 09:36:28 -0700 Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, Jakob Schlyter , iesg@ietf.org, paul@nohats.ca Subject: Re: [apps-discuss] [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:25:47 -0000 On May 3, 2012, at 11:07 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 1. 5. 2012, at 8:05, Jakob Schlyter wrote: >=20 >> On 30 apr 2012, at 15:53, Martin Rex wrote: >>=20 >>> When trying to deliver mail to @toad.com, the only secure >>> question to ask is whether the server is authorized to process >>> Email for @toad.com. For certificates issued from the traditional >>> PKIX world, that would require a "toad.com" DNSName SAN. >>=20 >> That would require large hosting provider, e.g. Google Apps, to = update their SMTP TLS certificates each and every time they added or = removed a customer. In my book, that would not scale. I believe we = should focus on securing the transport, not building a TLS-based = application authorization system. >=20 >=20 > And I would add this is out of the scope of the DANE protocol... >=20 > If you want MX fixed, do it. But it is currently broken even just for = TLS. Either there will be some other document which fixes interaction = of SMTP and TLS and throws DANE on top of it, or the MTAs will just cope = ;), but we cannot specify anything which is broken right now. Oh, this discussion again. If you want real assurance that an = outsourced mail server is authorized to operate a mail server, then you = need: 1. DNSSEC on the MX record (in which case the hosting provider can use = his own cert) 2. Certificate reissuance whenever the set of customers changes (as = Jakob notes) This was raised earlier, e.g.: I relented on that discussion only because people seemed to think that = the MX world were comfortable with the spoofing risk, and communities = that were worried about spoofing (e.g., XMPP) could write their own = independent specs. =20 --Richard From ondrej.sury@nic.cz Thu May 3 08:58:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8F221F8601; Thu, 3 May 2012 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOXx6izQdB5P; Thu, 3 May 2012 08:58:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EA53F21F865C; Thu, 3 May 2012 08:58:54 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 3B58B13F9E9; Thu, 3 May 2012 17:58:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336060734; bh=sDQRpdztgMHNX3XCRWEF5p3+mvLO51Jlo4NjzFwc+Sk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GigfEF5qJ+BC+OszH2prmiXR7mjMcyVfC4DTM89euWXVblcA2Z1hkEdKgOblznXaC PzQ3cssFkduD8eBncHIx9r8wT6ZDNWC5VASKSVcnzqXTWDvviSnz/MUZVhM0teMOPh pk/HpKvzN+VvFk0k6L0/bjL87WnZ7mhzRczPxbS4= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> Date: Thu, 3 May 2012 17:58:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 03 May 2012 09:36:40 -0700 Cc: The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [apps-discuss] [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:58:55 -0000 On 3. 5. 2012, at 17:25, Richard L. Barnes wrote: > Oh, this discussion again. No, it's _not_ that discussion again. I wanted to say that we don't _want_ to discuss and fix it in the DANE WG. Somebody fix it elsewhere and come back. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu May 3 08:28:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E1E21F853C; Thu, 3 May 2012 08:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BX1dqG1rg+6; Thu, 3 May 2012 08:28:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D047521F8581; Thu, 3 May 2012 08:27:59 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 2CA6B13F9E9; Thu, 3 May 2012 17:27:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336058879; bh=ACDujBuJItKGpH7EPMG2xiS23L5DWH0D/Gmxx81Qe+M=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aMsgfNbMEklmFPU8QusjYX6UAwhlE/YvgzNAoV8bSckCMhiT68VqtJFP/Www+Sidd lvDPp4/TZ665oYPQQ97w3rNs+DMNpSK0fBruf8saNGFiwmzd3PDU+wngLfbgJCJS08 3XSKJhXpTNMqdAIqPvH3sxxXciAexHSe+zdu35uI= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F96D2AB.6090509@stpeter.im> Date: Thu, 3 May 2012 17:27:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 03 May 2012 09:36:48 -0700 Cc: The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:28:00 -0000 On 24. 4. 2012, at 18:19, Peter Saint-Andre wrote: > Alexey, overnight I realized that this document doesn't say anything > about internationalized domain names (in fact, it doesn't cite any > documents about the definition of "DNS domain name"). So I think at = the > least it needs to provide a citation, e.g. to Section 2.2 of RFC 6125. Peter, I still don't understand why DANE should be different from any other new DNS RR type out there and specifically reference to IDN. RFC 6125 applies to DANE, as it applies to any other new RRtype which was and will be created. I hope you don't suggest we add a reference to RFC 6125 to every document creating a new RRtype? What value it would add to say: "Standard DNS rules applies including the IDN" in the document? I would say that it's implicit and doesn't need an explicit sentence. Chairs (and authors) share the opinion that the document doesn't need an update for IDN. Ondrej -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu May 3 08:07:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602F121F856F; Thu, 3 May 2012 08:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Tn1LltsqI7B; Thu, 3 May 2012 08:07:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0164C21F84B5; Thu, 3 May 2012 08:07:16 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 4D3C013F9E9; Thu, 3 May 2012 17:07:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336057635; bh=6/NOMAga4vpuBi8ceE0WstqVBrdAYbOsp/QSc0VR6Io=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d+9rd7ZTjZFWHZWtkNSmePYV3HeYcPn6ig3mfZKDyZRpM4kzrsK8sX5gcg7b40Kcr 2HoaIimLrBBZUikNOf0+4Fw9Qverc9nMODdY+lL07EiO0RHpIQFqvOreZsyk75lV2E /iIugS9TQPAK/mJBmcUyWFucpBxUoXI+jwp0LCsQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> Date: Thu, 3 May 2012 17:07:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 03 May 2012 09:36:51 -0700 Cc: mrex@sap.com, apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, paul@nohats.ca Subject: [apps-discuss] MX and DANE (Was: [dane] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:07:17 -0000 On 1. 5. 2012, at 8:05, Jakob Schlyter wrote: > On 30 apr 2012, at 15:53, Martin Rex wrote: >=20 >> When trying to deliver mail to @toad.com, the only secure >> question to ask is whether the server is authorized to process >> Email for @toad.com. For certificates issued from the traditional >> PKIX world, that would require a "toad.com" DNSName SAN. >=20 > That would require large hosting provider, e.g. Google Apps, to update = their SMTP TLS certificates each and every time they added or removed a = customer. In my book, that would not scale. I believe we should focus on = securing the transport, not building a TLS-based application = authorization system. And I would add this is out of the scope of the DANE protocol... If you want MX fixed, do it. But it is currently broken even just for = TLS. Either there will be some other document which fixes interaction = of SMTP and TLS and throws DANE on top of it, or the MTAs will just cope = ;), but we cannot specify anything which is broken right now. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu May 3 08:12:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C5621F8603; Thu, 3 May 2012 08:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmR3OA4S0waW; Thu, 3 May 2012 08:12:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A7B6221F8601; Thu, 3 May 2012 08:12:26 -0700 (PDT) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 0D42613F9E9; Thu, 3 May 2012 17:12:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1336057946; bh=E6gFYoHePVYqL7CxC9ifiRpSPYJL4aMUUFKhrlGJ+Jk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rSOi+vGYogs8EjKsLO3AkUjjE2lTWDvb9FRPkFg3BAjXi1MmjHmsd4moCSYjWdHnU iF4KttXs+BMcHKgD/wBjIDPUwyX9Dlk4s0rc/uQLm14G0A3+LGBaunCS4TL+hh1/xN XYESRlR1eO2mJYt685iQFmUGXkaX/GIyNYImmL8s= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> Date: Thu, 3 May 2012 17:12:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2861796C-6DBC-4CEF-A1AF-CC9DBF42CE9C@nic.cz> References: <201205021359.q42DxVtm018679@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 03 May 2012 09:36:51 -0700 Cc: The IESG , apps-discuss@ietf.org, dane list Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:12:27 -0000 Martin and all other, On 2. 5. 2012, at 15:59, Martin Rex wrote: > Mark Andrews wrote: >>=20 >> Tony Finch writes: >>>=20 >>> Ned Freed wrote: >>>>=20 >>>> But even this may not be acceptable for all I know. It may turn out >>>> that using DANE to secure the terminal A/AAAA records (modulo = CNAMEs) >>>> is actually an acceptable default for SRV/MX/NATPR-based services. >>>> I could easily be wrong, but it seems to me that this is what all >>>> this additional discussion is about. >>>=20 >>> I don't think it's as simple as that because RFC 6125 says = certificates >>> should match the SRV owner name not the target name. See also Dave >>> Cridland's comments about XMPP. >>=20 >> Should !=3D must. >=20 > I think that is a misunderstanding. >=20 > The XMPP document may explicitly account for a local policy to = override > the decision to continue communication because of a mismatch and chose > "should" over "must" for that, assuming that MUST is unconditional > and not subject to local policy. >=20 > Some specifications in the security area (and PKIX in particular) > use a different approach, using MUST all over the place, silently > assuming that local policy overrides MUSTS in specs all the time... > (and some of the language in DANE-protocol is the same, generously > sprinkling MUST all over the place, and causing confusion about > when a MUST is really a MUST (i.e. not subject to local policy). >=20 > Personally, I prefer shoulds to musts for situations where local > policy is supposed to apply. Is this still related to review of DANE protocol? It seems to me it's = not. Please change the subject, if you want to discuss this further, and cut = down the Cc list (I don't mind discussing this in the DANE WG list, if it's = clear it's not related to the review, but you talk about XMPP/SRV/etc.) -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From alexey.melnikov@isode.com Thu May 3 10:37:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAA621F865B for ; Thu, 3 May 2012 10:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cxx-idluTAb for ; Thu, 3 May 2012 10:37:20 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 110DB21F8657 for ; Thu, 3 May 2012 10:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1336066638; d=isode.com; s=selector; i=@isode.com; bh=GnUymmzgpS1Ow/2oqVkApX/t9oeLiFhffg0p8WJtrLo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NBbHDlgl/vexlJPSv33NKnhKvwqyC887VMoBjSHs7kGdIbv5sW/Mf8apvxDOI180SdQHKq inNfWYCReU09TqHBvXUWGYAi0i2Z3W5f457tVLYH4Vz7XCD8pbR2FzU/dO9yh/0SOaZAHg Qmv8c0wuZEoSHUFwZDVZu4hPkzJ3FRU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 3 May 2012 18:37:18 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FA2C270.4050906@isode.com> Date: Thu, 03 May 2012 18:37:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: apps-discuss@ietf.org References: <4F96E203.5060105@isode.com> In-Reply-To: <4F96E203.5060105@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Call for Adoption: draft-kucherawy-received-state-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 17:37:21 -0000 On 24/04/2012 18:25, Alexey Melnikov wrote: > Murray presented this draft in at least one of the face to face IETF > meetings and my recollection is that general feedback on this document > was positive. So I would like to initiate acceptance call for > processing this document in the APPSAWG. > > Please indicate your support or objection, and opinions thereto before > the close of business on May 1st. I've seen mostly expression of support. Also an earlier discussion in January indicated that a few more people were interested in working on this document in the APPSAWG. So I conclude that the document is accepted by the WG. > Alexey, as an APPSAWG co-chair From internet-drafts@ietf.org Thu May 3 10:44:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77B921F866E; Thu, 3 May 2012 10:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkk5jwAYG58D; Thu, 3 May 2012 10:44:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CCE21F8639; Thu, 3 May 2012 10:44:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120503174454.8723.16142.idtracker@ietfa.amsl.com> Date: Thu, 03 May 2012 10:44:54 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 17:44:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Indicating Email Handling States in Trace Fields Author(s) : D. Crocker Murray S. Kucherawy Filename : draft-ietf-appsawg-received-state-00.txt Pages : 11 Date : 2012-05-03 This memo registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, or other similar causes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-received-state-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-received-state-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-received-state/ From msk@cloudmark.com Thu May 3 10:55:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D25221F8646 for ; Thu, 3 May 2012 10:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9HJm7ksRdDZ for ; Thu, 3 May 2012 10:55:32 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id E012D21F85ED for ; Thu, 3 May 2012 10:55:32 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 5VvM1j0010ZaKgw01VvYmT; Thu, 03 May 2012 10:55:32 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=bcDpoZzB c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=YEQFarZpzVEA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=IN2j5il-0TmhvD1bkOcA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 3 May 2012 10:55:24 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: I-D Action: draft-ietf-appsawg-received-state-00.txt Thread-Index: AQHNKVR3ogbod2/1JUqVUhGVW0U1AJa4WK7Q Date: Thu, 3 May 2012 17:55:24 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810BA1A@exch-mbx901.corp.cloudmark.com> References: <20120503174454.8723.16142.idtracker@ietfa.amsl.com> In-Reply-To: <20120503174454.8723.16142.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336067732; bh=4C5RXEOYzajEWGJMQG6EesB18AMoY0slnsf54naKkIo=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=nH2PdPRnZC4fRQfpvPvhL/NSWnKH+U6rNY7taiyo/0ir9NrWbIVjaR2kfXb1Mly1z RljQUgQrWxs9yp54vx3Fb5dAFPTxgU7F4FegRbYUl1XepFIf30QYYTA0CoJ7O3AGTo vvdy9ysGgLX7Ygp+nKbTVatg1aG5oPc+t0096+s8= Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 17:55:33 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, May 03, 2012 10:45 AM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: I-D Action: draft-ietf-appsawg-received-state-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. >=20 > Title : Indicating Email Handling States in Trace Fields > Author(s) : D. Crocker > Murray S. Kucherawy > Filename : draft-ietf-appsawg-received-state-00.txt > Pages : 11 > Date : 2012-05-03 >=20 > This memo registers a trace field clause for use in indicating > transitions between handling queues or processing states, including > enacting inter- and intra-host message transitions. This might > include message quarantining, mailing list moderation, timed > delivery, queueing for further analysis, or other similar causes. This got a couple of rounds of development prior to becoming a working grou= p document, but that was a few months ago. I'd love some fresh eyes on it = and some new reviews. Or if you think it's pretty well-baked already, plea= se do say so. I know John Klensin had some more general concerns in the area of trace dat= a, but I seem to recall that we landed on the fact that it was a general co= ncern, and not something specific to this proposal. So we should have that= conversation as well, perhaps, and I'll let him get it re-started if he wi= shes. -MSK From dhc@dcrocker.net Thu May 3 11:22:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F378421F8636 for ; Thu, 3 May 2012 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1+Nt+7UxdB6 for ; Thu, 3 May 2012 11:22:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6164521F8630 for ; Thu, 3 May 2012 11:22:00 -0700 (PDT) Received: from [10.2.4.28] ([64.9.249.121]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q43ILw17028150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 3 May 2012 11:21:59 -0700 Message-ID: <4FA2CCC1.50209@dcrocker.net> Date: Thu, 03 May 2012 11:21:53 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20120503174454.8723.16142.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E00392810BA1A@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392810BA1A@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 03 May 2012 11:21:59 -0700 (PDT) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-received-state-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 18:22:01 -0000 On 5/3/2012 10:55 AM, Murray S. Kucherawy wrote: > This got a couple of rounds of development prior to becoming a working group document, but that was a few months ago. I'd love some fresh eyes on it and some new reviews. Or if you think it's pretty well-baked already, please do say so. +1 to the request. It will help to distinguish between basic, philosophical concerns, versus issues with the details. As the name of the field implies, it was originally targeting a very specific event, roughly characterized as "coming into the MTA". This new draft clearly (and I hope explicitly) expands the scope to cover any handling transition that the message undergoes that is worth recording. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Thu May 3 12:52:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A3821F8615; Thu, 3 May 2012 12:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hWgnppUO5eZ; Thu, 3 May 2012 12:52:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7973C21F861D; Thu, 3 May 2012 12:52:20 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C0D894005B; Thu, 3 May 2012 14:07:21 -0600 (MDT) Message-ID: <4FA2E1F2.6060406@stpeter.im> Date: Thu, 03 May 2012 13:52:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 19:52:22 -0000 On 5/3/12 9:27 AM, Ondřej Surý wrote: > On 24. 4. 2012, at 18:19, Peter Saint-Andre wrote: >> Alexey, overnight I realized that this document doesn't say anything >> about internationalized domain names (in fact, it doesn't cite any >> documents about the definition of "DNS domain name"). So I think at the >> least it needs to provide a citation, e.g. to Section 2.2 of RFC 6125. > > > Peter, > > I still don't understand why DANE should be different from any other > new DNS RR type out there and specifically reference to IDN. RFC 6125 > applies to DANE, as it applies to any other new RRtype which was and > will be created. I hope you don't suggest we add a reference to RFC > 6125 to every document creating a new RRtype? > > What value it would add to say: "Standard DNS rules applies including > the IDN" in the document? I would say that it's implicit and doesn't > need an explicit sentence. > > Chairs (and authors) share the opinion that the document doesn't need > an update for IDN. Ahoj Ondřej, Perhaps this is simply a difference between folks who look at things from the DNS perspective and folks who look at things from the apps perspective (as users of DNS). All sorts of application protocols are being updated to support IDNs. Those applications will need to know how to translate their IDNs (which might consist of U-labels) into a form that can be placed into the DNS. To make things perfectly clear, I'm just suggesting that we add a sentence or two warning those who write code for application protocols using DANE that they might need to convert U-labels into A-labels. I'll work to propose specific text today or tomorrow. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Thu May 3 13:34:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B73821F86B1; Thu, 3 May 2012 13:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o4fiIjEcafA; Thu, 3 May 2012 13:34:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8273621F86B0; Thu, 3 May 2012 13:34:31 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q43KYTTM077432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 May 2012 13:34:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA2E1F2.6060406@stpeter.im> Date: Thu, 3 May 2012 13:34:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 20:34:32 -0000 On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: > Perhaps this is simply a difference between folks who look at things > from the DNS perspective and folks who look at things from the apps > perspective (as users of DNS). All sorts of application protocols are > being updated to support IDNs. Those applications will need to know = how > to translate their IDNs (which might consist of U-labels) into a form > that can be placed into the DNS. To make things perfectly clear, I'm > just suggesting that we add a sentence or two warning those who write > code for application protocols using DANE that they might need to > convert U-labels into A-labels. I'll work to propose specific text = today > or tomorrow. I'll be interested to see that. I cannot see how anyone reading Section = 3 of RFC 5891 could think that they would *not* need to convert to = A-labels before looking up something in the DNS. If you are saying that = every post-5891 protocol that defines a new RRtype must say "and if you = are going to look up the domain name in the DNS, convert to A-labels = first", that's fine, but it seems kinda late to start saying that. --Paul Hoffman From sm@resistor.net Thu May 3 14:27:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEAA21F85D3; Thu, 3 May 2012 14:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF2yJIEPUDc2; Thu, 3 May 2012 14:27:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD68521F8592; Thu, 3 May 2012 14:27:33 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q43LRPD5003550; Thu, 3 May 2012 14:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336080452; i=@resistor.net; bh=Cp4NzOfkwoiY7Mee3yJKAMy48yr/SxqTz5aF87p5Stc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=P54whtoL7zNUNwiA1IY+KoUAIgu9B2OuyaiSuJ6/G/yhEUtUGG/taMCMPz//zBDpH qjp7Hn5RbviZOLG+NrDyxAXwyNwRoEpmxMeOQNBWzvI8TQXZDmSPsFPHGnX6bhYN+8 c8cQ1XEUHtP51lTlcFv09f5VMmmE4BbjVvJeTI0E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336080452; i=@resistor.net; bh=Cp4NzOfkwoiY7Mee3yJKAMy48yr/SxqTz5aF87p5Stc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3DVJNbIFFwq1Yty7KwRrmOYqGTwzPJckfe1CRaVZMX/5k2cXgYF6iqea1zuDsEzUN KaQlkxApOwWEmFyeRV42aC2D+nzt3Sk6N1GJEUJJtyQ7i1ngRLd41KisVFgMedy9aC dQ9WFYGunHRRoFPt7N8VC6u2FfZYTWZzXlJOaazc= Message-Id: <6.2.5.6.2.20120503130631.097d25d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 May 2012 14:26:37 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <4FA0335E.7090306@stpeter.im> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 21:27:34 -0000 Hi Peter, At 12:02 01-05-2012, Peter Saint-Andre wrote: > >> I still think that this document needs to say something about > >> IDNs. Section 3 of draft-ietf-dane-protocol-20 uses "domain name". The reference is likely RFC 1035. The problem with DANE is that it touches application layer protocols by using host names (see the examples). RFC 1123 is applicable then. If you want to support internationalization, you then end up using RFC 5890. Should the question about whether STD 13 supports IDN, everyone knows what the answer will be. :-) The note in Section 1.3 could be extended as a separate paragraph: This document does not cover how to associate certificates with domain names for application protocols that depend on MX, SRV, NAPTR, and similar DNS resource records; it is expected that later updates to this document might cover methods for making those associations. Note that legacy application specifications (e.g., SMTP [RFC5321] and HTTP [RFC2616]) do not permit non-ASCII labels in DNS domain names used with those protocols, i.e., only the A-label form of IDNs is permitted in those contexts. Section 2.2 of RFC 6125 discusses about DNS domain name used by an application service. [sentence borrowed from RFC 5890] Somewhere during the discussion of the AppsDir reviews, Alexey asked an interesting question: what is a "DNS domain name". The question was not fully answered. The "fix", if anyone thinks it is worthwhile, would be to get an answer in the context of Section 3 of the draft and adapt the hand-waving accordingly. Regards, -sm From stpeter@stpeter.im Thu May 3 14:41:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44BA21F86DC; Thu, 3 May 2012 14:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfgFVN0PBRyX; Thu, 3 May 2012 14:41:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E75A21F86D5; Thu, 3 May 2012 14:41:45 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A70C540058; Thu, 3 May 2012 15:56:43 -0600 (MDT) Message-ID: <4FA2FB94.204@stpeter.im> Date: Thu, 03 May 2012 15:41:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> In-Reply-To: <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 21:41:45 -0000 On 5/3/12 2:34 PM, Paul Hoffman wrote: > On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: > >> Perhaps this is simply a difference between folks who look at >> things from the DNS perspective and folks who look at things from >> the apps perspective (as users of DNS). All sorts of application >> protocols are being updated to support IDNs. Those applications >> will need to know how to translate their IDNs (which might consist >> of U-labels) into a form that can be placed into the DNS. To make >> things perfectly clear, I'm just suggesting that we add a sentence >> or two warning those who write code for application protocols using >> DANE that they might need to convert U-labels into A-labels. I'll >> work to propose specific text today or tomorrow. > > > I'll be interested to see that. I cannot see how anyone reading > Section 3 of RFC 5891 could think that they would *not* need to > convert to A-labels before looking up something in the DNS. If you > are saying that every post-5891 protocol that defines a new RRtype > must say "and if you are going to look up the domain name in the DNS, > convert to A-labels first", that's fine, but it seems kinda late to > start saying that. Not everyone is as smart as you are. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Thu May 3 14:47:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621C121F864B; Thu, 3 May 2012 14:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75kWnH4Txcdx; Thu, 3 May 2012 14:47:34 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E431321F8643; Thu, 3 May 2012 14:47:33 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F07051ECB41C; Thu, 3 May 2012 21:47:32 +0000 (UTC) Date: Thu, 3 May 2012 17:47:23 -0400 From: Andrew Sullivan To: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Message-ID: <20120503214643.GB1804@mail.yitter.info> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> <6.2.5.6.2.20120503130631.097d25d8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120503130631.097d25d8@resistor.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 21:47:34 -0000 On Thu, May 03, 2012 at 02:26:37PM -0700, SM wrote: > Hi Peter, > Section 3 of draft-ietf-dane-protocol-20 uses "domain name". The > reference is likely RFC 1035. The problem with DANE is that it > touches application layer protocols by using host names (see the > examples). RFC 1123 is applicable then. If you want to support > internationalization, you then end up using RFC 5890. Should the > question about whether STD 13 supports IDN, everyone knows what the > answer will be. :-) I don't think that the examples (I presume you mean "in that section", since the examples in Appx C aren't DNS names) are normative, and as nearly as I can tell nothing about section 3 is restricted to the host name syntax. It's true that if you want to use IDNA with DANE then you have to do it using A-labels. I don't really get why any of that needs to go into the protocol document, though. This is a document about how you do stuff in the DNS, and that means you have to do it in a DNS-y way. No? A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Thu May 3 14:59:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475CE21F86F7; Thu, 3 May 2012 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ej1lKeyDJ5i; Thu, 3 May 2012 14:59:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE2E021F86E1; Thu, 3 May 2012 14:59:28 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q43LxRZt080690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 May 2012 14:59:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA2FB94.204@stpeter.im> Date: Thu, 3 May 2012 14:59:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 21:59:29 -0000 On May 3, 2012, at 2:41 PM, Peter Saint-Andre wrote: > On 5/3/12 2:34 PM, Paul Hoffman wrote: >> On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: >>=20 >>> Perhaps this is simply a difference between folks who look at >>> things from the DNS perspective and folks who look at things from >>> the apps perspective (as users of DNS). All sorts of application >>> protocols are being updated to support IDNs. Those applications >>> will need to know how to translate their IDNs (which might consist >>> of U-labels) into a form that can be placed into the DNS. To make >>> things perfectly clear, I'm just suggesting that we add a sentence >>> or two warning those who write code for application protocols using >>> DANE that they might need to convert U-labels into A-labels. I'll >>> work to propose specific text today or tomorrow. >>=20 >>=20 >> I'll be interested to see that. I cannot see how anyone reading >> Section 3 of RFC 5891 could think that they would *not* need to >> convert to A-labels before looking up something in the DNS. If you >> are saying that every post-5891 protocol that defines a new RRtype >> must say "and if you are going to look up the domain name in the DNS, >> convert to A-labels first", that's fine, but it seems kinda late to >> start saying that. >=20 > Not everyone is as smart as you are. If you believe that developers who are using IDNs are not following the = easiest-to-read section of RFC 5891, the issue is much larger than just = DANE. I propose that is not a DANE issue at all. --Paul Hoffman From sm@resistor.net Thu May 3 15:07:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229E421F8705; Thu, 3 May 2012 15:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FO2vYTWC+EFv; Thu, 3 May 2012 15:07:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C25F21F8702; Thu, 3 May 2012 15:07:35 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q43M7QAQ018787; Thu, 3 May 2012 15:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336082853; i=@resistor.net; bh=zum396/mnt9aW03dpcIu7LrOhxO8VdinVsAdAeojKfc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=05kXBYc3FvOABWeRBUOwvh7rSJNgHwfAYlfuSJxcpqHC3waMH1lpoAoiFxO5aPNNy XQv+y3nJTSM/i0v0yZBkd5fwHNLEoo1bxhfPUvVH240d34M+IKCgZRgIf6rpS/Dtf7 0QwtOhj8MDoQRpOSL2ye5exXNQ/tMqG3D9x2REkY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336082853; i=@resistor.net; bh=zum396/mnt9aW03dpcIu7LrOhxO8VdinVsAdAeojKfc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X5dLuOESxYVMHzLXEfeBc2912koAbhvNCHefPzhUvxqqVimOTshG0NTkH4QJDWhpY NBNWNl8/IekSepZirTJdEXgQo83/GpUBuiXXUhT0tsabFW7q7kJL1dfd3oPS4SuSiC NGoRfXvECpA2bKgX+iQDZnNyWRE/s7oLdR91LHXE= Message-Id: <6.2.5.6.2.20120503145303.09a25d30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 May 2012 15:03:58 -0700 To: Andrew Sullivan From: SM In-Reply-To: <20120503214643.GB1804@mail.yitter.info> References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <4FA0335E.7090306@stpeter.im> <6.2.5.6.2.20120503130631.097d25d8@resistor.net> <20120503214643.GB1804@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 22:07:37 -0000 Hi Andrew, At 14:47 03-05-2012, Andrew Sullivan wrote: >I don't think that the examples (I presume you mean "in that section", >since the examples in Appx C aren't DNS names) are normative, and as I understand that. >nearly as I can tell nothing about section 3 is restricted to the host >name syntax. It's true that if you want to use IDNA with DANE then >you have to do it using A-labels. I don't really get why any of that >needs to go into the protocol document, though. This is a document >about how you do stuff in the DNS, and that means you have to do it in >a DNS-y way. No? Peter posted a message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05577.html which in my opinion explains the application perspective. If you go by RFC 4398, yes. The problem with the DNS way is that it pushes issues to the application side and the reverse is also valid. Regards, -sm From stpeter@stpeter.im Thu May 3 15:33:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EA621F8705; Thu, 3 May 2012 15:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jiiUHF0-PYT; Thu, 3 May 2012 15:33:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 672E921F8702; Thu, 3 May 2012 15:33:40 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 893B340058; Thu, 3 May 2012 16:48:42 -0600 (MDT) Message-ID: <4FA307C2.1090209@stpeter.im> Date: Thu, 03 May 2012 16:33:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> In-Reply-To: <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 22:33:41 -0000 On 5/3/12 3:59 PM, Paul Hoffman wrote: > On May 3, 2012, at 2:41 PM, Peter Saint-Andre wrote: > >> On 5/3/12 2:34 PM, Paul Hoffman wrote: >>> On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: >>> >>>> Perhaps this is simply a difference between folks who look at >>>> things from the DNS perspective and folks who look at things >>>> from the apps perspective (as users of DNS). All sorts of >>>> application protocols are being updated to support IDNs. Those >>>> applications will need to know how to translate their IDNs >>>> (which might consist of U-labels) into a form that can be >>>> placed into the DNS. To make things perfectly clear, I'm just >>>> suggesting that we add a sentence or two warning those who >>>> write code for application protocols using DANE that they might >>>> need to convert U-labels into A-labels. I'll work to propose >>>> specific text today or tomorrow. >>> >>> >>> I'll be interested to see that. I cannot see how anyone reading >>> Section 3 of RFC 5891 could think that they would *not* need to >>> convert to A-labels before looking up something in the DNS. If >>> you are saying that every post-5891 protocol that defines a new >>> RRtype must say "and if you are going to look up the domain name >>> in the DNS, convert to A-labels first", that's fine, but it seems >>> kinda late to start saying that. >> >> Not everyone is as smart as you are. > > If you believe that developers who are using IDNs are not following > the easiest-to-read section of RFC 5891, the issue is much larger > than just DANE. I propose that is not a DANE issue at all. I believe nothing -- I'm just saying that I am no longer surprised by what folks do or do not know. I see no harm in including a sentence or two sending folks in the right direction. Peter -- Peter Saint-Andre https://stpeter.im/ From marka@isc.org Thu May 3 17:02:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D421F867A; Thu, 3 May 2012 17:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YJhGzie+q9j; Thu, 3 May 2012 17:02:52 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1A51521F864F; Thu, 3 May 2012 17:02:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E06955F9A09; Fri, 4 May 2012 00:02:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:ada5:f16c:1a15:3716]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2D496216C33; Fri, 4 May 2012 00:02:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0F9632063979; Fri, 4 May 2012 10:02:20 +1000 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> <4874649B-01B4-4642-A3C0-F4CDFE87C85B@nic.cz> <9CB47D95-DF49-4B4A-875B-E2EED9E626A7@bbn.com> In-reply-to: Your message of "Thu, 03 May 2012 17:58:54 +0200." Date: Fri, 04 May 2012 10:02:19 +1000 Message-Id: <20120504000220.0F9632063979@drugs.dv.isc.org> Cc: "Richard L. Barnes" , The IESG , apps-discuss@ietf.org, IETF DANE WG list Subject: Re: [apps-discuss] [dane] MX and DANE (Was: AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 00:02:52 -0000 In message , =?utf-8?Q?Ond=C5=99ej _Sur=C3=BD?= writes: > On 3. 5. 2012, at 17:25, Richard L. Barnes wrote: > > Oh, this discussion again. > > No, it's _not_ that discussion again. I wanted to say that we > don't _want_ to discuss and fix it in the DANE WG. Somebody fix > it elsewhere and come back. While this isn't be a issue for DANE, DANE actually *removes* the last known threat, downgrade by filtering/not offering STARTTLS from the EHLO response, to making MX and STARTTLS work globally as it provides a method to signal that TLS should be available and as a consequence you should see a STARTTLS. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ned.freed@mrochek.com Thu May 3 18:36:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B990D11E8085; Thu, 3 May 2012 18:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJXi3MJNpiAL; Thu, 3 May 2012 18:36:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1FE11E8073; Thu, 3 May 2012 18:36:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF210DXHJK000UL2@mauve.mrochek.com>; Thu, 3 May 2012 18:36:21 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Thu, 3 May 2012 18:36:18 -0700 (PDT) Message-id: <01OF210BT32G0006TF@mauve.mrochek.com> Date: Thu, 03 May 2012 18:16:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 03 May 2012 14:59:26 -0700" <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> To: Paul Hoffman Cc: "apps-discuss@ietf.org Discuss" , The IESG , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 01:36:39 -0000 > If you believe that developers who are using IDNs are not following the > easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I > propose that is not a DANE issue at all. I completely agree, but additionally, the model of trying to cover all the possible ancillary material that some developer might possibly be unaware of is simply unsustainable. Were we to attempt it, we'd end up with every specification stuff with huge amounts of "see also" material irrelevant to the specification itself. And it will cause more problems than it solves. No, the question isn't whether someone without clue is going to read this specification and miss something important. That's going to happen no matter what. Rather, the question is whether or not it is at all likely that adding a particular pointer will actually make a significant difference. I don't think this suggestion rises to that level. Consider: TLSA records appear next to A, AAAA, or CNAME records, and have to have the same names as those records (modulo wildcards). Therefore an IDN name in a TLSA record means the A/AAAA/CNAME record also has, and more likely already had, an IDN name. That in turn means that the IDN issue has already been faced/addressed. So there doesn't seem to be much value here. Of course you can come up with scenarios where different people provision the different records, or the provisioning interface has different behavior for different kinds of records, and so on and so forth. But are these scenarios likely? I don't think so. Indeed, I suspect the bigger problem will be the lack of builtin support for TLSA records in deployed nameserver software. So if you want to address the more likely deployment problem for the less than clueful, you should be arguing for a reference to something that explains how to use the arbitrary record support in the more popular nameservers. (Or alternately, we could actually look at, you know, solving the problem. See John Levine's draft.) Ned From evnikita2@gmail.com Thu May 3 23:40:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EBE21F86E1 for ; Thu, 3 May 2012 23:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=1.376, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cR-evdwoZXd for ; Thu, 3 May 2012 23:40:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFD2921F86DF for ; Thu, 3 May 2012 23:40:05 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4208569obb.31 for ; Thu, 03 May 2012 23:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=A09O9R0hRZwyK0hATdA+3vhSGtkkdvsuW8g3sNUrwB0=; b=cDGspZ2oDLzdd7V7Ag5BbYgcHpwyj4xTfrvNJ0dXt2xxJTx/kQCyg7C1yCuoXVwUAs N7O7iD1jbY1ElqMDMi0K3Kwl2rkG3z1u4Q6NhuHCnGIPz7qtfHfD72lXNhW5mWG3kKuh 0sSqdX0qmFJepmKOvoTKS79cvAcCqxIxA3Oesgswd615IGlLBSj1MS5NZhbFSFSUCW03 gaLlA5c2CrsnoOIr+36q5dUTVY54T41iXr5lfBy61k/iXdGecC5XhZf9u9Ai1I8qNlQX bmTVrBWEuJj1aAFAJKuzWcJs5G3iJywYja8ouLKlnz1V2sdUUPDv0z8uYjAJDm9bat2j 7JOA== MIME-Version: 1.0 Received: by 10.60.27.38 with SMTP id q6mr6848403oeg.20.1336113605260; Thu, 03 May 2012 23:40:05 -0700 (PDT) Received: by 10.182.8.230 with HTTP; Thu, 3 May 2012 23:40:05 -0700 (PDT) Date: Fri, 4 May 2012 08:40:05 +0200 Message-ID: From: Mykyta Yevstifeyev To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] 'about' URI scheme draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 06:40:06 -0000 Hi, This is to let you know that I'm going to be offline for some 1.5 week or more, so I won't be able to paritipate is discussing the 'about' URI scheme draft, whose editor I am, and which has just ended IETF LC. Though I might be able to read some messages, I won't be able to respond. So I'd like to ask you not to take any action with respect to this document until all LC comments are resolved via my responding to those messages and posting a new version (and I guess we'll need a 2nd LC as there were many comments on this document's intended status, I mean changing it to Infrormational). Sincerely, Mykyta Yevstifeyev From barryleiba.mailing.lists@gmail.com Thu May 3 23:59:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B1A21F86DB for ; Thu, 3 May 2012 23:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.78 X-Spam-Level: X-Spam-Status: No, score=-102.78 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4AhRAtKESFi for ; Thu, 3 May 2012 23:59:50 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91B21F86D8 for ; Thu, 3 May 2012 23:59:50 -0700 (PDT) Received: by eeke51 with SMTP id e51so787258eek.31 for ; Thu, 03 May 2012 23:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sbsE7pO+bC0mvbwPTXbLt5DazE8bacbNLo7zGLMwKtI=; b=mGC6TxvSSUzvwkvKKKw9vlO389J1re3Z/uj1H6Xb6tLT8xbr0w8k8kVx6jikWA5Q6k xpfdSt1AmakMuJPjGXVv1TWWaKZO+KpOzQ/B73GxvxTAZ+hpC71Y8/7yMbmQxS6Z9gd8 Hz15A8PJa8SEhrE/VHV6ohdMVNnj8qrii5EsOiDJDFUOhpPMkFHTnbemeN+NbhC3b7+I TlKGANnacc2dbAbzzYq8KIvIEna9mtLA2fwgIJyoGFWPCA4XRPZYcBszpCr1y/TKE2wV Ur+ZRwTmsmKT/AbTn1b7SPh/ILqHtNZ7L7qu+XN+rNhv76ki+s8sHdRsv6NBg+iRhCrg lGHw== MIME-Version: 1.0 Received: by 10.14.133.81 with SMTP id p57mr928795eei.22.1336114789577; Thu, 03 May 2012 23:59:49 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.14.225.2 with HTTP; Thu, 3 May 2012 23:59:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 May 2012 02:59:49 -0400 X-Google-Sender-Auth: 09p9jnXFMiqoNGhfQqSS_BM9sB8 Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: multipart/alternative; boundary=20cf303a31e169723b04bf307710 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] 'about' URI scheme draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 06:59:56 -0000 --20cf303a31e169723b04bf307710 Content-Type: text/plain; charset=ISO-8859-1 > So I'd like to ask you not to take any action with respect > to this document until all LC comments are resolved via my responding > to those messages and posting a new version I tentatively have it scheduled for the telechat on 24 May. If we can't resolve everything and post a new version by 18 May, I'll move it out to the next telechat after. > (and I guess we'll need a > 2nd LC as there were many comments on this document's intended > status, I mean changing it to Infrormational). No, we don't need a new last call for that reason. If we last-call a doc as Informational, and then want to move it to Standards Track, we need a second last call. We don't need to do that if we *downgrade* the intended status. That's exactly why I last-called it at Proposed Standard. Now, depending upon the evaluation of the chairs and the AD as to the result of last call and the extent of the changes, we might do a second last call. But that wouldn't be for the status change. Barry, responsible AD --20cf303a31e169723b04bf307710 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > So I'd like to ask you not = to take any action with respect
> to this document until all LC comme= nts are resolved via my responding
> to those messages and posting a = new version

I tentatively have it scheduled for the telechat o= n 24 May. =A0If we can't resolve everything and post a new version by 1= 8 May, I'll move it out to the next telechat after.=

> (and I guess we'll need a
= > 2nd LC as there were many comme= nts on this document's intended
> status, I=A0mean changing = it to Infrormational).

No, we don= 't need a new last call for that reason. =A0If we last-call a doc as In= formational, and then want to move it to Standards Track, we need a second = last call. =A0We don't need to do that if we *downgrade* the intended s= tatus. =A0That's exactly why I last-called it at Proposed Standard.

Now, depending upon the evaluation of the cha= irs and the AD as to the result of last call and the extent of the changes,= we might do a second last call. =A0But that wouldn't be for the status= change.

Barry, responsible AD
=
--20cf303a31e169723b04bf307710-- From melvincarvalho@gmail.com Fri May 4 02:02:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DBC21F86C2 for ; Fri, 4 May 2012 02:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEWOYMf6yhWa for ; Fri, 4 May 2012 02:02:46 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0995521F8531 for ; Fri, 4 May 2012 02:02:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2249584vbb.31 for ; Fri, 04 May 2012 02:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kgCHSWHXXkzh9GTAd9m0iZvbfLZOOoRdY+1ps3abJKo=; b=TUC2VbYUXIJx/XUX1nMMsri1ysxl2XVXL1dKB1RnZ+jpTkTZk/Jl+8BlTJwNLvQAz2 rrZm77f0TeK4CcIRtG32To6LxQaR4cVaxjIlMzFM8UCKoDjmKY7r5CeUlexmr0TH2VYL 4VIYyJ60r1zxeLGEn0xXTZlYxW1R9wYYUNNRgoKuHH62BL3D6PpLfM4vNdDJidhwt3Zk EZtyS06MGCXmJaaatAjLgr0PAuckt2hU4lhlDmQSMdDmAUzgLYtC/BkOl0d7jfwiYOdB chXQFfN7TSD+jNyaFGem0OAmitTQ3eNpwKIVOrxLv//2LcmZJXqQ6VbUiLa91an122Ky BKKQ== MIME-Version: 1.0 Received: by 10.52.97.41 with SMTP id dx9mr2557116vdb.89.1336122162380; Fri, 04 May 2012 02:02:42 -0700 (PDT) Received: by 10.52.70.98 with HTTP; Fri, 4 May 2012 02:02:42 -0700 (PDT) In-Reply-To: <4FA2870D.1090407@packetizer.com> References: <4FA0F384.5050008@packetizer.com> <4FA11C4B.2000202@packetizer.com> <4FA2870D.1090407@packetizer.com> Date: Fri, 4 May 2012 11:02:42 +0200 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf307f3806dd7de804bf322e0a Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:02:48 -0000 --20cf307f3806dd7de804bf322e0a Content-Type: text/plain; charset=ISO-8859-1 On 3 May 2012 15:24, Paul E. Jones wrote: > On 5/3/2012 4:44 AM, Melvin Carvalho wrote: > > > > On 2 May 2012 13:36, Paul E. Jones wrote: > >> On 5/2/2012 7:08 AM, Melvin Carvalho wrote: >> >>> One thing that would be a kind of joint problem statement, of the main >>> thing that's trying to be solved. >>> >> >> Is this not understood? Keep in mind that this was not fabricated last >> week. I've been personally interacting with people working on WebFinger >> for a couple of years (or more) now. The idea is all about discovery. >> Given a URI, what can you learn about it? This resulted in the creation >> of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along the >> way. Definitely, the web linking document (RFC 5988) is also an important >> part of this. >> >> >> I think this started out as a way for webmail providers to give >>> auxiliary "follow your nose" style data linkage, using the "well known" >>> pattern. >>> >> >> I don't know where it all started, but I got my start with OpenID. I >> did not like entering https://openid.packetizer.com/paulej whenever I >> wanted to log in. Rather, I wanted to enter paulej@packetizer.com. I >> was referred by folks on the OpenID list to go look at WebFinger. And, >> here we are. > > > Yes I do remember the transition from Yadis to OpenID through 1.1 and to > 2.0. As you say there was a marked change. > > Seems to be two polarizing world views. One is to use email style > identifiers to describe things, the other is to use HTTP URIs to describe > things. The UI choice need not necessarily influence the backend > architecture. For example, facebook open graph uses HTTP URIs to define a > profile, but allows login with an email style identifier. > > > Yeah, I agree with you entirely. This is a topic for the OpenID list, > perhaps, but I had no objection to having OpenID use a URI. I just didn't > want to enter it by hand :-) Thus, using WebFinger as a discovery protocol > to facilitate the mapping of a email-style address into an OpenID URI made > a lot of sense. > > > > >> >> >> It's sort of morphed a bit into a few different things, such as a >>> generic discovery method for the net, a new uri scheme, an account >>> identity system for the net, serialization formats. >>> >> >> I don't think it has morphed. These were things that needed to be >> defined to realize the vision. >> >> >> All these things *can* be important, but there's already solutions in >>> many places, and overlap with existing technology. The recent WWW 2012 >>> conference has shown that structured data is now incoporated in somewhere >>> between 25% and 32% of the web, eg using RDFa and microdta. Do we think >>> it's productive to push yet another data lookup format? >>> >>> >>> http://www.bbc.co.uk/blogs/researchanddevelopment/2012/04/notes-from-the-www12-conferenc.shtml >>> >>> It would be awesome if we can main pain point, or problem statement that >>> these specs can solve, find out what the easy wins are, solve those with >>> minimum fuss, imho. >>> >> >> I'd argue there is nothing else in existence that can do what WebFinger >> does, modulo the competing SWD draft. That said, I think there is agreement >> to move forward with WebFinger to provide a single solution. >> > > I dont have any problem with moving forward with the WF draft, perhaps > taking the best features from both specs, is a great idea. I'm just > interested on whether the combined problem statement will change, and the > extent to which, there will be any focus on email based lookup. > > As an aside, in answer to your specific point. Im curious, are you saying > that SPARQL, which has been a W3C rec, for a number of years, is incapable > of a query such as the ones covered by SWD or WF? > > > I'm not sure if it is capable or not, but I get the impression that SPARQL > was not designed for that purpose. I suppose if there is a way to query > for multiple data elements and the entirety of what one might want to query > is located at a known location, perhaps it could. WebFinger is intended to > allow on to issue a query for any URI against the associated domain, > including acct:, mailto:, https:, etc. And the response is a simple set > of link relations. The process is so trivial I can implement a "server" > using static files and use "curl" to fetch the data set. Can SPARQL get > information for any URI as WebFinger can? For certain, if it can it does > so with a lot more complexity. I would need to see some examples, since > those in the spec don't seem to be aligned with what WF or SWD do. > SPARQL is just a query language for data. You can think of it a bit like a jquery with a funny syntax. It can reasonably easily handle questions like "for an email address mailto:user@host, give me the blog of that subject" or "for an email address mailto:user@host, give me ALL information on that subject" or "for a subject acct:user@host, give me ALL information on that subject" etc. etc. Toby Inkster wrote up how to do this back in 2009 and implemented it in perl [1], which may be of interest to you I guess one day XRD may have it's own general purpose query language which would be a generalization of SWD/WF. However, cant help but feel there's an element of reinvention as 100s of man years of spec writing has gone into SPARQL and Linked Data, so hopefully there's some elements that can be reused. [1] http://buzzword.org.uk/2009/fingerpoint/spec-in.html *apologies if that link is sometimes down, I think it's hosted from his home machine > > > > >> >> Are you arguing for a different data format? I think it's worth >> highlighting the simplicity and beauty of the XRD/JRD representations. >> These formats primarily include a set of link relations. The link >> relations are the same syntax and possible values as one might use in the >> "Link" header in HTTP and tags in HTML. So, WebFinger ties in very >> nicely with the Web. >> > > Not trying to form opinion here. Just to understand. In structured data, > things can change pretty quickly, and we're all trying to hit a moving > target. I do think it's sometimes helpful to look at what other > technologies are starting to gain adoption, in order to get a bigger > picture of the whole landscape, or how it might look in a few years. > > > This is one reason I think XRD/JRD are good, too. One might represent > data in a variety of formats (e.g., Portable Contacts vs. hCard vs. vCard > vs. xcard). WF does not dictate the format in which useful information is > presented. What it does is merely provide a pointer to that information. > It's that simplicity and data independence which I find appealing, as I can > continue to use WF long after formats holding user data become obsolete. > > Paul > --20cf307f3806dd7de804bf322e0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 May 2012 15:24, Paul E. Jones <paulej@packetizer.com> wrote:
=20 =20 =20
On 5/3/2012 4:44 AM, Melvin Carvalho wrote:


On 2 May 2012 13:36, Paul E. Jones <p= aulej@packetizer.com> wrote:
On 5/2/2012 7:08 AM, Melvin Carvalho wrote:
One thing that would be a kind of joint problem statement, of the main thing that's trying to be solved.

Is this not understood? =A0Keep in mind that this was not fabricated last week. =A0I've been personally interacting wit= h people working on WebFinger for a couple of years (or more) now. =A0The idea is all about discovery. =A0Given a URI, what can you learn about it? =A0This resulted in the creation of the XRD spec, RFC 5785, RFC 6415 and perhaps other documents along the way. =A0Definitely, the web linking document (RFC 5988) is also an important part of this.


I think this started out as a way for webmail providers to give auxiliary "follow your nose" style data linkag= e, using the "well known" pattern.

I don't know where it all started, but I got my start with OpenID. =A0I did not like entering https://openid.packetizer.com/paulej whenever I wanted to log in. =A0Rather, I wanted to enter paulej@packetizer.com. =A0I was referred by folks on the OpenID list to go look at WebFinger. =A0And, here we are.

Yes I do remember the transition from Yadis to OpenID through 1.1 and to 2.0.=A0 As you say there was a marked change.

Seems to be two polarizing world views.=A0 One is to use email style identifiers to describe things, the other is to use HTTP URIs to describe things.=A0 The UI choice need not necessarily influence the backend architecture.=A0 For example, facebook open graph uses HTTP URIs to define a profile, but allows login with an email style identifier.

Yeah, I agree with you entirely.=A0 This is a topic for the OpenID list, perhaps, but I had no objection to having OpenID use a URI.=A0 I just didn't want to enter it by hand :-)=A0 Thus, using WebFinger a= s a discovery protocol to facilitate the mapping of a email-style address into an OpenID URI made a lot of sense.


=A0


It's sort of morphed a bit into a few different things, such as a generic discovery method for the net, a new uri scheme, =A0an account identity system for the net, serialization formats.

I don't think it has morphed. =A0These were things that neede= d to be defined to realize the vision. I'd argue there is nothing else in existence that can do what WebFinger does, modulo the competing SWD draft. That said, I think there is agreement to move forward with WebFinger to provide a single solution.

I dont have any problem with moving forward with the WF draft, perhaps taking the best features from both specs, is a great idea.=A0 I'm just interested on whether the combined problem statement will change, and the extent to which, there will be any focus on email based lookup.

As an aside, in answer to your specific point.=A0 Im curious, are you saying that SPARQL, which has been a W3C rec, for a number of years, is incapable of a query such as the ones covered by SWD or WF?

I'm not sure if it is capable or not, but I get the impression that SPARQL was not designed for that purpose.=A0 I suppose if there is a way to query for multiple data elements and the entirety of what one might want to query is located at a known location, perhaps it could.=A0 WebFinger is intended to allow on to issue a query for any URI against the associated domain, including acct:, mailto:, https:, etc.=A0 And the response is a simple set of link relations.=A0 The process is so trivial I can implement a "server" using static= files and use "curl" to fetch the data set.=A0 Can SPARQL get infor= mation for any URI as WebFinger can?=A0 For certain, if it can it does so with a lot more complexity.=A0 I would need to see some examples, since those in the spec don't seem to be aligned with what WF or SW= D do.

SPARQL is just a query language for data= .=A0 You can think of it a bit like a jquery with a funny syntax.

It= can reasonably easily handle questions like

"for an email add= ress mailto:user@host, give me the blog of= that subject"

or

"for an email address mailto:user@host, give me ALL information on that subject"

or
"for a subject acct:user@host, give me ALL information on that su= bject"

etc. etc.

Toby Inkster wrote up how to do this back in 2009 and implemented it in per= l [1], which may be of interest to you

I guess one day XRD may have = it's own general purpose query language=20 which would be a generalization of SWD/WF.=A0 However, cant help but feel= =20 there's an element of reinvention as 100s of man years of spec writing = has gone into SPARQL and Linked Data, so hopefully there's some element= s that can be reused.

[1] http://buzzword.org.uk/2009/fingerpoint/spec-in.html=

*apologies if that link is sometimes down, I think it's hosted from= his home machine
=A0


=A0

Are you arguing for a different data format? =A0I think it's worth highlighting the simplicity and beauty of the XRD/JRD representations. =A0These formats primarily include a set of link relations. =A0The link relations are the same syntax and possible values as one might use in the "Link" header i= n HTTP and <link> tags in HTML. =A0So, WebFinger ties in very nicely with the Web.

Not trying to form opinion here.=A0 Just to understand.=A0 In structured data, things can change pretty quickly, and we're all trying to hit a moving target.=A0 I do think it's sometim= es helpful to look at what other technologies are starting to gain adoption, in order to get a bigger picture of the whole landscape, or how it might look in a few years.

This is one reason I think XRD/JRD are good, too.=A0 One might represent data in a variety of formats (e.g., Portable Contacts vs. hCard vs. vCard vs. xcard).=A0 WF does not dictate the format in which useful information is presented.=A0 What it does is merely provide a pointer to that information.=A0 It's that simplicity and data independence which I find appealing, as I can continue to use WF long after formats holding user data become obsolete.

Paul

--20cf307f3806dd7de804bf322e0a-- From andreas@sbin.se Fri May 4 02:05:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBC421F8633 for ; Fri, 4 May 2012 02:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOdMJe255+9D for ; Fri, 4 May 2012 02:05:18 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF6921F8552 for ; Fri, 4 May 2012 02:05:18 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4495GBI017515 for ; Fri, 4 May 2012 09:05:16 GMT Date: Fri, 4 May 2012 11:05:15 +0200 From: Andreas Petersson To: apps-discuss@ietf.org Message-ID: <20120504110515.18679e43@hetzer> In-Reply-To: <29236FD5-51E7-4AC5-88EA-6B956E453D8A@niven-jenkins.co.uk> References: <4FA02AEA.1080407@isode.com> <29236FD5-51E7-4AC5-88EA-6B956E453D8A@niven-jenkins.co.uk> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:05:19 -0000 Hi, Thanks for the feedback! See inlined comments below. /Andreas On 5/2/12 5:59 PM, Ben Niven-Jenkins wrote: > 1. The ABNF gives: > > forwarded-pair = token "=" ( token / quoted-string ) > token = 1*( /[-!#$%&'*+.^_`|~0-9A-Z]/ ) # httpbis-p1 S3.2.4 > > It is a happy coincidence that an IPv4address without an optional > port happens to fall within the token syntax and therefore does > not need to be a quoted-string, but neither an IPv4address with > the optional port (which involves ":" which is not in tchar) or > an IPv6address with or without port (which involve "[", "]" and ":" > none of which are in tchar) are valid tokens and MUST be sent > as quoted-string. > > What might casually seem to some to be the same syntax element > therefore has different quoting/escaping rules depending on its > exact makeup. Generators need to beware. Some might take the view > that it is safest and easiest to simply use quoted-string in all > cases, so consumers also need to beware that even an IPv4address > with no port might be sent as a quoted-string. > > I think this should be explicitly called out, given this draft gets > it wrong itself (see below). Right. I missed that those chars isn't part of tchar. I will add some warnings about this and also make sure to get it right in the examples. :-) > > > 2. The example in S4 is both wrong and odd. > > Forwarded: For=192.0.2.43,"for=[2001:db8:cafe::17]:47011" > Forwarded: proto=https;by=198.51.100.60 > > By #rule this expands to a 3-element list > > For=192.0.2.43 > "for=[2001:db8:cafe::17]:47011" > proto=https;by=198.51.100.60 > > The second element does not match the ABNF: the first quote should > be after the "=". Typo. > The third element, while valid, looks like it might have been > intended to be a run-on of the second thus creating a 2-element > list where the second element has 3 parameters. (It's not clear how > a client send an IPv6 request to an IPv4 endpoint though!) If this > is deliberate then fine, but it perhaps makes for a confusing example. It was intended to be a list with three elements, however not entirely thought through. The by-address in the last element should have a matching address family with the for-parameter in the second element. Maybe a simple example would be better in this section and a more complex example in section 7.1? > > 3. S5.1 ("by" parameter) says: > > This is primarily added by reverse proxies that wish to forward this > information to the backend server. > > I would add that this is especially useful for multi-homed proxies > where the address that the backend server sees the forwarded request > coming from is not the same as the address the proxy received the > request on. (Where the two addresses are the same it seems superfluous.) Indeed. > > 4. S5.2 ("for" parameter) says: > > The > last proxy's IP address, and optionally a port number, are, however, > readily available as the remote IP address of the TCP/IP connection. > > As above, the inbound address is not necessarily the same as the > outbound address of the proxy. The "by" parameter where present might > be a more valuable source of the "proxy's IP address". Yes, in some use cases it wouldn't matter though. A note on that would probably be in place though. > > 5. S6.1 (address identifiers) says: > > The IPv6address SHOULD comply with textual representation > recommendations [RFC5952] (e.g., lowercase, zero compression). > > But RFC 5952 defines a standard mechanism for generating the shortest > (most compressed) textual representation of an IPv6 literal. I do not fully understand the complaint here. The formulation above is however suggested from Dan Wing (@cisco), if the WG has a better idea on how to recommend textual representation of IPv6 addresses you are welcome to suggest them. This was however discussed also on the http-bis mailing list, so I suggest to read the old discussions first. > > 6. S7 says: > > As an example, the header field > > Forwarded: for=192.0.2.43,for=[2001:db8:cafe::17],for=unknown > > This is not valid syntax. The IPv6address contains non-tchars and must > be transmitted as a quoted-string. > Right, this is already mentioned in #1. > > 7. S7 also says: > > Note that this header field is relevant on a per request basis and > MUST NOT be cached. > > It's not entirely clear where this comes from. Request headers are not > normally cached, unless the origin invokes the Vary mechanism. Is it > intended that this should disable the ability of an origin to say > "Vary: Forwarded"? I can't see why this needs to be done (and in any > case won't work with intermediates unaware of this specification.) > > Also note that this header field MUST NOT be > preserved across redirects. > > This seems to presume an intermediate which follows redirects internally, > preserving the original request state for each sub-request, and presents > the final target as a response to the original incoming request. This > seems to be an inadvisable thing to do in any case. (I had a vague idea > it was prohibited, but can't find specific language in httpbis that > provides guidance in either direction - apart from perhaps the p1-S3.1.1 > direction to issue 301 responses to invalid request-lines rather than > transparently fixing them. That seems closely related.) > > Instead, it might be worth noting when the incoming Forwarded header > should be preserved or discarded: > > * Obviously a directly forwarded request should preserve/extend it. > > * If a single incoming request causes an intermediate to make multiple > related inbound requests, then presumably one is a more direct > analog of the original request and should preserve/extend the header, > whereas the others are "internal" and should filter it out. > > * Unless of course the intermediate has detected a content mismatch in > a 304 response and is following the httpbis-p4 S4.1 instructions to > repeat the request unconditionally, in which case the new request > is still basically a direct consequence of the origin request and > the header should probably be kept. The intention was to clarify (and satisfy draft-ietf-httpbis-p2-semantics-19#section-3.1). Your suggestion here seems better though. > 8. Because Via is well established and mandatory and this is new and > optional, consumers should also beware that the elements of Via may > not match the elements of Forwarded: so although proto= may be present > one will probably not be able to infer the corresponding HTTP version > number, or the software version taken from Via of a particular > intermediate identified within Forwarded. This remaining mismatch of > capabilities (which within the X-Forwarded-* family this specification > is intended to address) is perhaps unfortunate. Yes, a note on that would be in place. (The document do support the possibility to extend this header field to also contain stuff like proxy-software and version...) From andreas@sbin.se Fri May 4 02:09:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB721F8747 for ; Fri, 4 May 2012 02:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+MDnvVm3t-Y for ; Fri, 4 May 2012 02:09:17 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA4B621F853B for ; Fri, 4 May 2012 02:09:14 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q44999KW018039 for ; Fri, 4 May 2012 09:09:09 GMT Date: Fri, 4 May 2012 11:09:07 +0200 From: Andreas Petersson To: apps-discuss@ietf.org Message-ID: <20120504110907.6a704d69@hetzer> In-Reply-To: <20120502054103.GL10028@1wt.eu> References: <20120502054103.GL10028@1wt.eu> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:09:17 -0000 On Wed, 2 May 2012 07:41:03 +0200 Willy Tarreau wrote: > A quick note before it escapes my mind, for 8.2. Information leak : > > I would add : > This header field must never be copied into response messages by origin > servers or intermediaries for whatever reason as it can reveal the whole > proxy chain to the client. As a side effect, special care must be taken > in hosting environments not to allow the TRACE request where the Forwarded > field is used, as it would appear in the body of the response message. Seems reasonable. Regards Andreas From paulej@packetizer.com Fri May 4 02:46:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E24121F8629 for ; Fri, 4 May 2012 02:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy4DEsITZDZw for ; Fri, 4 May 2012 02:46:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 903EC21F8554 for ; Fri, 4 May 2012 02:46:42 -0700 (PDT) Received: from [156.106.218.124] ([156.106.218.124]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q449kdGU018554 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 4 May 2012 05:46:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336124801; bh=7KFW9+P7sEXIab4X2freYOVJIvl5bX48WBtoucbJ5fQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=KjW/aXd0hF0z6gzWC8XNj7U/LR1KK1RHQacebssumcesvSXwWxfrz1D5L9jgXps74 0CN+Ds8q2tu2JcszoycWqtNPG/VF5P6Ho2s2Z5L7oj5HJr6XwgFu89OHy7vlutBoP8 6BgW1GZBeHK2h2QyFwgzktEZz//s6mEUMmsO969o= Message-ID: <4FA3A585.4070305@packetizer.com> Date: Fri, 04 May 2012 05:46:45 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Melvin Carvalho References: <4FA0F384.5050008@packetizer.com> <4FA11C4B.2000202@packetizer.com> <4FA2870D.1090407@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090906080101050208090608" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WebFinger Discussion Points X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:46:43 -0000 This is a multi-part message in MIME format. --------------090906080101050208090608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/4/2012 5:02 AM, Melvin Carvalho wrote: > SPARQL is just a query language for data. You can think of it a bit > like a jquery with a funny syntax. > > It can reasonably easily handle questions like > > "for an email address mailto:user@host , give me the > blog of that subject" > > or > > "for an email address mailto:user@host , give me ALL > information on that subject" > > or > > "for a subject acct:user@host, give me ALL information on that subject" > > etc. etc. > > Toby Inkster wrote up how to do this back in 2009 and implemented it > in perl [1], which may be of interest to you > > I guess one day XRD may have it's own general purpose query language > which would be a generalization of SWD/WF. However, cant help but > feel there's an element of reinvention as 100s of man years of spec > writing has gone into SPARQL and Linked Data, so hopefully there's > some elements that can be reused. > > [1] http://buzzword.org.uk/2009/fingerpoint/spec-in.html Melvin, This is interesting and I had not seen it before. At the very least, it validates that there are even more people interested in solving this problem. The approach has a lot of parallels to WF & SWD. To figure out where to direct a query, one uses the domain name of an email address and issues a query to, for example, http://example.com/sparql. This is similar to looking at /.well-known/host-meta. WF would query host-meta for a document with link relations inside. The "fingerpoint" spec looks for Link headers in the HTTP response, it seems. This is the place where the similarities end, though. At this stage, a WF client would have the link relations related to a person and could query each for documents (e.g., PoCo, vcard, avatar, etc.). The "fingerpoint" protocol would only have a pointer to where it can then go issue a SPARQL query. Next, one has to go issue a SPARQL query, which a lot like a web version of SQL. This adds one more steps and also introduces SPARQL, which is not trivial by any means; it's a fairly powerful language. So, I stand corrected that another protocol could not be used, but the alternative (SPARQL) does not fit the goal of trying to keep WF/SWD "simple", IMO. Paul --------------090906080101050208090608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/4/2012 5:02 AM, Melvin Carvalho wrote:
SPARQL is just a query language for data.  You can think of it a bit like a jquery with a funny syntax.

It can reasonably easily handle questions like

"for an email address mailto:user@host, give me the blog of that subject"

or

"for an email address mailto:user@host, give me ALL information on that subject"

or

"for a subject acct:user@host, give me ALL information on that subject"

etc. etc.

Toby Inkster wrote up how to do this back in 2009 and implemented it in perl [1], which may be of interest to you

I guess one day XRD may have it's own general purpose query language which would be a generalization of SWD/WF.  However, cant help but feel there's an element of reinvention as 100s of man years of spec writing has gone into SPARQL and Linked Data, so hopefully there's some elements that can be reused.

[1] http://buzzword.org.uk/2009/fingerpoint/spec-in.html

Melvin,

This is interesting and I had not seen it before.  At the very least, it validates that there are even more people interested in solving this problem.

The approach has a lot of parallels to WF & SWD.  To figure out where to direct a query, one uses the domain name of an email address and issues a query to, for example, http://example.com/sparql.  This is similar to looking at /.well-known/host-meta.  WF would query host-meta for a document with link relations inside.  The "fingerpoint" spec looks for Link headers in the HTTP response, it seems.  This is the place where the similarities end, though.  At this stage, a WF client would have the link relations related to a person and could query each for documents (e.g., PoCo, vcard, avatar, etc.).  The "fingerpoint" protocol would only have a pointer to where it can then go issue a SPARQL query.  Next, one has to go issue a SPARQL query, which a lot like a web version of SQL.  This adds one more steps and also introduces SPARQL, which is not trivial by any means; it's a fairly powerful language.

So, I stand corrected that another protocol could not be used, but the alternative (SPARQL) does not fit the goal of trying to keep WF/SWD "simple", IMO.

Paul

--------------090906080101050208090608-- From internet-drafts@ietf.org Fri May 4 05:40:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C059021F862B; Fri, 4 May 2012 05:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxfFe2p3f9Bh; Fri, 4 May 2012 05:40:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB8B21F85F0; Fri, 4 May 2012 05:40:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504124025.20761.11083.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 05:40:25 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-jones-appsawg-webfinger-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 12:40:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-jones-appsawg-webfinger-04.txt Pages : 21 Date : 2012-05-04 This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ From ietfc@btconnect.com Fri May 4 07:00:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E7121F8757 for ; Fri, 4 May 2012 07:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=1.522, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-WEKeeyqf4p for ; Fri, 4 May 2012 07:00:37 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6CE21F8749 for ; Fri, 4 May 2012 07:00:37 -0700 (PDT) Received: from mail154-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 4 May 2012 14:00:26 +0000 Received: from mail154-tx2 (localhost [127.0.0.1]) by mail154-tx2-R.bigfish.com (Postfix) with ESMTP id CCAB52C01E8; Fri, 4 May 2012 14:00:25 +0000 (UTC) X-SpamScore: -33 X-BigFish: PS-33(zz9371I542Mdf9M1432Nzz1202hzz1033IL8275dhz2dh2a8h5a9h668h839hd24h304l) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI Received: from mail154-tx2 (localhost.localdomain [127.0.0.1]) by mail154-tx2 (MessageSwitch) id 1336140023906083_5621; Fri, 4 May 2012 14:00:23 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.246]) by mail154-tx2.bigfish.com (Postfix) with ESMTP id C77AA4C006D; Fri, 4 May 2012 14:00:23 +0000 (UTC) Received: from DB3PRD0702HT005.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 4 May 2012 14:00:22 +0000 Received: from SN2PRD0710HT004.namprd07.prod.outlook.com (157.56.234.149) by pod51017.outlook.com (10.3.4.160) with Microsoft SMTP Server (TLS) id 14.15.74.2; Fri, 4 May 2012 14:00:27 +0000 Message-ID: <05b601cd29f5$9966f440$4001a8c0@gateway.2wire.net> From: t.petch To: Barry Leiba , Apps Discuss References: Date: Fri, 4 May 2012 14:57:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.234.149] X-OriginatorOrg: btconnect.com Subject: Re: [apps-discuss] Citations for terms from RFC 5598 (Internet MailArchitecture) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:00:38 -0000 ----- Original Message ----- From: "Barry Leiba" To: "Apps Discuss" Sent: Wednesday, April 25, 2012 2:41 PM > RFC 5598, "Internet Mail Architecture", is a handy document -- an > Informational doc that's on the approved-downref list, and which > contains explanations for many terms that we use in talking about > email infrastructure, along with a clear picture of how the pieces all > fit together. > > It frequently comes up in document reviews, both from > directorates/review teams and from the IESG, that people wish we'd > expanded the terms taken from RFC 5598 on first use. We freely use > terms such as "MTA", "MSA", "MUA", "ADMD", and so on, and readers > aren't always sure whether *that* term comes from 5598 or not. > Further, someone with a basic idea of how things work might not have > to look to 5598 to understand "Message Submission Agent" or > "Administrative Management Domain", but is likely not to get the > abbreviations without heading to the reference. > > I think it's reasonable for us to establish a convention for citing > from RFC 5598 that goes something like this: > > 1. Put a reference in the terminology section that says that a number > of terms in this document come from RFC 5598. Something like this > works: > > 1.1 Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > A number of terms used in this document are explained in "Internet Mail > Architecture" [RFC5598], and an understanding of the concepts in RFC 5598 > is important for readers of this document. > > 2. On first use of any particular term, spell it out, abbreviate it, > and cite it. Do this for *every* term we get out of 5598. So on > first use of MTA we say, "when a Message Transfer Agent (MTA) > [RFC5598] receives a connection...". If we also use "MSA", we *also* > say, on first use, "when connecting to a Message Submission Agent > (MSA) [RFC5598], it is important to...". And then, "if the recipient > is in the same Administrative Management Domain (ADMD) [RFC5598], > then...". And so on, for all the terms. > > This may mean that we have a lot of citations to 5598, one for each > term we use out of there, but I think it will make it easier for > people to read and understand the email-related documents. > > Comments? A good idea but a poor execution. Have you read RFC5598 lately, looked at it from the point of view of someone who wants to know what an MSA is? You have to plough through 21 pages of gunk, some of which is irrelevant but others of which you must understand, otherwise you cannot understand the meaning of MSA. Go to the index and it says that MSA appears on page 12; mmm, keep looking, it's a good way of passing a wet Bank Holiday. We need a document but, sadly RFC5598, can never be it; it was written for IETF experts, not for those who want to understand the basics. Tom Petch > Barry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From Michael.Jones@microsoft.com Fri May 4 07:09:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB121F8792 for ; Fri, 4 May 2012 07:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.923 X-Spam-Level: X-Spam-Status: No, score=-3.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HweuL66G0MXl for ; Fri, 4 May 2012 07:09:02 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id A740E21F877F for ; Fri, 4 May 2012 07:08:59 -0700 (PDT) Received: from mail24-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 4 May 2012 14:08:48 +0000 Received: from mail24-am1 (localhost [127.0.0.1]) by mail24-am1-R.bigfish.com (Postfix) with ESMTP id 0243018024D; Fri, 4 May 2012 14:08:48 +0000 (UTC) X-SpamScore: -30 X-BigFish: VS-30(zz9371I936eK542M1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail24-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail24-am1 (localhost.localdomain [127.0.0.1]) by mail24-am1 (MessageSwitch) id 1336140526363935_6323; Fri, 4 May 2012 14:08:46 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.226]) by mail24-am1.bigfish.com (Postfix) with ESMTP id 561C03600BA; Fri, 4 May 2012 14:08:46 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 4 May 2012 14:08:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Fri, 4 May 2012 14:08:40 +0000 From: Mike Jones To: "Paul E. Jones" Thread-Topic: [apps-discuss] I-D Action: draft-jones-appsawg-webfinger-04.txt Thread-Index: AQHNKfMYSzCf2GFvyUCcoYVslGQ8pJa5qs4g Date: Fri, 4 May 2012 14:08:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664AE81A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20120504124025.20761.11083.idtracker@ietfa.amsl.com> In-Reply-To: <20120504124025.20761.11083.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-jones-appsawg-webfinger-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:09:04 -0000 Thanks for the new draft, Paul. -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Friday, May 04, 2012 5:40 AM To: i-d-announce@ietf.org Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-jones-appsawg-webfinger-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-jones-appsawg-webfinger-04.txt Pages : 21 Date : 2012-05-04 This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-jones-appsawg-webfinger-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-jones-appsawg-webfinger/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From barryleiba@gmail.com Fri May 4 07:48:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E1721F85B5; Fri, 4 May 2012 07:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VocTXpKxp5Ek; Fri, 4 May 2012 07:48:19 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2221F857D; Fri, 4 May 2012 07:48:19 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2275842qcs.31 for ; Fri, 04 May 2012 07:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NKrzBDlROzR3UENKxaikW+eIRgHUzdurM0FSNRHx9ds=; b=Z/AtUss0eAKLLe9M0JrFt3njPwx5Z7/21HIuj2mArxRISiGGooe9u4veqwnigC2ilD LODbn/Y3wo+DwdvEsySckL2N8pEIxvRXWqSuARP1NaWs+O1XL+zh8uxQ5FI1bCFVZt6H kz6s+QZlxu7NrDIwNwuiE4eHAacKqX334fh+LREhTm1AFpgn7zwI1AY1J4eygyuUMruW XOt9Us+yLTdsfyrRG3ksLTwAJqXMJHXdMxI7v+5vzQo1UNcZ6xhHM/uSW2BKC2bze9Eo zkV/AIXX3oakRh404CwO4VUx+44m184PyJh/99PB6SHpdbGd97xOqYcRFI90jjA/rIJ3 ICHA== MIME-Version: 1.0 Received: by 10.60.29.10 with SMTP id f10mr8714691oeh.32.1336142898429; Fri, 04 May 2012 07:48:18 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Fri, 4 May 2012 07:48:18 -0700 (PDT) In-Reply-To: <4FA3E380.5030708@cisco.com> References: <4FA3E380.5030708@cisco.com> Date: Fri, 4 May 2012 10:48:18 -0400 X-Google-Sender-Auth: 2BZAzYkjG1rjsQ-tBkdG_fsyOIM Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: multipart/alternative; boundary=e89a8ff1c89ad47d4904bf3702e3 Cc: "apps-discuss@ietf.org" , "paitken@cisco.com" , "nirbd@cisco.com" , "iesg@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:48:20 -0000 --e89a8ff1c89ad47d4904bf3702e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I just posted a new version of draft-claise-export-application-info-in-ipfix, and > forgot to include your comments. ... > From here, we could do 3 things > 1. I quickly post a new version of the draft > 2. Ron put an RFC-editor note > 3. We solve this during the AUTH48 > > I will let Ron decide what's best. This happens all the time, and it always puzzles me. What's the fear of posting another rev of the doc? They're cheap and easy. Not to usurp Ron's decision of what's best in this case, but in general, I think that if one forgets to include something in a draft version, one simply puts it in and posts another version. Voil=E0. Barry --e89a8ff1c89ad47d4904bf3702e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I just posted a new version of= =A0draft-claise-export-application-info-in-ipfix, and
> forgot to include your comments= .
...
> From here, we could do 3 things<= /span>
> =A0 =A0 1. I quickly post a new version of the draft
> =A0 =A0 2= . Ron put an RFC-editor note
> =A0 =A0 3. We solve this during the AU= TH48
>
> I will l= et Ron decide what's best.

This happens all the time, and it always puzz= les me. =A0What's the fear of posting another rev of the doc? =A0They&#= 39;re cheap and easy.

Not to usurp Ron's decision of what's= best in this case, but in general, I think that if one forgets to include = something in a draft version, one simply puts it in and posts another versi= on. =A0Voil=E0.

Barry
--e89a8ff1c89ad47d4904bf3702e3-- From bclaise@cisco.com Fri May 4 07:11:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A042121F87A2; Fri, 4 May 2012 07:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.035 X-Spam-Level: X-Spam-Status: No, score=-8.035 tagged_above=-999 required=5 tests=[AWL=2.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsQGFJBy3ODd; Fri, 4 May 2012 07:11:22 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id A35AB21F87AB; Fri, 4 May 2012 07:11:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q44EBI8G026814; Fri, 4 May 2012 07:11:18 -0700 (PDT) Received: from [10.21.169.179] ([10.21.169.179]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q44EBDGK004479; Fri, 4 May 2012 07:11:13 -0700 (PDT) Message-ID: <4FA3E380.5030708@cisco.com> Date: Fri, 04 May 2012 10:11:12 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jiankang YAO References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060900010302050000020207" X-Mailman-Approved-At: Fri, 04 May 2012 08:01:56 -0700 Cc: nirbd@cisco.com, me , paitken@cisco.com, apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:11:23 -0000 This is a multi-part message in MIME format. --------------060900010302050000020207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jiankang, Thanks for your review. I just posted a new version of draft-claise-export-application-info-in-ipfix , and forgot to include your comments. Sorry about that. Anyway, I agree with your proposal OLD: Applications could be defined at different OSI layers, from layer 2 to layer 7. For example: Link Layer Distribution Protocol (LLDP) [LLDP ] is layer 2 application, ICMP is layer 3 application [IANA-PROTO ], HTTP is layer 4 application [IANA-PORTS ], and skype is layer 7. NEW: Applications could be identified at different OSI layers, from layer 2 to layer 7. For example: Link Layer Distribution Protocol (LLDP) [LLDP] can be identified in layer 2, ICMP can be identified in layer 3 [IANA-PROTO], HTTP can be identified in layer 4 [IANA-PORTS], and skype can be identified in layer7. OLD: Section 6.5. title: Example 4: Layer 7 Application NEW: Section 6.5. title: Example 5: Layer 7 Application From here, we could do 3 things 1. I quickly post a new version of the draft 2. Ron put an RFC-editor note 3. We solve this during the AUTH48 I will let Ron decide what's best. Regards, Benoit (as a contributor) > I have been selected as the Applications Area Directorate reviewer > for this draft (for background on AppsDir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document > shepherd or AD before posting a new version of the draft. > > Document: draft-claise-export-application-info-in-ipfix-05 > Title: Export of Application Information in IPFIX > Reviewer: Jiankang Yao > Review Date: April 20, 2012 > > Summary: This document is almost ready for publication as a Informational RFC. > > This draft specifies an extension to the IPFIX information model specified in [RFC5102] to export application > information. > > Minor issue: > > In Section 6: > > 6. Application Id Examples................................. 21 > 6.1. Example 1: Layer 2 Protocol........................ 21 > 6.2. Example 2: Standardized IANA Layer 3 Protocol...... 22 > 6.3. Example 3: Proprietary Layer 3 Protocol............ 23 > 6.4. Example 4: Standardized IANA Layer 4 Port.......... 25 > 6.5. Example 4: Layer 7 Application..................... 26 > 6.6. Example: port Obfuscation.......................... 28 > 6.7. Example: Application Mapping Options Template...... 29 > 6.8. Example: Attributes Values Options Template Record. 30 > > > Comments : This section is all about examples, covering 10 pages. I suggest to move it to the appendix of this document since it does not specify anything. > > > > Discussion issue: > > In section 2 > " > Application could be defined at different OSI layers, from > layer 2 to layer 7. For example: Link Layer Distribution > Protocol (LLDP) [LLDP] is layer 2 application, ICMP is layer > 3 application [IANA-PROTO], HTTP is layer 4 application > [IANA-PORTS], and skype is layer 7. " > > Comments: From my understanding, HTTP is a kind of layer 7 application based on OSI, but it can be identified in layer 4. > If my understanding is correct, I suggest to tune the text to the following: > > " > Application could be identified at different OSI layers, from > layer 2 to layer 7. For example: Link Layer Distribution > Protocol (LLDP) [LLDP] can be identified in layer 2, ICMP is can be identified in layer 3 > [IANA-PROTO], HTTP can be identified in layer 4 [IANA-PORTS], and skype can be identified in layer7. " > > In the rest of document, it need to be tuned accordingly too. > > > > > Nits: > > Section6.5. title: Example 4: Layer 7 Application > > Change it to "Example 5: Layer 7 Application" since section 6.4 title is " Example 4: Standardized IANA Layer 4 Port"? > > > Jiankang Yao > > --------------060900010302050000020207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Jiankang,
Thanks for your review.
I just posted a new version of draft-claise-export-application-info-in-ipfix, and forgot to include your comments. Sorry about that.

Anyway, I agree with your proposal
OLD:
      Applications could be defined at different OSI layers, from
      layer 2 to layer 7. For example: Link Layer Distribution
      Protocol (LLDP) [LLDP] is layer 2 application, ICMP is layer
      3 application [IANA-PROTO], HTTP is layer 4 application
      [IANA-PORTS], and skype is layer 7.
NEW:

      Applications could be identified at different OSI layers, from
      layer 2 to layer 7. For example: Link Layer Distribution
      Protocol (LLDP) [LLDP] can be identified in layer 2, ICMP can 
      be identified in layer 3 [IANA-PROTO], HTTP can be identified in 
      layer 4 [IANA-PORTS], and skype can be identified in layer7.
OLD:
Section 6.5. title:  Example 4: Layer 7 Application
NEW:
Section 6.5. title:  Example 5: Layer 7 Application

From here, we could do 3 things
    1. I quickly post a new version of the draft
    2. Ron put an RFC-editor note
    3. We solve this during the AUTH48

I will let Ron decide what's best.

Regards, Benoit (as a contributor)
I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on AppsDir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-claise-export-application-info-in-ipfix-05
Title: Export of Application Information in IPFIX
Reviewer: Jiankang Yao
Review Date: April 20, 2012

Summary:  This document is almost ready for publication as a Informational RFC.

This draft specifies an extension to the IPFIX information model specified in [RFC5102] to export application
 information.

Minor issue:

In Section 6:

          6. Application Id Examples................................. 21
           6.1. Example 1: Layer 2 Protocol........................ 21
           6.2. Example 2: Standardized IANA Layer 3 Protocol...... 22
           6.3. Example 3: Proprietary Layer 3 Protocol............ 23
           6.4. Example 4: Standardized IANA Layer 4 Port.......... 25
           6.5. Example 4: Layer 7 Application..................... 26
           6.6. Example: port Obfuscation.......................... 28
           6.7. Example: Application Mapping Options Template...... 29
           6.8. Example: Attributes Values Options Template Record. 30


Comments : This section is all about examples, covering 10 pages. I suggest to move it to the appendix of this document since it does not specify anything.



Discussion issue:

 In section 2
     "
       Application could be defined at different OSI layers, from
      layer 2 to layer 7. For example: Link Layer Distribution
      Protocol (LLDP) [LLDP] is layer 2 application, ICMP is layer
      3 application [IANA-PROTO], HTTP is layer 4 application
      [IANA-PORTS], and skype is layer 7. "
   
Comments:  From my understanding, HTTP  is  a kind of layer 7 application based on OSI, but it can be identified in layer 4.
If my understanding is correct, I suggest to tune the text to the following:

    "
       Application could be identified at different OSI layers, from
      layer 2 to layer 7. For example: Link Layer Distribution
      Protocol (LLDP) [LLDP] can be identified in layer 2, ICMP is can be identified in layer 3
[IANA-PROTO], HTTP can be identified in layer 4  [IANA-PORTS], and skype can be identified in layer7. "

In the rest of document, it need to be tuned accordingly too.
   
  


Nits:

Section6.5. title:  Example 4: Layer 7 Application

Change it to "Example 5: Layer 7 Application" since section 6.4 title is " Example 4: Standardized IANA Layer 4 Port"?


Jiankang Yao

--------------060900010302050000020207-- From stpeter@stpeter.im Fri May 4 09:21:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CFA21E8028; Fri, 4 May 2012 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hVNHGTHqhVv; Fri, 4 May 2012 09:21:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3D26621E8026; Fri, 4 May 2012 09:21:19 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 456844005B; Fri, 4 May 2012 10:36:23 -0600 (MDT) Message-ID: <4FA401FD.8060003@stpeter.im> Date: Fri, 04 May 2012 10:21:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FA3E380.5030708@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Benoit Claise , "iesg@ietf.org" , "paitken@cisco.com" , "apps-discuss@ietf.org" , "nirbd@cisco.com" Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 16:21:20 -0000 On 5/4/12 8:48 AM, Barry Leiba wrote: >> I just posted a new version > of draft-claise-export-application-info-in-ipfix > , > and >> forgot to include your comments. > ... >> From here, we could do 3 things >> 1. I quickly post a new version of the draft >> 2. Ron put an RFC-editor note >> 3. We solve this during the AUTH48 >> >> I will let Ron decide what's best. > > This happens all the time, and it always puzzles me. What's the fear of > posting another rev of the doc? They're cheap and easy. > > Not to usurp Ron's decision of what's best in this case, but in general, > I think that if one forgets to include something in a draft version, one > simply puts it in and posts another version. Voilà. +1. Revised I-Ds improve traceability. From msk@cloudmark.com Fri May 4 12:02:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A82E21E8025 for ; Fri, 4 May 2012 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlS6WEwoLaNV for ; Fri, 4 May 2012 12:02:48 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5547F21E8024 for ; Fri, 4 May 2012 12:02:48 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 5v391j0090as01C01v3D7n; Fri, 04 May 2012 12:03:13 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=x7RSzEbT3xAA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=22iR80tViS9illKqAbMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=sbfrhPoBMooTZVdHI1MA:9 a=zPYLrieAM3FdFMxYZ3oA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 4 May 2012 10:31:47 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: draft-jones-appsawg-webfinger-04 Thread-Index: Ac0qG8eE3EKALRWtQ/iIIohy4m6GpQ== Date: Fri, 4 May 2012 17:31:46 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E00392810E4CAexchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336158193; bh=RQgAEHL1uN7TE9LxdOtLHf7CM+FHkDDhB+3Ac9c+QvA=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Vqx2gcno/F7yGCHeGxtNNkFOTx3N/2NzUsv/ztID1VzYJn4D3DCWJPMe5zw+MMKlL oXV6mfPII9fVYaB+AHid1egJJz/5QXqIVlgxv4ZEeWmbdqOctwUnHE4PBZZzF+jy6X BbhKZdfa4I6ivK3epmrL0aU8UHInIzPLiwJ0qw6I= Cc: "oauth@ietf.org WG" Subject: [apps-discuss] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:02:49 -0000 --_000_9452079D1A51524AA5749AD23E00392810E4CAexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The above-named draft has been offered as the recommended path forward in t= erms of converging on a single document to advance through appsawg. The co= nversation I saw this week in that regard has seemed mostly positive. Please review it, or at least the diff, and indicate your support or object= ion on apps-discuss@ietf.org to adopting this= one as the common path forward. We would like to make a decision about whi= ch one to begin advancing in the next week or two. Have a good weekend! -MSK, APPSAWG co-chair --_000_9452079D1A51524AA5749AD23E00392810E4CAexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The above-named draft has been offered as the recomm= ended path forward in terms of converging on a single document to advance t= hrough appsawg.  The conversation I saw this week in that regard has s= eemed mostly positive.

 

Please review it, or at least the diff, and indicate= your support or objection on apps-discuss@ietf.org to adopt= ing this one as the common path forward. We would like to make a decision a= bout which one to begin advancing in the next week or two.

 

Have a good weekend!

 

-MSK, APPSAWG co-chair

 

--_000_9452079D1A51524AA5749AD23E00392810E4CAexchmbx901corpclo_-- From msk@cloudmark.com Fri May 4 12:11:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B796121F8562 for ; Fri, 4 May 2012 12:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw65AAgBY61N for ; Fri, 4 May 2012 12:11:05 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5417121F858E for ; Fri, 4 May 2012 12:11:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 5vB41j0070ZaKgw01vB4Cd; Fri, 04 May 2012 12:11:04 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=bcDpoZzB c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=qZODYEWQ6tEA:10 a=zutiEJmiVI4A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=xHtqcHUEHTX5HUyQyOAA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=TGee3Ba7mUIGFQlJ:21 a=h5-B19Wk7lxFeviF:21 a=lZMDfK_87SB22ZODSQMA:9 a=N3ArBj-webIGVUoDqssA:7 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=ulE9d5oRiSwu0_XV:21 a=rD1oA7xkchdHB45z:21 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 4 May 2012 10:28:41 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-05 Thread-Index: AQHNKgT0H7bu5kDVM0WptlqweeKej5a54jbQ Date: Fri, 4 May 2012 17:28:39 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810E4B7@exch-mbx901.corp.cloudmark.com> References: <4FA3E380.5030708@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E00392810E4B7exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336158664; bh=PgqJjNQh9D5O5y0WSRI0E21WmQUM+cbWmFM1EL3RSY8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=tYNMumRkb9gsFpirlleMiND9ecGUOKyUn13ND6T/VPVB5n+83PeyU56kr/t0gV0Wu SLmBnjxh8QdrrzAQlYKXTFS/pbqzGK7BlJ7MJuYYwJf5FK99uPCIDQotwcKnchd0Un vybRv86iw4w5Av0TNNhTIIq0snAvRSHKTudd1Des= Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:11:06 -0000 --_000_9452079D1A51524AA5749AD23E00392810E4B7exchmbx901corpclo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [trimmed Cc list] In the past when I've done this during a Last Call (IETF or WG, can't remem= ber), someone else complained in the form of "So what version exactly are w= e supposed to be reviewing here?" I think that's where my own hesitation c= omes from when this decision needs to be made. -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Barry Leiba Sent: Friday, May 04, 2012 7:48 AM To: Benoit Claise Cc: apps-discuss@ietf.org; paitken@cisco.com; nirbd@cisco.com; iesg@ietf.or= g Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-applicati= on-info-in-ipfix-05 > I just posted a new version of draft-claise-export-application-info-in-ip= fix, and > forgot to include your comments. ... > From here, we could do 3 things > 1. I quickly post a new version of the draft > 2. Ron put an RFC-editor note > 3. We solve this during the AUTH48 > > I will let Ron decide what's best. This happens all the time, and it always puzzles me. What's the fear of po= sting another rev of the doc? They're cheap and easy. Not to usurp Ron's decision of what's best in this case, but in general, I = think that if one forgets to include something in a draft version, one simp= ly puts it in and posts another version. Voil=E0. Barry --_000_9452079D1A51524AA5749AD23E00392810E4B7exchmbx901corpclo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[trimmed Cc list]

 <= /p>

In the past when I’= ve done this during a Last Call (IETF or WG, can’t remember), someone= else complained in the form of “So what version exactly are we suppo= sed to be reviewing here?”  I think that’s where my own hesit= ation comes from when this decision needs to be made.

 <= /p>

-MSK

 <= /p>

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Barry Leiba
Sent: Friday, May 04, 2012 7:48 AM
To: Benoit Claise
Cc: apps-discuss@ietf.org; paitken@cisco.com; nirbd@cisco.com; iesg@= ietf.org
Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-ap= plication-info-in-ipfix-05

 

> I just posted = a new version of draft-claise-export-application-info-in-ipfix, and

> forgot to incl= ude your comments.

...

> From here, we = could do 3 things
>     1. I quickly post a new= version of the draft
>     2. Ron put an RFC-edito= r note
>     3. We solve this during= the AUTH48
>
> I will let Ron decide what's best.

 

This happens all th= e time, and it always puzzles me.  What's the fear of posting another = rev of the doc?  They're cheap and easy.

 

Not to usurp Ron's = decision of what's best in this case, but in general, I think that if one f= orgets to include something in a draft version, one simply puts it in and p= osts another version.  Voil=E0.

 

Barry

--_000_9452079D1A51524AA5749AD23E00392810E4B7exchmbx901corpclo_-- From eran@hueniverse.com Fri May 4 12:41:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C554621E8043; Fri, 4 May 2012 12:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDE94eK6lauo; Fri, 4 May 2012 12:41:25 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 05C5621E8042; Fri, 4 May 2012 12:41:24 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 5vhQ1j0030EuLVk01vhQLu; Fri, 04 May 2012 12:41:24 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Fri, 4 May 2012 12:41:23 -0700 From: Eran Hammer To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" Thread-Topic: draft-jones-appsawg-webfinger-04 Thread-Index: Ac0qG8eE3EKALRWtQ/iIIohy4m6GpQAEgy3Q Date: Fri, 4 May 2012 19:41:23 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20101CA96@P3PWEX2MB008.ex2.secureserver.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20101CA96P3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:41:25 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20101CA96P3PWEX2MB008ex2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support using this document as the starting point for this work. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= urray S. Kucherawy Sent: Friday, May 04, 2012 10:32 AM To: apps-discuss@ietf.org Cc: oauth@ietf.org WG Subject: [OAUTH-WG] draft-jones-appsawg-webfinger-04 The above-named draft has been offered as the recommended path forward in t= erms of converging on a single document to advance through appsawg. The co= nversation I saw this week in that regard has seemed mostly positive. Please review it, or at least the diff, and indicate your support or object= ion on apps-discuss@ietf.org to adopting this= one as the common path forward. We would like to make a decision about whi= ch one to begin advancing in the next week or two. Have a good weekend! -MSK, APPSAWG co-chair --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20101CA96P3PWEX2MB008ex2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support using this d= ocument as the starting point for this work.

 

EH

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Friday, May 04, 2012 10:32 AM
To: apps-discuss@ietf.org
Cc: oauth@ietf.org WG
Subject: [OAUTH-WG] draft-jones-appsawg-webfinger-04

 

The above-named draft has been offered as the recomm= ended path forward in terms of converging on a single document to advance t= hrough appsawg.  The conversation I saw this week in that regard has s= eemed mostly positive.

 

Please review it, or at least the diff, and indicate= your support or objection on apps-discuss@ietf.org to adopt= ing this one as the common path forward. We would like to make a decision a= bout which one to begin advancing in the next week or two.

 

Have a good weekend!

 

-MSK, APPSAWG co-chair

 

--_000_0CBAEB56DDB3A140BA8E8C124C04ECA20101CA96P3PWEX2MB008ex2_-- From gsalguei@cisco.com Fri May 4 12:49:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB79421E8045; Fri, 4 May 2012 12:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20GTsKPAcYBA; Fri, 4 May 2012 12:49:48 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B1D0A21E8042; Fri, 4 May 2012 12:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gsalguei@cisco.com; l=4159; q=dns/txt; s=iport; t=1336160988; x=1337370588; h=references:in-reply-to:mime-version:message-id: content-transfer-encoding:cc:from:subject:date:to; bh=HCAcemyufsnhZ9/vYKf5+uEmzD1JN3TvTa3rMhTO5qA=; b=Y1Ok5HleoCBnDHpADviMPlPKnqm7ddX/Jz4AKrQDblhgsrp6DOqtojId LhrFjctBcXxrvE6U6CwOATEP5kD6WOHxYaDdhUvy/0zOjqukcfpWhXtnP ae2SAoLJxa/4Bt3sBc+1ZO4+FvjRmytJAbEVEiVfmfJDMADmn1Xefp8SU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEIAHcypE+tJXG8/2dsb2JhbABFgkaDKKx7AoEHggkBAQEDAQEBAQ8BEApBCwULAgEIBD4CAicwAQEEEyKHZgULmxCNFpJtBI91NWMEiDCNTo5ZgWmDBA X-IronPort-AV: E=Sophos;i="4.75,533,1330905600"; d="scan'208,217";a="80516618" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 04 May 2012 19:49:48 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q44JnmMw007714; Fri, 4 May 2012 19:49:48 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 May 2012 14:49:48 -0500 Received: from 72.163.62.211 ([72.163.62.211]) by XMB-RCD-204.cisco.com ([72.163.62.211]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 May 2012 19:49:47 +0000 References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> MIME-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary="Apple-Mail-36A76E19-206D-4516-BFD6-B3EF0EF685A3"; charset="iso-8859-1" Message-ID: <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> Content-Transfer-Encoding: 7bit Thread-Topic: [apps-discuss] draft-jones-appsawg-webfinger-04 Thread-Index: Ac0qLw91jpuP0JfARCag29xw1SJcwA== From: "Gonzalo Salgueiro (gsalguei)" Date: Fri, 4 May 2012 15:49:42 -0400 To: "Murray S. Kucherawy" X-OriginalArrivalTime: 04 May 2012 19:49:48.0306 (UTC) FILETIME=[0FF38720:01CD2A2F] Cc: oauth@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:49:49 -0000 --Apple-Mail-36A76E19-206D-4516-BFD6-B3EF0EF685A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support this doc being adopted as starting point for WG discussion. Regards, Gonzalo On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" wrote:= > The above-named draft has been offered as the recommended path forward in t= erms of converging on a single document to advance through appsawg. The con= versation I saw this week in that regard has seemed mostly positive. > =20 > Please review it, or at least the diff, and indicate your support or objec= tion on apps-discuss@ietf.org to adopting this one as the common path forwar= d. We would like to make a decision about which one to begin advancing in th= e next week or two. > =20 > Have a good weekend! > =20 > -MSK, APPSAWG co-chair > =20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-36A76E19-206D-4516-BFD6-B3EF0EF685A3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I support this doc being adopted as starting point for WG discussion.

Regards,

Gonzalo


On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" <msk@cloudmark.com> wrote:

The above-named draft has been offered as the recommended path forward in terms of converging on a single document to advance through appsawg.  The conversation I saw this week in that regard has seemed mostly positive.

 

Please review it, or at least the diff, and indicate your support or objection on apps-discuss@ietf.org to adopting this one as the common path forward. We would like to make a decision about which one to begin advancing in the next week or two.

 

Have a good weekend!

 

-MSK, APPSAWG co-chair

 

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--Apple-Mail-36A76E19-206D-4516-BFD6-B3EF0EF685A3-- From stpeter@stpeter.im Fri May 4 12:51:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B162321F85EA for ; Fri, 4 May 2012 12:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKWhV6KGjtSX for ; Fri, 4 May 2012 12:51:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B5C4821F85D8 for ; Fri, 4 May 2012 12:51:28 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BA6B740058; Fri, 4 May 2012 14:06:33 -0600 (MDT) Message-ID: <4FA4333F.3090101@stpeter.im> Date: Fri, 04 May 2012 13:51:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:51:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/4/12 11:31 AM, Murray S. Kucherawy wrote: > The above-named draft has been offered as the recommended path > forward in terms of converging on a single document to advance > through appsawg. The conversation I saw this week in that regard > has seemed mostly positive. > > Please review it, or at least the diff, and indicate your support > or objection on apps-discuss@ietf.org > to adopting this one as the common > path forward. We would like to make a decision about which one to > begin advancing in the next week or two. I think this is a good starting point. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+kMz8ACgkQNL8k5A2w/vwN7QCeLOBqQPpWjtmKTd+mkOyc28np BvkAoJ23TyeUFYHj7Ygs3Fb1FpZ7eawM =64Eo -----END PGP SIGNATURE----- From bclaise@cisco.com Fri May 4 08:55:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380BE21F8714; Fri, 4 May 2012 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.177 X-Spam-Level: X-Spam-Status: No, score=-8.177 tagged_above=-999 required=5 tests=[AWL=2.421, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMGf0ptm8Cln; Fri, 4 May 2012 08:55:07 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id 92AD721F8634; Fri, 4 May 2012 08:55:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q44Ft2BY007870; Fri, 4 May 2012 08:55:02 -0700 (PDT) Received: from [10.21.169.179] ([10.21.169.179]) by fire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q44FswXv021176; Fri, 4 May 2012 08:54:59 -0700 (PDT) Message-ID: <4FA3FBD1.1040406@cisco.com> Date: Fri, 04 May 2012 11:54:57 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Barry Leiba References: <4FA3E380.5030708@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000508090305090101050901" X-Mailman-Approved-At: Fri, 04 May 2012 13:10:06 -0700 Cc: "paitken@cisco.com" , "apps-discuss@ietf.org" , "iesg@ietf.org" , me , "nirbd@cisco.com" Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:55:08 -0000 This is a multi-part message in MIME format. --------------000508090305090101050901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit > > I just posted a new version of > draft-claise-export-application-info-in-ipfix > , > and > > forgot to include your comments. > ... > > From here, we could do 3 things > > 1. I quickly post a new version of the draft > > 2. Ron put an RFC-editor note > > 3. We solve this during the AUTH48 > > > > I will let Ron decide what's best. > > This happens all the time, and it always puzzles me. What's the fear > of posting another rev of the doc? They're cheap and easy. > > Not to usurp Ron's decision of what's best in this case, but in > general, I think that if one forgets to include something in a draft > version, one simply puts it in and posts another version. Voilà. Same answer from Ron. Therefore http://www.ietf.org/id/draft-claise-export-application-info-in-ipfix-07.txt is now posted ;-) Regards, Benoit. > > Barry --------------000508090305090101050901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
> I just posted a new version of draft-claise-export-application-info-in-ipfix, and
> forgot to include your comments.
...
> From here, we could do 3 things
>     1. I quickly post a new version of the draft
>     2. Ron put an RFC-editor note
>     3. We solve this during the AUTH48
>
> I will let Ron decide what's best.

This happens all the time, and it always puzzles me.  What's the fear of posting another rev of the doc?  They're cheap and easy.

Not to usurp Ron's decision of what's best in this case, but in general, I think that if one forgets to include something in a draft version, one simply puts it in and posts another version.  Voilà.
Same answer from Ron.
Therefore http://www.ietf.org/id/draft-claise-export-application-info-in-ipfix-07.txt is now posted ;-)

Regards, Benoit.

Barry

--------------000508090305090101050901-- From stpeter@stpeter.im Fri May 4 13:58:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6611E8083; Fri, 4 May 2012 13:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReVGOWyo7pJh; Fri, 4 May 2012 13:58:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 137E711E8072; Fri, 4 May 2012 13:58:55 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E686440058; Fri, 4 May 2012 15:13:59 -0600 (MDT) Message-ID: <4FA4430D.3090902@stpeter.im> Date: Fri, 04 May 2012 14:58:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> In-Reply-To: <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 20:58:55 -0000 On 5/3/12 3:59 PM, Paul Hoffman wrote: > On May 3, 2012, at 2:41 PM, Peter Saint-Andre wrote: > >> On 5/3/12 2:34 PM, Paul Hoffman wrote: >>> On May 3, 2012, at 12:52 PM, Peter Saint-Andre wrote: >>> >>>> Perhaps this is simply a difference between folks who look at >>>> things from the DNS perspective and folks who look at things from >>>> the apps perspective (as users of DNS). All sorts of application >>>> protocols are being updated to support IDNs. Those applications >>>> will need to know how to translate their IDNs (which might consist >>>> of U-labels) into a form that can be placed into the DNS. To make >>>> things perfectly clear, I'm just suggesting that we add a sentence >>>> or two warning those who write code for application protocols using >>>> DANE that they might need to convert U-labels into A-labels. I'll >>>> work to propose specific text today or tomorrow. >>> >>> >>> I'll be interested to see that. I cannot see how anyone reading >>> Section 3 of RFC 5891 could think that they would *not* need to >>> convert to A-labels before looking up something in the DNS. If you >>> are saying that every post-5891 protocol that defines a new RRtype >>> must say "and if you are going to look up the domain name in the DNS, >>> convert to A-labels first", that's fine, but it seems kinda late to >>> start saying that. >> >> Not everyone is as smart as you are. > > If you believe that developers who are using IDNs are not following the easiest-to-read section of RFC 5891, the issue is much larger than just DANE. I propose that is not a DANE issue at all. Maybe, maybe not. I leave that up to the working group. Borrowing a bit from RFC 6066 (thanks to Martin Rex for the pointer), I suggest that we could add the following parenthetical statement to point 3 in Section 3... OLD 3. The domain name is appended to the result of step 2 to complete the prepared domain name. NEW 3. The domain name is appended to the result of step 2 to complete the prepared domain name. (The domain name is the fully qualified DNS domain name [RFC1035] of the TLS server and is represented as a byte string using ASCII encoding without a trailing dot; this enables support for internationalized domain names through the use of A-labels as defined in [RFC5890].) Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Fri May 4 14:06:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577B321F8532 for ; Fri, 4 May 2012 14:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFxYFtkHjIkJ for ; Fri, 4 May 2012 14:06:28 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id D5DC421F849A for ; Fri, 4 May 2012 14:06:25 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 5x6V1j0010as01C01x6VsH; Fri, 04 May 2012 14:06:29 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Xth4yC59 c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=DYq6my6sJs0A:10 a=zutiEJmiVI4A:10 a=ou5xGSR4Oo8A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=c9U-ykEWkj9_jmJu9BgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Fri, 4 May 2012 14:06:03 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: draft-ietf-appsawg-media-type-suffix-regs Thread-Index: AQHNKjm214kJrC4EIEqw930/6rIevQ== Date: Fri, 4 May 2012 21:06:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810EB11@exch-mbx901.corp.cloudmark.com> References: <20120426131912.32053.74050.idtracker@ietfa.amsl.com> In-Reply-To: <20120426131912.32053.74050.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336165589; bh=PBCF3OPjqeWL579bH5exbe7VM2Y4GtjQp/UFsSX0Huw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Ki7Zmxn82U3wnozBoz7djQqWgaPtEPGldygNOnmEBgw7vbTYoCaAfnjeqA+FZ0awV 6JaKhvhRbhHagURmOLuS2NygoZPkohTgtHBFQv4COj+Y7krdIhSF83/+F4duERxYko uTolGR60UVAasNTwGHWssHNXMbwJ8uJtxksjMWIA= Subject: [apps-discuss] draft-ietf-appsawg-media-type-suffix-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:06:29 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, April 26, 2012 6:19 AM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: I-D Action: draft-ietf-appsawg-media-type-suffix-regs-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. >=20 > Title : Additional Media Type Structured Syntax Suffixes > Author(s) : Tony Hansen > Filename : draft-ietf-appsawg-media-type-suffix-regs-00.txt > Pages : 9 > Date : 2012-04-26 >=20 > This document defines several Structured Syntax Suffixes for use with > media type registrations. In particular, it defines and registers > the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" > Structured Syntax Suffixes, and updates the "+xml" Structured Syntax > Suffix registration. This document is the follow-on to the one Ned just finished that updates me= dia type registration procedures. Since the latter references this one nor= matively, they'll be clustered and held until they're all queued. Thus, please review and provide some comments so we can make progress towar= d being able to submit it for processing. Thanks, and good weekend to all. -MSK, APPSAWG co-chair From ajs@anvilwalrusden.com Fri May 4 14:08:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F3021F853F for ; Fri, 4 May 2012 14:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIEJJX9HhKgs for ; Fri, 4 May 2012 14:08:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3727C21F853D for ; Fri, 4 May 2012 14:08:56 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8B0A01ECB41C for ; Fri, 4 May 2012 21:08:55 +0000 (UTC) Date: Fri, 4 May 2012 17:08:53 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20120504210853.GM7394@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [apps-discuss] draft-sullivan-domain-origin-assert-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:08:56 -0000 Dear colleagues, I posted today draft-sullivan-domain-origin-assert-00.txt. The point of this draft is to outline a way of publishing records in the DNS, so that one can figure out what names have some sort of administrative link to one another (I've called this the "administrative realm", although probably not consistently, and I'm not too happy with the term). The idea is that you'd be able to use the mechanism in order either to consider different DNS names as somehow linked together (so that, for instance, cookie policies or other such things could be adapted accordingly), or (more often) to determine that names are _not_ linked together in order to foil illegitimate attempts to assert links. I can't think of any other list that is appropriate, but if people have an alternative I'm all ears. I haven't explicitly pointed commenters at this list yet, pending permission from the list moderators. Comments (shredding, &c. &c.) are eagerly solicited. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Fri May 4 14:10:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542021F8532; Fri, 4 May 2012 14:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-et4MvXiMQ0; Fri, 4 May 2012 14:10:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0229821F84B2; Fri, 4 May 2012 14:10:56 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q44LAtCb056796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 May 2012 14:10:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA4430D.3090902@stpeter.im> Date: Fri, 4 May 2012 14:10:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C883441-D7DD-4BE8-80C4-61C276CC8840@vpnc.org> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> <4FA4430D.3090902@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:10:57 -0000 On May 4, 2012, at 1:58 PM, Peter Saint-Andre wrote: > Borrowing a bit from RFC 6066 (thanks to Martin Rex for the pointer), = I > suggest that we could add the following parenthetical statement to = point > 3 in Section 3... >=20 > OLD > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. >=20 > NEW >=20 > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string using ASCII encoding without a > trailing dot; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) Thank you for finally suggesting text. :-) This seems fine to me, doesn't change anything technically, appears in = the right place, and doesn't feel gratuitous. --Paul Hoffman From mrex@sap.com Fri May 4 15:24:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9EF21F84D8; Fri, 4 May 2012 15:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.067 X-Spam-Level: X-Spam-Status: No, score=-10.067 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wowv-UxmRu-v; Fri, 4 May 2012 15:24:58 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E57721F84D0; Fri, 4 May 2012 15:24:58 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44MOpx2011769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 00:24:51 +0200 (MEST) From: Martin Rex Message-Id: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> To: ajs@crankycanuck.ca (Andrew Sullivan) Date: Sat, 5 May 2012 00:24:50 +0200 (MEST) In-Reply-To: <20120504220713.GR7394@crankycanuck.ca> from "Andrew Sullivan" at May 4, 12 06:07:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:24:59 -0000 Andrew Sullivan wrote: > > On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote: > > 3. The domain name is appended to the result of step 2 to complete > > the prepared domain name. (The domain name is the fully > > qualified DNS domain name [RFC1035] of the TLS server and is > > represented as a byte string using ASCII encoding without a > > trailing dot; this enables support for internationalized > > domain names through the use of A-labels as defined in > > [RFC5890].) > > I don't understand that definition of "the domain name". What we > appear to be discussing here is how you prepare the presentation > format for the domain name; "represented as a byte string using ASCII > encoding" doesn't make a lot of sense to me in this context. > > In particular, you don't need any of the text starting with > "represented" and ending with the semicolon, because what you're > describing there isn't properly speaking a domain name at all. It's a > relative domain name, which happens to be relative to the root. It's > also in presentation format, which is irrelevant for DNS query > purposes, because we don't send queries in presentation format. > > It sounds like the key point you want to make is that IDNA2008 labels > MUST be in A-label format before transformation. Is that it? We added similar text like the above to rfc6066 (TLS extensions) for the description of the extension "Server name indication" here: http://tools.ietf.org/html/rfc6066#page-7 3rd paragraph on page 7 Could you point to an existing document that contains a suitable 1-paragraph desciption that you believe fits better here? I don't think that we should be inventing a new description for ever new document, but preferably re-use what is already there. -Martin From ajs@anvilwalrusden.com Fri May 4 15:33:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A2C21E8015; Fri, 4 May 2012 15:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8iKDUjn2cJd; Fri, 4 May 2012 15:33:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9E921E8012; Fri, 4 May 2012 15:33:21 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BEF9E1ECB41C; Fri, 4 May 2012 22:33:20 +0000 (UTC) Date: Fri, 4 May 2012 18:33:19 -0400 From: Andrew Sullivan Sender: dane-bounces@ietf.org To: Peter Saint-Andre Message-ID: <20120504223314.GU7394@crankycanuck.ca> References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> <4F96D2AB.6090509@stpeter.im> <4FA2E1F2.6060406@stpeter.im> <2B6494C5-4BB1-4159-967C-483094BDC0C7@vpnc.org> <4FA2FB94.204@stpeter.im> <07511DD9-AED9-4E67-B162-6D353C550788@vpnc.org> <4FA4430D.3090902@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA4430D.3090902@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:33:22 -0000 [resending from an actually subscribed address. Apologies] Hi, On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote: > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string using ASCII encoding without a > trailing dot; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) I don't understand that definition of "the domain name". What we appear to be discussing here is how you prepare the presentation format for the domain name; "represented as a byte string using ASCII encoding" doesn't make a lot of sense to me in this context. In particular, you don't need any of the text starting with "represented" and ending with the semicolon, because what you're describing there isn't properly speaking a domain name at all. It's a relative domain name, which happens to be relative to the root. It's also in presentation format, which is irrelevant for DNS query purposes, because we don't send queries in presentation format. It sounds like the key point you want to make is that IDNA2008 labels MUST be in A-label format before transformation. Is that it? A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Fri May 4 15:37:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513A321F84F8; Fri, 4 May 2012 15:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.069 X-Spam-Level: X-Spam-Status: No, score=-10.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3m-tok2M3VV; Fri, 4 May 2012 15:37:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2321F84F0; Fri, 4 May 2012 15:37:49 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44MbknI013307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 00:37:46 +0200 (MEST) From: Martin Rex Message-Id: <201205042237.q44Mbj23000744@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Sat, 5 May 2012 00:37:45 +0200 (MEST) In-Reply-To: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> from "Martin Rex" at May 5, 12 00:24:50 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ajs@crankycanuck.ca, dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:37:50 -0000 Martin Rex wrote: > > Andrew Sullivan wrote: > > > > On Fri, May 04, 2012 at 02:58:53PM -0600, Peter Saint-Andre wrote: > > > 3. The domain name is appended to the result of step 2 to complete > > > the prepared domain name. (The domain name is the fully > > > qualified DNS domain name [RFC1035] of the TLS server and is > > > represented as a byte string using ASCII encoding without a > > > trailing dot; this enables support for internationalized > > > domain names through the use of A-labels as defined in > > > [RFC5890].) > > > > I don't understand that definition of "the domain name". What we > > appear to be discussing here is how you prepare the presentation > > format for the domain name; "represented as a byte string using ASCII > > encoding" doesn't make a lot of sense to me in this context. > > > > In particular, you don't need any of the text starting with > > "represented" and ending with the semicolon, because what you're > > describing there isn't properly speaking a domain name at all. It's a > > relative domain name, which happens to be relative to the root. It's > > also in presentation format, which is irrelevant for DNS query > > purposes, because we don't send queries in presentation format. > > > > It sounds like the key point you want to make is that IDNA2008 labels > > MUST be in A-label format before transformation. Is that it? > > > We added similar text like the above to rfc6066 (TLS extensions) > for the description of the extension "Server name indication" here: > > http://tools.ietf.org/html/rfc6066#page-7 > > 3rd paragraph on page 7 > > Could you point to an existing document that contains a suitable > 1-paragraph desciption that you believe fits better here? > I don't think that we should be inventing a new description > for ever new document, but preferably re-use what is already there. That "we added to rfc6066" refers to this disussion in the TLS WG: https://www.ietf.org/mail-archive/web/tls/current/msg07233.html Re-reading that paragraph, I realize that the description "fully qualified DNS hostname of the server" is factually incorrect for rfc6066 (I don't know about DANE, though). When used by HTTP-over-TLS, it ought to be the name as used by the client for performing server endpoint identification (rfc2818 or rf6125), and that _can_ be a hostname without domain from a URL!! -Martin From ajs@anvilwalrusden.com Fri May 4 15:38:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A313721F84F8; Fri, 4 May 2012 15:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjafVrGjEyqA; Fri, 4 May 2012 15:38:32 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2550221F84F0; Fri, 4 May 2012 15:38:32 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CFDAB1ECB41C; Fri, 4 May 2012 22:38:21 +0000 (UTC) Date: Fri, 4 May 2012 18:38:20 -0400 From: Andrew Sullivan To: Martin Rex Message-ID: <20120504223816.GV7394@crankycanuck.ca> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:38:33 -0000 On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: > > We added similar text like the above to rfc6066 (TLS extensions) > for the description of the extension "Server name indication" here: The problem in this case, however, is that what the TLSA document is doing is building a QNAME for use in the DNS. None of the description from RFC 6066 is a domain name. Remember, the dot-separated labels are the presentation form, but _not_ what you send on the wire. Dots aren't part of the DNS on the wire. What we want to do for this case is get the QNAME for the DNS. So we take the two labels that come out of steps 1 and 2 in the draft, and put them on the front of the DNS name that we're trying to look up, creating an absolute, fully qualified name that gets sent in the QNAME of the DNS operation. At least I think that's what the section is trying to do. I'm also uncomfortable with the "ASCII" stuff, because DNS labels aren't in ASCII. They're octets. However, ASCII is treated specially in the DNS. (This is one of the sharp edges about the DNS that we'd all like to go back and fix if we could.) A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@resistor.net Fri May 4 15:51:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9099021F848A; Fri, 4 May 2012 15:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOo+QsB8Ajm8; Fri, 4 May 2012 15:51:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D840421F8484; Fri, 4 May 2012 15:51:02 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q44MosIQ028878; Fri, 4 May 2012 15:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336171862; i=@resistor.net; bh=dCK3Jg/dzB8UsGA/Kes7ELu7lJOaB3hllpIZf9kZjYE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j2cPhLFpwDleX40wWq6yXwJ47yDfopVIISdVUTk4bRgtYXcI0AG4js4uX/UXcuTpT D4d0xQwioIzm7BPZcvrjct5Umkc0qrC1rFic1eRwl3G96RhZS770LOVy8yakL/UyzP TbqyVuqv/hfK7dzw0ceB2ugtdWv7br3B1BSfHBEE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336171862; i=@resistor.net; bh=dCK3Jg/dzB8UsGA/Kes7ELu7lJOaB3hllpIZf9kZjYE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xW8Pjb3zz/bOxeA0wwqN+aMlRA2rCzWQQBTi+IUfnydmqrdV+7LdTKpI0q9xU+XKe oqZ5aLtXCypVagoinuO/xAs/PaYRY6fl++eBSEWu1GqC7cMoa7eyNFcEG03mk7/h7H qDBgui4uRTxYcLwO9zmd+X9+6cvnNJmg4AzduiZ4= Message-Id: <6.2.5.6.2.20120504152947.0ab53640@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 04 May 2012 15:50:49 -0700 To: mrex@sap.com From: SM In-Reply-To: <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:51:04 -0000 Hi Martin, At 15:24 04-05-2012, Martin Rex wrote: >We added similar text like the above to rfc6066 (TLS extensions) >for the description of the extension "Server name indication" here: > > http://tools.ietf.org/html/rfc6066#page-7 > >3rd paragraph on page 7 > >Could you point to an existing document that contains a suitable >1-paragraph desciption that you believe fits better here? I'll skip the tricky question. :-) >I don't think that we should be inventing a new description >for ever new document, but preferably re-use what is already there. The text from that section of RFC 6066 is about FQDNs. RFC 6394 mentions that 'the process of obtaining this "source" domain is application specific [RFC6125]'. It seems like the better choice to keep things easy. It also matches what's in Section 4 of the draft. Regards, -sm From barryleiba.mailing.lists@gmail.com Fri May 4 16:09:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E526511E8072 for ; Fri, 4 May 2012 16:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZHDg+6-5Mfc for ; Fri, 4 May 2012 16:09:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98DB921F8542 for ; Fri, 4 May 2012 16:09:12 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2718504lbb.31 for ; Fri, 04 May 2012 16:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FNQ292PYZiFPgj28B6hVlLAWEPSvzgcs7viZ68h1P5k=; b=diHKatUFLDPdzg6kE0DWR+KDYsyK42U7tK8GY//yiK6E/Xk7v1ndYMc6+oG6mJuyMY e/vaiuUsKeY2bEc5cFID7UrwJDAQaD4sydVBKa6jbSk9xamrLbtcvCerSidn/gY2EPvI 3FHb2I1raWIrjmT4y+MCTx1Aqo3R63VPA4s/ffUb4cvm4SAG5LbEsAfj5bW7+U4jdPHj qh51bRzRvW4uRhXAE9yfX1lraIEZM6XDoFfQf1reyF4R/UrMSHKWcSrMfFM6Gg3RXQrg 1+v+/L4JiWJkeVc2jURQ+QfXlk/290SgLSuMZQkLWJzoVvhQYWNuMaqeCYlApY/ayP5M VHEQ== MIME-Version: 1.0 Received: by 10.112.23.40 with SMTP id j8mr3738754lbf.44.1336172951336; Fri, 04 May 2012 16:09:11 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Fri, 4 May 2012 16:09:11 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E00392810E4B7@exch-mbx901.corp.cloudmark.com> References: <4FA3E380.5030708@cisco.com> <9452079D1A51524AA5749AD23E00392810E4B7@exch-mbx901.corp.cloudmark.com> Date: Fri, 4 May 2012 19:09:11 -0400 X-Google-Sender-Auth: mCMlITHpL3TYFbGihz_8x7bnKz8 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=90e6ba25db951f782e04bf3e0289 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-application-info-in-ipfix-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 23:09:14 -0000 --90e6ba25db951f782e04bf3e0289 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I see it, there's little reason to complain about that now. There are both tracker and tools links that give you the latest version, regardless of what version was specified in the last call note, and the tracker link is now included in the last call. The answer to the question is always, "The latest one, of course." It's silly to have people reviewing errors that have already been corrected and text that's already changed. Barry On Friday, May 4, 2012, Murray S. Kucherawy wrote: > > In the past when I=92ve done this during a Last Call (IETF or WG, can=92t > remember), someone else complained in the form of =93So what version exac= tly > are we supposed to be reviewing here?=94 I think that=92s where my own > hesitation comes from when this decision needs to be made. > > -MSK**** > > ** ** > > *From:* apps-discuss-bounces@ietf.org 'apps-discuss-bounces@ietf.org');> [mailto:apps-discuss-bounces@ietf.org<= javascript:_e({}, 'cvml', 'apps-discuss-bounces@ietf.org');>] > *On Behalf Of *Barry Leiba > *Sent:* Friday, May 04, 2012 7:48 AM > *To:* Benoit Claise > *Cc:* apps-discuss@ietf.org 'apps-discuss@ietf.org');>; paitken@cisco.com 'paitken@cisco.com');>; nirbd@cisco.com 'nirbd@cisco.com');>; iesg@ietf.org 'iesg@ietf.org');> > *Subject:* Re: [apps-discuss] APPSDIR review of > draft-claise-export-application-info-in-ipfix-05**** > > ** ** > > > I just posted a new version of > draft-claise-export-application-info-in-ipfix, > and**** > > > forgot to include your comments.**** > > ...**** > > > From here, we could do 3 things > > 1. I quickly post a new version of the draft > > 2. Ron put an RFC-editor note > > 3. We solve this during the AUTH48 > > > > I will let Ron decide what's best.**** > > ** ** > > This happens all the time, and it always puzzles me. What's the fear of > posting another rev of the doc? They're cheap and easy.**** > > ** ** > > Not to usurp Ron's decision of what's best in this case, but in general, = I > think that if one forgets to include something in a draft version, one > simply puts it in and posts another version. Voil=E0.**** > > ** ** > > Barry**** > --90e6ba25db951f782e04bf3e0289 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As I see it, there's little reason to complain about that now. =A0There= are both tracker and tools links that give you the latest version, regardl= ess of what version was specified in the last call note, and the tracker li= nk is now included in the last call. =A0The answer to the question is alway= s, "The latest one, of course." =A0It's silly to have people = reviewing errors that have already been corrected and text that's alrea= dy changed.

Barry

On Friday, May 4, 2012, Murray S. = Kucherawy wrote:=A0

In the past when I=92ve done this during a L= ast Call (IETF or WG, can=92t remember), someone else complained in the for= m of =93So what version exactly are we supposed to be reviewing here?=94=A0 I think that=92s where my own hesitation comes= from when this decision needs to be made.

-MSK=

=A0<= /p>

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Barry Leiba
Sent: Friday, May 04, 2012 7:48 AM
To: Benoit Claise
Cc: apps-discuss@ietf.org; paitken@cisco.com; nirbd@cisco.com; iesg@ietf.org
Subject: Re: [apps-discuss] APPSDIR review of draft-claise-export-ap= plication-info-in-ipfix-05

=A0

> I just posted a new version of=A0draft-claise-export-a= pplication-info-in-ipfix, and

> forgot to include your comments.

...

> From here, we could do 3 things > =A0 =A0 1. I quickly post a new version of the draft
> =A0 =A0 2. Ron put an RFC-editor note
> =A0 =A0 3. We solve this during the AUTH48
>
> I will let Ron decide what's best.

=A0

This happens all the time, and it always puzzl= es me. =A0What's the fear of posting another rev of the doc? =A0They= 9;re cheap and easy.

=A0

Not to usurp Ron's decision of what's = best in this case, but in general, I think that if one forgets to include s= omething in a draft version, one simply puts it in and posts another versio= n. =A0Voil=E0.

=A0

Barry

--90e6ba25db951f782e04bf3e0289-- From barryleiba.mailing.lists@gmail.com Fri May 4 18:25:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3565021E801F; Fri, 4 May 2012 18:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc1bf5ABTHPC; Fri, 4 May 2012 18:25:05 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D33021E8018; Fri, 4 May 2012 18:25:04 -0700 (PDT) Received: by lagj5 with SMTP id j5so2763886lag.31 for ; Fri, 04 May 2012 18:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Pr8tvjhdSF7EpXJNFRM7XtR1vdqMjQ572SCeNvqXkUk=; b=LlVDaTrMNRdxox9oMcklw+tB1otZ2VBvljaQY485zKAFSXJhlKjk4IPHu50ei/Vr2i tV86UaQYAFyX2KMGKcKniGd3fNrkiJxa4QBD9OFwjz5tY6hfUYDYn44jTZrHDsLfnFTu Ny7H2sMNoP9rATNq+bbInHNFHMKhAs3yHohm8crYLpO40PHs/YKDtW7hjXjE6Z5+k9Ta kWRP3GanBavDUgvGevQzbnakmF9mcPB30NMzkcEAKRt69SSPqxAo5NjDqhAd+rCpCn/z 36181JDAmZLOtzsYM8WTXJmxRyujxmjfS7qRhKgVu5UPe9ARxwhzB7xxSyaO9We0CToS XUVw== MIME-Version: 1.0 Received: by 10.112.88.98 with SMTP id bf2mr3951061lbb.30.1336181104033; Fri, 04 May 2012 18:25:04 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Fri, 4 May 2012 18:25:03 -0700 (PDT) In-Reply-To: <4FA04B17.9050902@gulbrandsen.priv.no> References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> Date: Fri, 4 May 2012 21:25:03 -0400 X-Google-Sender-Auth: 3iRNGhqzeS9H2fjK9uUn6eLGKtM Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=bcaec554da2a0fbec104bf3fe82e Cc: "ima@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 01:25:06 -0000 --bcaec554da2a0fbec104bf3fe82e Content-Type: text/plain; charset=ISO-8859-1 >> 7. IANA Considerations >> >> ADD the name of the correct registry! > > I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name. Oy. Sorry: you're both being lazy. The IANA registries are here: http://www.iana.org/protocols/ One can (and should) look up the registry, and use the correct name, without guessing. That said, Claudio didn't look it up either, and as it turns out, Arnt (1) did use the correct name and (2) between the correct name and the reference to the creating RFC, specified it entirely adequately for IANA to understand it. In other words, the IANA section is fine. Barry --bcaec554da2a0fbec104bf3fe82e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> 7. IANA Considerations
&= gt;>
>> ADD the name of the correct registry!
>
> I= 'm afraid the schmuck who wrote RFC 5530 didn't define a correct na= me.

Oy. =A0Sorry: you're both being lazy. =A0The I= ANA registries are here:
http://www.iana.org/protocols/<= /a>

In other words, the IANA section is fine.

Barry
--bcaec554da2a0fbec104bf3fe82e-- From mrex@sap.com Fri May 4 18:43:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A1A21E8018; Fri, 4 May 2012 18:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.775 X-Spam-Level: X-Spam-Status: No, score=-9.775 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxQlSX2FXY9z; Fri, 4 May 2012 18:43:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C2DFF21F84EE; Fri, 4 May 2012 18:43:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q451hRgw017094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 03:43:27 +0200 (MEST) From: Martin Rex Message-Id: <201205050143.q451hQnW011408@fs4113.wdf.sap.corp> To: marka@isc.org (Mark Andrews) Date: Sat, 5 May 2012 03:43:26 +0200 (MEST) In-Reply-To: <20120504000220.0F9632063979@drugs.dv.isc.org> from "Mark Andrews" at May 4, 12 10:02:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ondrej.sury@nic.cz, iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Subject: Re: [apps-discuss] [dane] MX and DANE (Was: AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 01:43:31 -0000 Mark Andrews wrote: > > O. writes: > > > > On 3. 5. 2012, at 17:25, Richard L. Barnes wrote: > > > Oh, this discussion again. > > > > No, it's _not_ that discussion again. I wanted to say that we > > don't _want_ to discuss and fix it in the DANE WG. Somebody fix > > it elsewhere and come back. 100 ack. > > While this isn't be a issue for DANE, DANE actually *removes* the > last known threat, downgrade by filtering/not offering STARTTLS > from the EHLO response, to making MX and STARTTLS work globally as > it provides a method to signal that TLS should be available and as > a consequence you should see a STARTTLS. Please do not confuse DANE with DNSSEC. example: foo.x. IN MX 10 mx.bar.y. mx.bar.y. IN CNAME tweety.baz.z. tweety.baz.z. IN A 0.1.2.3 plus: foo.x. is a DNS-Zone with DNSSEC enabled bar.y. is a DNS-Zone without DNSSEC baz.z. is a DNS-Zone with DNSSEC enabled The DNS software module does not know about MX records and will not look at any of the above. To _me_ this looks like opening a can of worms, not like closing one, and the apps protocols that want such scenarios secured by DNSSEC, will have to design and discuss their desired security architecture, how to perform&implement the various lookups and possible indirections, how to compute the desired result/outcome from the various possibilities leveraged by the DNS magic machinery and describe: - to implementers of the apps protocol how to implement this - to admins of the machines how to configure the various possible scenarios and provide a security considerations about all the potential and non-obvious pitfalls. Btw. in the example above, "mx.bar.y. IN CNAME tweety.baz.z." could have been a DNS reply spoofed by an attacker. I have significant doubts, that DANE is the right forum to discuss any of these very apps-specific characteristics and requirements. And DANE-protocol LC is definitely the wrong time for it (IIRC, the DANE WG tabled this discussion before it got deeply ratholed over it). *I* really do not want to discuss this any further. -Martin From internet-drafts@ietf.org Fri May 4 21:14:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237E621F845F; Fri, 4 May 2012 21:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.067 X-Spam-Level: X-Spam-Status: No, score=-102.067 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQYaIVPHtezF; Fri, 4 May 2012 21:14:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFFD21F8446; Fri, 4 May 2012 21:14:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120505041437.15982.68906.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 21:14:37 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 04:14:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-07.txt Pages : 31 Date : 2012-05-04 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-07.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ From mrex@sap.com Fri May 4 21:38:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D139021F845A; Fri, 4 May 2012 21:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4GOw9ONtAqh; Fri, 4 May 2012 21:38:18 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 126A521F844E; Fri, 4 May 2012 21:38:17 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q454cDSR002960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 06:38:13 +0200 (MEST) From: Martin Rex Message-Id: <201205050438.q454cC0K021676@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Sat, 5 May 2012 06:38:12 +0200 (MEST) In-Reply-To: <20120504223816.GV7394@crankycanuck.ca> from "Andrew Sullivan" at May 4, 12 06:38:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: mrex@sap.com, dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 04:38:20 -0000 Andrew Sullivan wrote: > > On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: > > > > We added similar text like the above to rfc6066 (TLS extensions) > > for the description of the extension "Server name indication" here: > > The problem in this case, however, is that what the TLSA document is > doing is building a QNAME for use in the DNS. None of the description > from RFC 6066 is a domain name. > > Remember, the dot-separated labels are the presentation form, but > _not_ what you send on the wire. Dots aren't part of the DNS on the > wire. > > What we want to do for this case is get the QNAME for the DNS. So we > take the two labels that come out of steps 1 and 2 in the draft, and > put them on the front of the DNS name that we're trying to look up, > creating an absolute, fully qualified name that gets sent in the QNAME > of the DNS operation. > > At least I think that's what the section is trying to do. > > I'm also uncomfortable with the "ASCII" stuff, because DNS labels > aren't in ASCII. They're octets. However, ASCII is treated specially > in the DNS. (This is one of the sharp edges about the DNS that we'd > all like to go back and fix if we could.) Thanks for pointing out the details. I have been an occasional caller of gethostbyname(), and not used libresolv function() like res_query(). Do we expect the target audience (folks implementing DANE protocol) to use an API like that of libresolv's res_query(), where the representation appears to be still a single string rather than individual DNS labels, or that they're caller of even lower APIs? The name that gets prefixed by protocol and port should probably represent an absolute, fully qualified name as is, and be used with res_query? The default behaviour of gethostbyname(), trying completion of a name that doesn't end with a dot/period with (default) domain or entries from a (domain) searchlist (res_search?) would likely risk unpleasant consequences. -Martin From McQuilWP@pobox.com Sat May 5 01:21:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A754621F84B2 for ; Sat, 5 May 2012 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvQ0RIW686xH for ; Sat, 5 May 2012 01:21:04 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 083C821F8435 for ; Sat, 5 May 2012 01:21:03 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id E30CB3323; Sat, 5 May 2012 04:21:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:mime-version:content-type :content-transfer-encoding; s=sasl; bh=Cbmsq+XuOxZjjmBS2WclT5H7f tA=; b=R6FnNP3DcY52AcIYlejyQc4qqd8Ku+gkW15hbRx9eVKR77LXFxfdKe/xZ aTv4v1QZqxLirdHjhDDLrExNz2r61NEAA6UZ4qyUJJFAtHStKRXGUhNDUvqHmBDX w8QYqvtlCyJM3366DE67UiZZRA5gOon9hlUZKK+n1xCYygMN2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=sasl; b=QKsFITQzKwyHA2nI63m NVVmn/oAwv5dDkYVEouqa0vBZZXYwDQFYKeteiFQ17rk2XMCJjSnr37rGf1P12lF 6am8E+Yabu9YR0/53AZodZMQzUkpswF2Mbb79Ey+bbKNFk8NNREgLFwiSqrfZ+Fx 87kBIBBxT4kXuOmgzMSKET2M= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id DAFCC3322; Sat, 5 May 2012 04:21:01 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 56D893321; Sat, 5 May 2012 04:21:01 -0400 (EDT) Date: Sat, 5 May 2012 01:20:59 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <387277348.20120505012059@pobox.com> To: Apps-Discusssion MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 3FFAA228-968B-11E1-9CFD-FC762E706CDE-02871704!b-pb-sasl-quonix.pobox.com Subject: [apps-discuss] draft-ietf-appsawg-received-state-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 08:21:04 -0000 I have reviewed this draft and (other than a typo, sent to the authors) I agree that it is ready for publication. -- Bill McQuillan From julian.reschke@gmx.de Sat May 5 01:32:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97921F8546 for ; Sat, 5 May 2012 01:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCvRnNSjAT2k for ; Sat, 5 May 2012 01:32:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8615B21F8543 for ; Sat, 5 May 2012 01:32:20 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2012 08:32:18 -0000 Received: from p54BB3218.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.50.24] by mail.gmx.net (mp024) with SMTP; 05 May 2012 10:32:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19780sBGbB7J+AUVTzPym0yP8tRmOKaazrQVdubpK wRvg6NeX+xr/dZ Message-ID: <4FA4E58A.2040102@gmx.de> Date: Sat, 05 May 2012 10:32:10 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-levine-application-gzip@tools.ietf.org, IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: standards@taugh.com, The IESG Subject: [apps-discuss] Applications Area Directorate Review of draft-levine-application-gzip-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 08:32:22 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-levine-application-gzip-02 Title: The application/zlib and application/gzip media types Reviewer: Julian Reschke Review Date: 2012-05-05 IETF Last Call Date: from 2012-05-03 to 2012-05-31 IESG Telechat Date: - Summary: This document defines media types for gzip and zlib compression. It is ready for publication with minor editorial issues. Major Issues: None. Minor Issues: The document needs an IANA Considerations Section. That Section could either contain the registration templates, or just reference them. In the actual templates, I recommend the following changes: "Published specification:" - I would make these pointers to Sections 2 and 3 of draft-levine-application-gzip; referencing the base specs directly here would mean that draft-levine-application-gzip doesn't get referenced in the media types registry at all. "Encoding considerations": says this should one of "7bit", "8bit", "framed", or "binary". So maybe change to: "binary - needs base64 or other encoding that allows arbitrary binary data when transmitted over non-binary transports" (or just say "binary"). Best regards, Julian From julian.reschke@gmx.de Sat May 5 01:40:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F11E21F8548 for ; Sat, 5 May 2012 01:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwZkzplhhPdI for ; Sat, 5 May 2012 01:40:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2452F21F8546 for ; Sat, 5 May 2012 01:40:36 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2012 08:40:36 -0000 Received: from p54BB3218.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.50.24] by mail.gmx.net (mp072) with SMTP; 05 May 2012 10:40:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18UMI09M8gUHBm/fu/BMDw5LYh3pA25+PszsRrMYZ BjoLLAnW3mV3Rr Message-ID: <4FA4E780.8000907@gmx.de> Date: Sat, 05 May 2012 10:40:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-levine-application-gzip@tools.ietf.org, IETF Apps Discuss References: <4FA4E58A.2040102@gmx.de> In-Reply-To: <4FA4E58A.2040102@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: standards@taugh.com, The IESG Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-levine-application-gzip-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 08:40:38 -0000 On 2012-05-05 10:32, Julian Reschke wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-levine-application-gzip-02 > Title: The application/zlib and application/gzip media types > Reviewer: Julian Reschke > Review Date: 2012-05-05 > IETF Last Call Date: from 2012-05-03 to 2012-05-31 > IESG Telechat Date: - > > Summary: This document defines media types for gzip and zlib > compression. It is ready for publication with minor editorial issues. > ... Forgot to mention: I did *not* check the correctness of the "magic number" field. Best regards, Julian From julian.reschke@gmx.de Sat May 5 04:06:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0921F849D for ; Sat, 5 May 2012 04:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50aQKpnWQAkE for ; Sat, 5 May 2012 04:06:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8784E21F8459 for ; Sat, 5 May 2012 04:06:29 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2012 11:06:28 -0000 Received: from p54BB3218.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.50.24] by mail.gmx.net (mp017) with SMTP; 05 May 2012 13:06:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+4Lil3IzS45gOMoVoDlDN8ns75uASxHf4Xzu4O+7 Y8QfdGjnFX9PVb Message-ID: <4FA5099B.5000205@gmx.de> Date: Sat, 05 May 2012 13:06:03 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andreas Petersson References: <4FA02AEA.1080407@isode.com> <29236FD5-51E7-4AC5-88EA-6B956E453D8A@niven-jenkins.co.uk> <20120504110515.18679e43@hetzer> In-Reply-To: <20120504110515.18679e43@hetzer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 11:06:30 -0000 On 2012-05-04 11:05, Andreas Petersson wrote: > Hi, > > Thanks for the feedback! > See inlined comments below. > > /Andreas > > > On 5/2/12 5:59 PM, Ben Niven-Jenkins wrote: >> 1. The ABNF gives: >> >> forwarded-pair = token "=" ( token / quoted-string ) >> token = 1*( /[-!#$%&'*+.^_`|~0-9A-Z]/ ) # httpbis-p1 S3.2.4 >> >> It is a happy coincidence that an IPv4address without an optional >> port happens to fall within the token syntax and therefore does >> not need to be a quoted-string, but neither an IPv4address with >> the optional port (which involves ":" which is not in tchar) or >> an IPv6address with or without port (which involve "[", "]" and ":" >> none of which are in tchar) are valid tokens and MUST be sent >> as quoted-string. >> >> What might casually seem to some to be the same syntax element >> therefore has different quoting/escaping rules depending on its >> exact makeup. Generators need to beware. Some might take the view >> that it is safest and easiest to simply use quoted-string in all >> cases, so consumers also need to beware that even an IPv4address >> with no port might be sent as a quoted-string. >> >> I think this should be explicitly called out, given this draft gets >> it wrong itself (see below). > > Right. I missed that those chars isn't part of tchar. > I will add some warnings about this and also make sure > to get it right in the examples. :-) > ... +1 The alternative would be to use a different syntax, not reusing HTTP parameter syntax. I think this would be a mistake, though; it just needs even more custom parsers need to be written. So I think examples and a big fat warning in the prose are the right thing to do here. Best regards, Julian From julian.reschke@gmx.de Sat May 5 04:10:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38CA21F8566 for ; Sat, 5 May 2012 04:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQrZgIb85yGa for ; Sat, 5 May 2012 04:10:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EAB7921F8569 for ; Sat, 5 May 2012 04:10:58 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2012 11:10:57 -0000 Received: from p5DD9569A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.86.154] by mail.gmx.net (mp004) with SMTP; 05 May 2012 13:10:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/XnixNVH7X6lbTvit88h2Fdl9/qCNym6mKqXQZpk BSgqrDKTyaod+V Message-ID: <4FA50AAD.9090807@gmx.de> Date: Sat, 05 May 2012 13:10:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <4FA02AEA.1080407@isode.com> In-Reply-To: <4FA02AEA.1080407@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] WGLC comments on draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 11:11:00 -0000 Hi there, first of all: thanks for taking the work, Andreas & Martin! I've got one nit right now: > Given that a proxy wishes to add a Forwarded header field to the > outgoing request, if the incoming request has no such header field, > the proxy simply adds the header with the list of parameters desired. > If, on the other hand, the incoming request has such a header field, > the proxy adds a comma and the list of parameters. A proxy MAY > remove all Forwarded header fields from a request. It MUST, however, > ensure that the correct header field is updated in case of multiple > Forwarded header fields. As the header field uses HTTP list syntax, it's also possible (and maybe simpler) to simply add another instance to the list of headers. Best regards, Julian From paul.hoffman@vpnc.org Sat May 5 07:22:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A307F21F854F; Sat, 5 May 2012 07:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izD-imIIjxhU; Sat, 5 May 2012 07:22:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5C08321F8548; Sat, 5 May 2012 07:21:55 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q45ELpKW060046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 5 May 2012 07:21:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120504223816.GV7394@crankycanuck.ca> Date: Sat, 5 May 2012 07:21:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 14:22:00 -0000 On May 4, 2012, at 3:38 PM, Andrew Sullivan wrote: > On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: >>=20 >> We added similar text like the above to rfc6066 (TLS extensions) >> for the description of the extension "Server name indication" here: >=20 > The problem in this case, however, is that what the TLSA document is > doing is building a QNAME for use in the DNS. None of the description > from RFC 6066 is a domain name. >=20 > Remember, the dot-separated labels are the presentation form, but > _not_ what you send on the wire. Dots aren't part of the DNS on the > wire. =20 >=20 > What we want to do for this case is get the QNAME for the DNS. So we > take the two labels that come out of steps 1 and 2 in the draft, and > put them on the front of the DNS name that we're trying to look up, > creating an absolute, fully qualified name that gets sent in the QNAME > of the DNS operation. =20 >=20 > At least I think that's what the section is trying to do. It is indeed what the section is trying to do. > I'm also uncomfortable with the "ASCII" stuff, because DNS labels > aren't in ASCII. They're octets. However, ASCII is treated specially > in the DNS. (This is one of the sharp edges about the DNS that we'd > all like to go back and fix if we could.) Note that the document explicitly states in the last paragraph of = section 1.2 that "This document only relates to securely associating = certificates for TLS and DTLS with host names". We are not talking just = "domain names" (which are made up of labels of octets) but "host names" = which are made up of labels of ASCII. We were told (wisely) not to try = to reopen this can of worms, so we didn't. As you pointed out, Peter's proposed wording had an issue by mentioning = the "dots". That can easily be fixed. I now propose: OLD 3. The domain name is appended to the result of step 2 to complete the prepared domain name. NEW 3. The domain name is appended to the result of step 2 to complete the prepared domain name. (The domain name is the fully qualified DNS domain name [RFC1035] of the TLS server and is represented as a byte string where each label is encoded using ASCII; this enables support for internationalized domain names through the use of A-labels as defined in [RFC5890].) --Paul Hoffman From Claudio.Allocchio@garr.it Sat May 5 07:34:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A27521F8498; Sat, 5 May 2012 07:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAmzf7xuYphB; Sat, 5 May 2012 07:34:14 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D421F8495; Sat, 5 May 2012 07:34:13 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q45EY0ft096799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 May 2012 16:34:07 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q45EY0ft096799 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=AWVXxGfSiV+kEckB3XJx0AzPL9W1dMAG623qxoRacZ6DF03ukFmKRYXnvvptkQ9dQ cZNnFhdfzJ1S7i1vQthRuDBC+iWG4Cbq2FEPaBPDJTcE1NfD0vD+70Ufh6th3m0Joh0 yFRpPCYjTYQskcv388CSwdIXg7GATDYrPJbRbHw= Date: Sat, 5 May 2012 16:34:01 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Barry Leiba In-Reply-To: Message-ID: References: <6.2.5.6.2.20120501024024.0a3684f0@resistor.net> <4FA04B17.9050902@gulbrandsen.priv.no> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Arnt Gulbrandsen , "ima@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [EAI] AppsDir Review of draft-ietf-eai-simpledowngrade-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 14:34:15 -0000 On Fri, 4 May 2012, Barry Leiba wrote: >>> 7. IANA Considerations >>> >>> ADD the name of the correct registry! >> >> I'm afraid the schmuck who wrote RFC 5530 didn't define a correct name. > > Oy. Sorry: you're both being lazy. The IANA registries are here: > http://www.iana.org/protocols/ yes... but? > One can (and should) look up the registry, and use the correct name, > without guessing. that's why I added my Nits note. > That said, Claudio didn't look it up either, and as it turns out, Arnt (1) True, I did not loked at it. > did use the correct name and (2) between the correct name and the reference > to the creating RFC, specified it entirely adequately for IANA to > understand it. > > In other words, the IANA section is fine. that why "(RFC editor: Please remove this paragraph. I can't remember the URL of the registry, but it's the one specified in RFC 5530.)" ? ;-) but as I said, it's a Nit. > Barry > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From w@1wt.eu Sat May 5 07:41:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED51121F84C4 for ; Sat, 5 May 2012 07:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=-3.985, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgIQk4aUtd3L for ; Sat, 5 May 2012 07:41:28 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D4CF421F84AF for ; Sat, 5 May 2012 07:41:27 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q45EfLMe009900; Sat, 5 May 2012 16:41:21 +0200 Date: Sat, 5 May 2012 16:41:21 +0200 From: Willy Tarreau To: Julian Reschke Message-ID: <20120505144121.GA8105@1wt.eu> References: <4FA02AEA.1080407@isode.com> <4FA50AAD.9090807@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA50AAD.9090807@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC comments on draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 14:41:29 -0000 Hi Julian, On Sat, May 05, 2012 at 01:10:37PM +0200, Julian Reschke wrote: > Hi there, > > first of all: thanks for taking the work, Andreas & Martin! > > I've got one nit right now: > > > Given that a proxy wishes to add a Forwarded header field to the > > outgoing request, if the incoming request has no such header field, > > the proxy simply adds the header with the list of parameters desired. > > If, on the other hand, the incoming request has such a header field, > > the proxy adds a comma and the list of parameters. A proxy MAY > > remove all Forwarded header fields from a request. It MUST, however, > > ensure that the correct header field is updated in case of multiple > > Forwarded header fields. > > As the header field uses HTTP list syntax, it's also possible (and maybe > simpler) to simply add another instance to the list of headers. That's the point I wanted to add too. Haproxy does this right now, as well as stunnel (with appropriate patch). It's generally the easiest solution on gateways which modify as little the input stream as possible. Best regards, Willy From johnl@taugh.com Sat May 5 08:37:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3692921F85D2 for ; Sat, 5 May 2012 08:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZYooKru60sz for ; Sat, 5 May 2012 08:37:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7317821F85CC for ; Sat, 5 May 2012 08:37:42 -0700 (PDT) Received: (qmail 33294 invoked from network); 5 May 2012 15:37:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=820c.4fa54944.k1205; bh=piA8q8iSt8r06trbdU7NWmH88bdDu5un2/gwaFlB9aw=; b=fkNFdRV3f+8lXE4A0O6uymD/qv32gZ76tDaC0SEWk/+KMiYq9e2hmv9vdqRZttytCdBemONdjwBVmRi+nxAqGc/ZoqjNH0WlQxawOhSmSzzHf7OXajm7ZAGtKCHGADC2lTkXws8Sczm/cRcSCZsvjDLA9PTFTYnF4qYfF46xSuc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=820c.4fa54944.k1205; bh=piA8q8iSt8r06trbdU7NWmH88bdDu5un2/gwaFlB9aw=; b=P3a10ve2Iyc3ljOuCDZiAbYQCKFQku9knZhUbfJKjfz2rCtBPUWG1jyhcvH1+ebJFMECXMCoAQ90/dyvmutrmS8oxz+tNhRZplGSjRc5rFjYbnudp9ZgZ3OgjcfQw7ikKhskFgEU1dQECkFIrBCNTpqKdiX7Nf80ut8Jz5QTLXE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 5 May 2012 15:37:17 -0000 Date: 5 May 2012 11:37:39 -0400 Message-ID: From: "John R Levine" To: "Julian Reschke" In-Reply-To: <4FA4E58A.2040102@gmx.de> References: <4FA4E58A.2040102@gmx.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-levine-application-gzip-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 15:37:43 -0000 > "Published specification:" - I would make these pointers to Sections 2 and 3 > of draft-levine-application-gzip; referencing the base specs directly here > would mean that draft-levine-application-gzip doesn't get referenced in the > media types registry at all. I think it's OK the way it is. Look at RFC 3778 which defines application/pdf. Its published spec is the Adobe reference books, but the media registry entry refers to the RFC. Most RFCs that register media types also define the media so they point to themselves, but the few that don't point to the base specs. Other than that, I agree with your comments, and the next version will reflect them. I also checked the magic numbers, added a sentence to describe the checksum in the first two bytes of a zlib file. Regards, John From stephen.farrell@cs.tcd.ie Sat May 5 10:16:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159CB21F84FD for ; Sat, 5 May 2012 10:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbcFiMSYR-SR for ; Sat, 5 May 2012 10:16:37 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id DD46A21F84EB for ; Sat, 5 May 2012 10:16:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5FB36157B18; Sat, 5 May 2012 18:16:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1336238194; bh=mWFaS61rXsbyWI v7Rniaw4Ug5mMMDJeLT4IlLrclOEc=; b=ICkwxzUTBcT2Xtfnqg/kc88ACMkX4Q sUDUil2KSbyH7MFS5P0vS6bTYzrgvmjl7HHgbjENLifpLQAlDXixs1ALiiZTQJQn raunqv/RvOa968v5UU7zNz88jCgbO+SmcXQ/FmP6GE6Chqjiv3wYB0Bji0a7X4hm m+fp5TOwrOEkAWkfQTRyRL1ydz+GrPejt2Xbo5WkFUizO+k3HOaiS39iiJ0A/cwJ 8yWTNS8q2twP8R5eAizoNHvfPDBt6qvvknaA1UXWSiaaXoneEjdsTcvTOinpkzpF rnC2CnBkwQLxjxyYDuYGtYBUDiDO5Sfg8XA+Lr+zyiJh/l59eazlhwnw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 0Vez6K733DS2; Sat, 5 May 2012 18:16:34 +0100 (IST) Received: from [192.168.212.241] (unknown [209.117.47.251]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CB43E157B17; Sat, 5 May 2012 18:16:28 +0100 (IST) Message-ID: <4FA5606C.8090401@cs.tcd.ie> Date: Sat, 05 May 2012 18:16:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] CRC vs check digit in draft-farrell-decade-ni X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 17:16:41 -0000 Hi James, On 05/01/2012 03:17 AM, Manger, James H wrote: > A check digit would be more appropriate than an CRC for the human-readable format in "Naming Things with Hashes" . The draft currently has an optional 16-bit CRC, represented with 4 hex digits. CRCs are really designed for detecting bit errors (or bursts of bit errors). Check digits, on the other hand, are designed to detect human errors (changing digits, transposing digits etc). 1 or 2 check digits are sufficient, instead of 4 chars for a 16-bit CRC. > > Most check digit algorithms work on decimal digits. This draft needs one for a string or at least for hex digits. Perhaps the Luhn mod N algorithm would be suitable ? Using N=16 and calculating the checksum over just the hex digits of the hash should work well. Such a checksum doesn't "protect" the algorithm name, but it doesn't need to as there are only a handful of valid values anyway. Such a checksum would also ignore the case of hex digits. It doesn't change if you switch from an alg name to id (eg "sha-256-120" to "3"). > > P.S. The examples in draft 05 all look correct now. Well, let's see if I break 'em again:-) People liked your idea of the Luhn checkdigit so if you're in the mood to check if I've gone wrong again I'd really appreciate that. I've added this text for the nih bit: The hash value is OPTIONALLY followed by a checkdigit. The checkdigit MUST be calculated using Luhn's mod N algorithm (with N=16) as defined in [ISOIEC7812], (see also http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm). The input to the calculation is the ASCII-HEX encoded hash value (i.e. "val" in the ABNF production below). This maps the ASCII-HEX so that '0'=0,...'9'=9,'a'=10,...'f'=15. None of the other fields are input when calculating the checkdigit. And then using the python-stdnum package I get the following examples: +-------------------------------------------------------------------+ | Human-readable form of a name for this key (truncated to 120 bits | | in length) with checksum: | | nih:sha-256-120;53269057e12fe2b74ba07c892560a2;f | +-------------------------------------------------------------------+ | Human-readable form of a name for this key (truncated to 32 bits | | in length) with checksum: | | nih:sha-256-32;53269057;b | +-------------------------------------------------------------------+ | Human-readable form using decimal presentation of the | | algorithm ID (sha-256-120) with checksum: | | nih:3;53269057e12fe2b74ba07c892560a2;f | +-------------------------------------------------------------------+ Thanks in advance, if you've time, Stephen. > > -- > James Manger > From ralimi@google.com Fri May 4 17:35:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C8121E801F for ; Fri, 4 May 2012 17:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TthhcjdLTTRW for ; Fri, 4 May 2012 17:34:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8235D21E8012 for ; Fri, 4 May 2012 17:34:58 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2745930lbb.31 for ; Fri, 04 May 2012 17:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=ZHPLbmFiU2qKb0eI9DK87D6IJu1Zc+Uo+Q6mhhg3JRE=; b=VfDgiSY/2nsJZ1fUE9R5YR8+rFNDRdZ9veUe6r5ksugCT73PQyHlLREjziTII2f6pZ ka7cPgisF5ytN9N/QQRF/o/q5mvNdHUOeYFaLoTBnZetB9shCoWeQClJl5EqTL1VymX+ ir3v/Cb3D/ekyZGqw7RzGjxPHgvMntgtQOJc4PqQ3EvT5D3NJFzAXpsn0hfKwJLYO5UM NMwE83eYES/MqSEqcyP8mwxJOw9LzPYIHJkaEJS93WI8j074K07CBGMnH/HOX13EXkT1 RryojU3zT/paE6VnmmaMX3eO8I4goQkz1ue0VD3r0X+JCz4AdAmFD9Td1zo4x45tkaBh 5Pcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=ZHPLbmFiU2qKb0eI9DK87D6IJu1Zc+Uo+Q6mhhg3JRE=; b=XZS6sP0XGKmd5t7S3D+Opr5MoE02BiohvQ9rvm9GXwpEjuKAxvLkVyg8cpX76ZbmPU XzW1lMBmD0Ed3Vy64hUIjkpQup5AD78LAOZ90ExNKHGFa4DyvZfaKj08J+9uInZTNgmk RTwHYBqUeIHcgtjts3W8LdYBY5ujPZtw/upGwyytISrSwoiAULStMqSVnjvff2lsYTaJ GD8JsicX5kabYLTu0AaNBuOC3E8elfXko/awmQaw7ycCVbxVG3VEJayvNjEmBlBMiU1O VIJc35mYUkmoQ1GD6KhysQAxkG7KfHiX9nTq34L51EpZkVLf3dvsYSEE6T5lPrj1Vm2K Egkw== Received: by 10.152.112.161 with SMTP id ir1mr7575469lab.13.1336178097366; Fri, 04 May 2012 17:34:57 -0700 (PDT) Received: by 10.152.112.161 with SMTP id ir1mr7575448lab.13.1336178097191; Fri, 04 May 2012 17:34:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.134.97 with HTTP; Fri, 4 May 2012 17:34:26 -0700 (PDT) In-Reply-To: <4FA28A5D.4050904@bell-labs.com> References: <2DE7DDDA-6621-4E56-BD3D-1173833E672B@niven-jenkins.co.uk> <98BA299A-18E0-412C-A005-754F336E1620@niven-jenkins.co.uk> <30166A91-3C02-48F7-8C3B-179DA770138C@niven-jenkins.co.uk> <4DC76AEC-2DCE-4DE4-B92C-C37F160DA7FF@niven-jenkins.co.uk> <4FA28A5D.4050904@bell-labs.com> From: Richard Alimi Date: Fri, 4 May 2012 17:34:26 -0700 Message-ID: To: "Vijay K. Gurbani" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk3pm/kwaBQz9l405PEzwos8SAVMUx99UPMrAok/5zFflCWJC+mGrRUPU+RyAs/BUMMDSkfplY6ZBjupEHeQkg2sGObITpRW8LnP7h6qkiltIhmFbaX4z8S3ciJ666c5HB8XeQqYI5/bqCQstPzqPMiYm3skQ== X-Mailman-Approved-At: Sat, 05 May 2012 12:55:20 -0700 Cc: draft-ietf-alto-protocol.all@tools.ietf.org, alto , apps-discuss@ietf.org Subject: Re: [apps-discuss] [alto] Review of draft-ietf-alto-protocol-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 00:35:03 -0000 On Thu, May 3, 2012 at 6:38 AM, Vijay K. Gurbani wrote: > On 05/03/2012 01:59 AM, Ben Niven-Jenkins wrote: >>> >>> This seems reasonable to me, except would it be appropriate to >>> have this kind of document dependency? =A0Would it be more >>> appropriate to just reference RFC2616? >> >> >> Up to you. HTTPBIS is in the process of putting the HTTPBIS specs >> through WG LC so there is light at the end of the tunnel for them >> popping out as RFCs. I referred to the HTTPBIS document because it's >> easier to find an appropriate reference but similar material is in >> 2616. > > > If the reference to HTTPBIS is informative, then we are not gated > by HTTPBIS reaching the terminal state of RFC assignment. > > So the question to Rich A. would be whether he thinks that the > reference we put in fits better as Informative or Normative. > If the former, then we can move ahead without any delays. Based on my understanding, this seems like a normative reference. If someone thinks otherwise, please say so and I'll be happy to add a reference to HTTPbis instead :) Rich > > Thanks, > > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: =A0 http://ect.bell-labs.com/who/vkg/ From w@1wt.eu Sat May 5 23:07:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ECE21F8493 for ; Sat, 5 May 2012 23:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[AWL=-4.866, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTM8CEKP2d6O for ; Sat, 5 May 2012 23:07:55 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 175EA21F8491 for ; Sat, 5 May 2012 23:07:53 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q4667ow1012618; Sun, 6 May 2012 08:07:50 +0200 Date: Sun, 6 May 2012 08:07:50 +0200 From: Willy Tarreau To: Andreas Petersson Message-ID: <20120506060750.GC8105@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 06:07:56 -0000 Hi Andreas, I'd like to propose the following point for "8.1. Header validity and integrity". For a long transition period, origin servers will be facing requests holding both X-Forwarded-* header fields and the new Forwarded header field. The only way to decide which one is the right one cannot be determined by any information carried in the request such as the header fields presence or order. The only way to know what header to rely on depends on the previous trusted proxy or gateway in the chain, and such information may only be specified in the origin server's configuration. Servers behind a trusted reverse proxy will likely be configured to use only one header field. Servers behind multiple trusted reverse proxies might be configured to use either header field depending on the incoming connection's source address. I have another point related to this : should we encourage proxies and gateways to convert X-Forwarded-* header fields from requests to Forwarded when possible ? It would solve most of the trouble on origin servers during the transition period I think, at least in hosted environments where the header field names are all controlled by the same admin. Regards, Willy From James.H.Manger@team.telstra.com Sun May 6 04:41:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D7E21F8462 for ; Sun, 6 May 2012 04:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0fVmkFido8U for ; Sun, 6 May 2012 04:41:01 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 72A0021F845C for ; Sun, 6 May 2012 04:40:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,538,1330866000"; d="scan'208";a="74762395" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 06 May 2012 21:40:58 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6702"; a="61638171" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcavi.tcif.telstra.com.au with ESMTP; 06 May 2012 21:40:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Sun, 6 May 2012 21:40:57 +1000 From: "Manger, James H" To: Stephen Farrell Date: Sun, 6 May 2012 21:40:55 +1000 Thread-Topic: CRC vs check digit in draft-farrell-decade-ni Thread-Index: Ac0q4tXo3Wz2027NRwSD5ag+jZuOQgAmP+dw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2853D2B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <4FA5606C.8090401@cs.tcd.ie> In-Reply-To: <4FA5606C.8090401@cs.tcd.ie> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] CRC vs check digit in draft-farrell-decade-ni X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 11:41:04 -0000 > People liked your idea of the Luhn checkdigit so if you're in the > mood to check if I've gone wrong again I'd really appreciate that. > > I've added this text for the nih bit: > > The hash value is OPTIONALLY followed by a checkdigit. The > checkdigit MUST be calculated using Luhn's mod N algorithm (with > N=3D16) as defined in [ISOIEC7812], (see also > http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm). The input to the > calculation is the ASCII-HEX encoded hash value (i.e. "val" in the > ABNF production below). This maps the ASCII-HEX so that > '0'=3D0,...'9'=3D9,'a'=3D10,...'f'=3D15. None of the other fields are i= nput > when calculating the checkdigit. This text look good, though it doesn't seem to mention the ";" between the = hash value and the checksum. Perhaps it should start: "The hash value is OPTIONALLY followed by a semicolon then a checkdigit." > | nih:sha-256-120;53269057e12fe2b74ba07c892560a2;f | > | nih:sha-256-32;53269057;b | > | nih:3;53269057e12fe2b74ba07c892560a2;f | I concur with these checkdigit calculations. (Curiously the 8 digits in the 32-bit example are all decimal digits (no a-= f) - but I doubt that will confuse anyone) -- James Manger From James.H.Manger@team.telstra.com Sun May 6 04:45:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56F521F8462 for ; Sun, 6 May 2012 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn7usO5UxxKy for ; Sun, 6 May 2012 04:45:10 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE7421F845C for ; Sun, 6 May 2012 04:45:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,538,1330866000"; d="scan'208";a="71964990" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 06 May 2012 21:45:08 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6702"; a="59942352" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdni.tcif.telstra.com.au with ESMTP; 06 May 2012 21:45:08 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Sun, 6 May 2012 21:45:08 +1000 From: "Manger, James H" To: Stephen Farrell , Ari Keranen , Apps Discuss Date: Sun, 6 May 2012 21:45:06 +1000 Thread-Topic: Indicating hash size in 'ni' URIs Thread-Index: Ac0myevxKiYXzeWPQCafdSTEA9q9nQAcYu9AARBsm1A= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 11:45:10 -0000 Section 2 "Basics" of draft-farrell-decade-ni-05 says "when a hash value is= truncated the name MUST indicate this". But why? It is easy to determine the amount of truncation (if any) from the length o= f the hash value in the 'ni' URI (or 'nih' URI or binary form). Instead of: nih:sha-256-32;53269057 why not use: nih:sha-256;53269057 The second form saves a few bytes, but more importantly it avoids the need = to register a new algorithm name for every truncation length that could hav= e any use. This is particularly important for the binary format that only h= as a 6-bit field (64 possibilities) to indicate the algorithm. 64 hash algs= sounds ok; 64 hash/length pairs sounds quite limiting. The truncation length in the alg name is not used to parse the URI (even in= the binary format). The one constraint the spec would need to state is that any truncation MUST= be on a byte (8-bit) boundary (so you can calculate the truncation length = from the number of base64url-chars in a 'ni' URI). -- James Manger From stephen.farrell@cs.tcd.ie Sun May 6 07:09:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3D121F84CD for ; Sun, 6 May 2012 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvcS5tS2zZXL for ; Sun, 6 May 2012 07:09:45 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EC36621F84C9 for ; Sun, 6 May 2012 07:09:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E6C7015356A; Sun, 6 May 2012 15:09:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1336313382; bh=HYjodcB2f/wU4l ytjU6kFEWXDm7wD3153CghzkRFgUA=; b=66kJzXaqq7OX12mglCMTdOeVS5cLBk RwZ5riE3Nz1sMki9ShYEEiW1hlMA/sh0oSsXf4P+60kpFBS9+Ii+FN67Str3+h5F iOPL6oSYyG3fpJI00ydP1SmCK84nx7FvLVd76OV3TA5uC1hjRFZgMNjcCVLmjw8P oSZBqC2+25biTcLo3iOuBDdsQXCjJOkksv9ZEa3a2Z7ZbjzezM640bKGdzRWP+vP btW2pdu1oAMLY4Fd4R5SRRCuyXH3iKNQInndnfFLA2mds+ZSv4+Avy30KJSOW66K tGu+YrhsyytcxkcpWSMt0aDawLmsUtSrUbI6FnWqMSyMd20Gdc97cvZA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id H+u7GsS0Kv63; Sun, 6 May 2012 15:09:42 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.65.213]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B86731716E5; Sun, 6 May 2012 15:09:39 +0100 (IST) Message-ID: <4FA68622.3010802@cs.tcd.ie> Date: Sun, 06 May 2012 15:09:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <4FA5606C.8090401@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F2853D2B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2853D2B@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] CRC vs check digit in draft-farrell-decade-ni X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 14:09:46 -0000 On 05/06/2012 12:40 PM, Manger, James H wrote: >> People liked your idea of the Luhn checkdigit so if you're in the >> mood to check if I've gone wrong again I'd really appreciate that. >> >> I've added this text for the nih bit: >> >> The hash value is OPTIONALLY followed by a checkdigit. The >> checkdigit MUST be calculated using Luhn's mod N algorithm (with >> N=16) as defined in [ISOIEC7812], (see also >> http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm). The input to the >> calculation is the ASCII-HEX encoded hash value (i.e. "val" in the >> ABNF production below). This maps the ASCII-HEX so that >> '0'=0,...'9'=9,'a'=10,...'f'=15. None of the other fields are input >> when calculating the checkdigit. > > This text look good, though it doesn't seem to mention the ";" between the hash value and the checksum. Perhaps it should start: > "The hash value is OPTIONALLY followed by a semicolon then a checkdigit." Sure. > >> | nih:sha-256-120;53269057e12fe2b74ba07c892560a2;f | >> | nih:sha-256-32;53269057;b | >> | nih:3;53269057e12fe2b74ba07c892560a2;f | > > I concur with these checkdigit calculations. > (Curiously the 8 digits in the 32-bit example are all decimal digits (no a-f) - but I doubt that will confuse anyone) Great, S > > -- > James Manger > From stephen.farrell@cs.tcd.ie Sun May 6 07:27:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E45E21F84BD for ; Sun, 6 May 2012 07:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5n1xBCKgQXM for ; Sun, 6 May 2012 07:27:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id AADD521F84B6 for ; Sun, 6 May 2012 07:27:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C87AC15356A; Sun, 6 May 2012 15:27:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1336314465; bh=YUCXHdCsxs5Q3L jDoPS+48Vrmnjjz0rH4pr2fyLqLLI=; b=yaCjr5eT1v+nsb1hLnFe/oPqLGCqGH iskeviipV3mbmUcSBzKi53Qaa1cNAq5cEDxO6WUj5qrWOqM0hd0huOolRiHF4G27 y0tSTVK2IFrJPR5JTrNucev4ek+OTxsF0OpLXkrUBm7OYN1qOEn54ESdpiXhUlCK a5KsADd7SpeyhIHzH9jFcJsSLLKoqLrr51CLundLdX801JFu+PcQZLOuiZP3/z/q qac+Tp5fORttlQZjZSykiIvWKgSMAsK7tSJf1dowkwhFFcK0qgp7WsDrP31aZFes zk9yU76tAMdMUmd+FEYZivGaJm1HEbG5NlQjwPJUU/ZA24NTRBeqUy7g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 1Z+Uw4esqgZl; Sun, 6 May 2012 15:27:45 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.65.213]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 600151716E7; Sun, 6 May 2012 15:27:45 +0100 (IST) Message-ID: <4FA68A60.6030207@cs.tcd.ie> Date: Sun, 06 May 2012 15:27:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 14:27:47 -0000 Hi James, On 05/06/2012 12:45 PM, Manger, James H wrote: > Section 2 "Basics" of draft-farrell-decade-ni-05 says "when a hash value is truncated the name MUST indicate this". But why? > > It is easy to determine the amount of truncation (if any) from the length of the hash value in the 'ni' URI (or 'nih' URI or binary form). Instead of: > > nih:sha-256-32;53269057 > > why not use: > > nih:sha-256;53269057 > > The second form saves a few bytes, but more importantly it avoids the need to register a new algorithm name for every truncation length that could have any use. This is particularly important for the binary format that only has a 6-bit field (64 possibilities) to indicate the algorithm. 64 hash algs sounds ok; 64 hash/length pairs sounds quite limiting. > > The truncation length in the alg name is not used to parse the URI (even in the binary format). > > The one constraint the spec would need to state is that any truncation MUST be on a byte (8-bit) boundary (so you can calculate the truncation length from the number of base64url-chars in a 'ni' URI). I'm going to argue against that change for two reasons. First, if the name is received via a stream-cipher protected channel then not having the length in the alg might enable some truncation attacks. That's a bit of a corner-case, but a real issue nonetheless. Second, I prefer that there be fewer options overall, compared to having more options, to encourage interop. (Interop for these isn't hard though, which makes this a less convincing argument for me.) IMO the restricted space for binary format algs is therefore a good thing. So, I'd rather keep as-is in this respect. Cheers, S. > -- > James Manger > From glenn.parsons@ericsson.com Sun May 6 10:58:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FED921F8534 for ; Sun, 6 May 2012 10:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUAqQ+MoyD4Y for ; Sun, 6 May 2012 10:58:54 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C74DF21F84F8 for ; Sun, 6 May 2012 10:58:54 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q46Hwpvs016064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 May 2012 12:58:54 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.132]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 6 May 2012 13:58:50 -0400 From: Glenn Parsons To: "draft-ietf-eai-rfc5721bis-04.all@tools.ietf.org" , "apps-discuss@ietf.org" Date: Sun, 6 May 2012 13:58:48 -0400 Thread-Topic: APPSDIR review of draft-ietf-eai-rfc5721bis-04 Thread-Index: Ac0rseNFQS++0IyDSA2QL0SjbKGbKA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C1EUSAACMS0714e_" MIME-Version: 1.0 Subject: [apps-discuss] APPSDIR review of draft-ietf-eai-rfc5721bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 17:58:56 -0000 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C1EUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-eai-rfc5721bis-04 Title: POP3 Support for UTF-8 Reviewer: Glenn Parsons Review Date: May 5, 2012 Summary: This draft is almost ready for publication as Proposed Standard = RFC but has a few issues that should be fixed before publication Major Issues: None that I found Minor Issues: 1.1 "silly" seems like the wrong word. How about "will appear incorrectly = as a result" but why not consider posting a companion PDF version with the correct ac= cents? Then you could reword this note here (and the one in section 2) to indic= ate the limitation is only in the txt version... 2. section 2 seems somewhat long without any subsections. Consider adding= one or more...perhaps for the examples? 3.1 After the nice example in section 2, the reader feels that they are mis= sing from the end of section 3. A full example would be onerous, but a sho= rtened one would be helpful 3.2 the 5th and 7th paragraphs are related and it would likely read better = if the 7th paragraph was made the second sentence of the 5th paragraph. 5. I am curious as to what would casue the "better mood" of the server :-) = I suspect it is implementation choice and if the CPU is running at max it = would be in a "bad mood" and decline a downconvert request? Whatever the c= ase, I suggest you explain this a bit more... 6. The section -> Section ...in both paragraphs Nits: -- The draft header indicates that this document obsoletes RFC5721, but the= abstract doesn't seem to mention this, which it should -- The document has a disclaimer for pre-RFC5378 work, but was first submi= tted on or after 10 November 2008. Does it really need the disclaimer? =3D=3D Outdated reference: A later version (-04) exists of draft-ietf-eai-= simpledowngrade-03 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C1EUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please resolve these c= omments along with any other Last Call comments you may receive. Please wai= t for direction from your document shepherd or AD before posting a new vers= ion of the draft.
Document: draft-ietf-eai-rfc5721bis-04
Title: POP3 Support for= UTF-8
Reviewer: Glenn Parsons
Review Date: May 5, 2012
Summary:   T= his draft is almost ready for publication as Proposed Standard RFC but has = a few issues that should be fixed before publication
Major Issues:  No= ne that I found
Minor Issues:
1.1 "silly" = seems like the wrong word.  How about "will appear incorrectly as= a result"
   but why not consider posting a companion PDF version with the = correct accents?
   Then you could reword this note here (and the one in section 2= ) to indicate the limitation is only in the txt version…
2.  section 2 see= ms somewhat long without any subsections.  Consider adding one or more= …perhaps for the examples?
3.1 After the nice exa= mple in section 2, the reader feels that they are missing from the end of s= ection 3.  A full example would be onerous, but a shortened one would = be helpful
3.2 the 5th and 7th pa= ragraphs are related and it would likely read better if the 7th paragraph w= as made the second sentence of the 5th paragraph.
5. I am curious as to = what would casue the "better mood" of the server :-)  I susp= ect it is implementation choice and if the CPU is running at max it would b= e in a "bad mood" and decline a downconvert request?  Whatever the case, I suggest you explain this a bit more...
6.  The section -= > Section
     …in both paragraphs
Nits:
-- The draft header in= dicates that this document obsoletes RFC5721, but the abstract doesn't seem= to mention this, which it should
-- The document has a= disclaimer for pre-RFC5378 work, but was first submitted on or after 10 No= vember 2008. Does it really need the disclaimer?
=3D=3D Outdated refer= ence: A later version (-04) exists of draft-ietf-eai-simpledowngrade-03
 
 
 
 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C1EUSAACMS0714e_-- From glenn.parsons@ericsson.com Sun May 6 10:59:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059EA21F8541 for ; Sun, 6 May 2012 10:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQo848m0084k for ; Sun, 6 May 2012 10:59:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 17D9221F84F8 for ; Sun, 6 May 2012 10:58:59 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q46HwvTJ010537; Sun, 6 May 2012 12:58:58 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.132]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 6 May 2012 13:58:51 -0400 From: Glenn Parsons To: "draft-ietf-eai-5738bis-03.all@tools.ietf.org" , "apps-discuss@ietf.org" Date: Sun, 6 May 2012 13:58:50 -0400 Thread-Topic: APPSDIR revie of draft-ietf-eai-5738bis-03 Thread-Index: Ac0rseQf/GE4sMyvS9eEskEF9rXObA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C2EUSAACMS0714e_" MIME-Version: 1.0 Subject: [apps-discuss] APPSDIR revie of draft-ietf-eai-5738bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 17:59:02 -0000 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C2EUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-eai-5738bis-03 Title: IMAP Support for UTF-8 Reviewer: Glenn Parsons Review Date: May 5, 2012 Summary: This draft is almost ready for publication as Proposed Standard RF= C but has a few issues that should be fixed before publication Major Issues: None that I noticed... Minor Issues: 3. (last para) Section 6 imply -> Section 6 implies 3.1 (first para) ...it informs the client that... -> ... it is informing th= e client that ... this rewording clarifies that the ABNF is not sent with the capabilit= y :-) 3.2 It would be cleare if the ABNF were introduced (as in 3.1) ... eg. Add= ..."with the following syntax:" to the last para. And further if the exam= ple was clearly marked "Example:" Further the C/S should not be double spa= ced. 8. This document adds two new ... -> This document defines two ... In both paragraphs as these are already in the IANA registry. 8. IMAP4 list selection -> IMAP4 LIST-EXTENDED ...since that is the IANA registry name 8.3 3.4.1 -> 3.4.2 ... though I would be tempted to change them all to just 3.4 Nits: ** There are 3 instances of too long lines in the document, the longest one= being 4 characters in excess of 72. =3D=3D The 'Obsoletes: ' line in the draft header should list only the _num= bers_ of the RFCs which will be obsoleted by this document (if approved); i= t should not include the word 'RFC' in the list. =3D=3D The document seems to lack the recommended RFC 2119 boilerplate, eve= n if it appears to use RFC 2119 keywords -- however, there's a paragraph wi= th a matching beginning. Boilerplate error? (The document does seem to have= the reference to RFC 2119 which the ID-Checklist requires). =3D=3D Missing Reference: 'RFC 5258' is mentioned on line 286, but not defi= ned =3D=3D Outdated reference: draft-ietf-eai-rfc5335bis has been published as = RFC 6532 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C2EUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have been selected a= s the Applications Area Directorate reviewer for this draft (for background= on appsdir, please see http://trac.t= ools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
Please resolve these c= omments along with any other Last Call comments you may receive. Please wai= t for direction from your document shepherd or AD before posting a new vers= ion of the draft.
Document: draft-ietf-eai-5738bis-03
Title: IMAP Support for UTF-8
Reviewer:  Glenn Parsons
Review Date:  May 5, 2012
Summary: This draft is= almost ready for publication as Proposed Standard RFC but has a few issues= that should be fixed before publication
Major Issues:  No= ne that I noticed...
Minor Issues:
3.  (last para)&n= bsp; Section 6 imply -> Section 6 implies
3.1 (first para) ̷= 0;it informs the client that… -> … it is informing the clien= t that …
      this rewording clarifies that the ABNF is no= t sent with the capability :-)
3.2  It would be = cleare if the ABNF were introduced (as in 3.1) … eg. Add …"= ;with the following syntax:" to the last para.  And further if th= e example was clearly marked "Example:"  Further the C/S sho= uld not be double spaced.
8. This document adds = two new … -> This document defines two …
    In both paragraphs as these are already in the IANA regi= stry.
8.  IMAP4 list se= lection -> IMAP4 LIST-EXTENDED
    …since that is the IANA registry name
8.3  3.4.1 -> = 3.4.2
      … though I would be tempted to change = them all to just 3.4
Nits:
** There are 3 instanc= es of too long lines in the document, the longest one being 4 characters in= excess of 72.
=3D=3D The 'Obsoletes:= ' line in the draft header should list only the _numbers_ of the RFCs whic= h will be obsoleted by this document (if approved); it should not include t= he word 'RFC' in the list.
=3D=3D The document se= ems to lack the recommended RFC 2119 boilerplate, even if it appears to use= RFC 2119 keywords -- however, there's a paragraph with a matching beginnin= g. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires).
=3D=3D Missing Referen= ce: 'RFC 5258' is mentioned on line 286, but not defined
=3D=3D Outdated refere= nce: draft-ietf-eai-rfc5335bis has been published as RFC 6532
 
 
 
 
 
 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FF4C2EUSAACMS0714e_-- From cabo@tzi.org Sun May 6 13:57:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B735A21F84F0; Sun, 6 May 2012 13:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.287 X-Spam-Level: X-Spam-Status: No, score=-106.287 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaWMSzbt2TOr; Sun, 6 May 2012 13:57:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 890AA21F84AA; Sun, 6 May 2012 13:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q46KvdU6003700; Sun, 6 May 2012 22:57:39 +0200 (CEST) Received: from [192.168.217.105] (p548996D9.dip.t-dialin.net [84.137.150.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F1E4B111; Sun, 6 May 2012 22:57:38 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Carsten Bormann Date: Sun, 6 May 2012 22:57:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92309DC0-A179-4B5B-9D8C-4B55F64A4668@tzi.org> To: draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org, "apps-discuss@ietf.org application-layer protocols" X-Mailer: Apple Mail (2.1257) Cc: mboned@ietf.org, 6man@ietf.org, The IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-mboned-64-multicast-address-format-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 20:57:52 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Gr=FC=DFe, Carsten --------------------------------- Document: draft-ietf-mboned-64-multicast-address-format-01 Title: IPv4-Embedded IPv6 Multicast Address Format Reviewer: Carsten Bormann Review Date: 2012-05-06 IETF Last Call Date: 2012-04-19 ** Summary: This draft is NOT ready for publication as a Proposed Standard and should be revised before publication. The document appears as an attempt to extend the reasoning of RFC 6052 to multicast IPv4 addresses. However, while unicast IPv4 addresses and their IPv6 counterparts are assigned as part of network configuration, multicast addresses are decided upon by applications. The document is very short on information how an application should decide when to make use of the newly defined formats. It is therefore also hard to understand why these formats are needed in the first place. There appears to be a transition model in the minds of the authors that makes this necessary or practical, and this information must be made part of the document for it to be useful. ** Major Issues: To continue the summary: I don't understand which network elements need to be able to determine, by looking at an IP address, that this document is in use. What for? More generally, which entities need to interoperate based on a common understanding of this format? Of the various fields left "configurable according to local policies of the entity managing the IPv4-IPv6 Interconnection Function", which are important for applications? How do they know these policies? If that information is all in the two parameters "ASM_MPREFIX64" and "SSM_MPREFIX64", what is the protocol that will be used to make this information available to applications? I don't think this can be a standards-track document without defining at least one MTI protocol for disseminating this information. What is an implementation supposed to do that receives an address that looks like it is governed by this document but does not conform to either of the agreed prefixes disseminated to the implementation? This document needs editorial attention. I will abstain from trying to make detailed corrections, as this would become tedious quickly. While much of this work could be done by the RFC editor, some of the editorial decisions will enter e.g. IANA registries, so the technical terms need to be decided now. More importantly, understanding this document during its development process (including mine as a reviewer) may be hampered by its editorial shortcomings. ** Minor Issues: My first editorial problem is with the title. This address format is not embedded in IPv4, as the title wants to make us believe. Instead, it is talking about an multicast address format for IPv6 that embeds an IPv4 multicast address. (While this misleading naming repeats the same mistake that has been made in RFC 6052, at least there it is not part of the title.) 3 The role of 64IX is very unclear. My conjecture is that this draft is defining the address format for the case M=3D1 only (i.e., address[16] =3D= 1). No text defines what happens for M=3D0, so the assumption appears to be that RFC 4291 applies unchanged in this case. If this conjecture is correct, this needs to be made much clearer. What is "r"? Define. 4 Why is 64IX moving around here? (The discriminating bit M now seems to be address[32].) How does one find out which of the two positions of the M bit to use? . o sub-group-id: The default value is all zeros. How does an application find out when to choose a different one? . 232.0.0.1-232.0.0.255 range is being . reserved to IANA. Who is making this reservation? ("is being reserved" means the resernation is going on right now, but I don't find anything in 9.) 7 7 seems to imply this format is only useful where RFC 6052 is in use. If this is true, this should be clearly stated. More specifically, the assumption appears to be that all nodes that need to exchange information that concerns IPv4 sources need to have the same RFC 6052 parameters in effect. How is that ensured? ** Nits: 10 -- s/defined/defines/ (And many more, see above.) From anthonybryan@gmail.com Sun May 6 14:18:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1637F21F8535 for ; Sun, 6 May 2012 14:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajYZZzc9MT+y for ; Sun, 6 May 2012 14:18:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3610D21F852E for ; Sun, 6 May 2012 14:18:15 -0700 (PDT) Received: by yhq56 with SMTP id 56so4529542yhq.31 for ; Sun, 06 May 2012 14:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1apJRQ7iUp1eNLvBIHb0JJzP4uJgpVjJRJWvvQ0+x5U=; b=PyfD+tBLEF6XSGDopuqOft+FjI78jA8SNxU9hXPS70aGwTdv5lpvdXn73B3aBCfKdy B0FAkg+LPurlE7Pn9O1k15DoqcVtl8HiyDMpiSLOU5jjsHtHmVrB5EjQBUGM0IFcnoV1 S9KOIC2lh0K2+tTK4ey44KKqgQhUdODISRO3b2/WSYhxTopLWjrDW+HkEHQJypq8Meq2 RI8WGr1fSEDQG0TqUk/uVzZO3a/skl01ORh8xSUhEb6i+BWImJ/gheNME4Jk3NF76R16 oostDLL4tttA9ohXdAT2KWovd8Q4xcyAWPRJ5Nm5euzFmGAd30by+1wrdovEh/JMUsu7 24ng== MIME-Version: 1.0 Received: by 10.236.143.71 with SMTP id k47mr10107993yhj.58.1336339094842; Sun, 06 May 2012 14:18:14 -0700 (PDT) Received: by 10.147.114.14 with HTTP; Sun, 6 May 2012 14:18:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 6 May 2012 17:18:14 -0400 Message-ID: From: Anthony Bryan To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 21:18:16 -0000 On Sun, May 6, 2012 at 7:45 AM, Manger, James H wrote: > Section 2 "Basics" of draft-farrell-decade-ni-05 says "when a hash value = is truncated the name MUST indicate this". But why? > > It is easy to determine the amount of truncation (if any) from the length= of the hash value in the 'ni' URI (or 'nih' URI or binary form). Instead o= f: > > =A0nih:sha-256-32;53269057 > > why not use: > > =A0nih:sha-256;53269057 > > The second form saves a few bytes, but more importantly it avoids the nee= d to register a new algorithm name for every truncation length that could h= ave any use. that would mean you could also make use of the existing "Hash Function Textual Names" registry http://www.iana.org/assignments/hash-function-text-names/hash-function-text= -names.xml --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From mnot@mnot.net Sun May 6 16:47:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE4F21F854E; Sun, 6 May 2012 16:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p5sZyAYftNY; Sun, 6 May 2012 16:47:58 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3A421F84DF; Sun, 6 May 2012 16:47:58 -0700 (PDT) Received: from [192.168.0.100] (unknown [110.151.123.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E0EBC50A64; Sun, 6 May 2012 19:47:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Mark Nottingham In-Reply-To: <3BF363C82C184B46930A905352C2013F02103860@FIESEXC006.nsn-intra.net> Date: Mon, 7 May 2012 09:47:49 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E1AF099-0252-4032-8769-E8F794BFFAD2@mnot.net> <3BF363C82C184B46930A905352C2013F02103860@FIESEXC006.nsn-intra.net> To: "Peylo, Martin (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1257) Cc: toka@tectia.com, draft-ietf-pkix-cmp-transport-protocols.all@tools.ietf.org, ext Sean Turner , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 23:47:59 -0000 Hi Martin, Responses below. On 07/05/2012, at 3:59 AM, Peylo, Martin (NSN - FI/Espoo) wrote: [=85] > I added the following to the introduction:=20 >=20 > The usage of HTTP for transporting CMP messages exclusively uses POST > method > for requests, effectively tunneling CMP over HTTP. While this is > generally > considered as bad practice and should not be emulated, there are good > reasons to > do so for transporting CMP. HTTP is used as it is generally easy to > implement, > traverses network borders utilizing ubiquitous proxies and is already > commonly > found in existing CMP implementations. Other request methods such as > GET are=20 > not used as all PKI management operations are triggered using the > CMP's PKI=20 > messages which need to be transported within a POST request. Looks good, thanks. >> * Section 3.2 "Persistent Connections" effectively re-specifies part > of >> HTTP; this section should be removed. >=20 > I couldn't find HTTP explicitly forbidding (or permitting) to use the > information=20 > if sequential requests came over the same connection or not on the > higher layer=20 > - but of course I might have missed that somewhere. As I personally > already have=20 > experienced this as a fatal source of incompatibility between CMP = client > and server=20 > implementations I would like to keep this paragraph. Trying to avoid > sounding like > re-specifying parts of HTTP I changed this section to the following: >=20 > HTTP permits to reuse a connection for subsequent requests. > Implementations > may use this functionality but MUST NOT rely on this for messages > within the > same CMP transaction as e.g. intermediate HTTP proxies might = terminate > the > connection after each request/response pair. >=20 > Do you think it would be OK to keep it like this? We're clarifying this in HTTPbis, but of course that doesn't help you = *right* now. I'd change to something like: HTTP persistent connections [ref to 2616] allow multiple interactions to = take place on the same HTTP connection. However, neither HTTP nor this = protocol are designed to correlate messages on the same connection in = any meaningful way; persistent connections are only a performance = optimisation. In particular, intermediaries can do things like mix = connections from different clients into one "upstream" connections, = terminate persistent connections and forward requests as non-persistent = requests, etc. As such, implementations MUST NOT infer that requests on = the same connection come from the same client (e.g., for purposes of = authentication); every message is to be evaluated in isolation.=20 >> * Section 9 "Security Considerations" #2 -- "There is no security at > the >> HTTP protocol level" is a gross misstatement. >=20 > Changed to: >=20 > 2. Without being encapsulated in effective security protocols such > as > TLS [RFC5246] there is no integrity protection at the HTTP > protocol level. Therefore information from the HTTP protocol > should not be used to change state of the transaction. Works for me. >> * Section 9 "Security Considerations" #2 -- "The client SHOULD NOT >> support the "301 Moved Permanently status code" is ambiguous. Do you >> mean that it should never be followed, or that it should not be = stored >> as a permanent redirect? A statement merely warning of the effects of > a >> MITM would be more useful here. >=20 > Changed to: >=20 > 3. Client users should be aware that storing the target location of > a HTTP response with the "301 Moved Permanently" status code > could be exploited by a man-in-the-middle attacker to block them > permanently from contacting the correct server. OK. Thanks, -- Mark Nottingham http://www.mnot.net/ From martin.peylo@nsn.com Sun May 6 11:00:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA121F8534; Sun, 6 May 2012 11:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0Lvjsl1by23; Sun, 6 May 2012 11:00:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8650621F84F8; Sun, 6 May 2012 11:00:06 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q46I02EZ004387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 May 2012 20:00:02 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q46I02rQ023269; Sun, 6 May 2012 20:00:02 +0200 Received: from FIESEXC006.nsn-intra.net ([10.159.0.14]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 6 May 2012 20:00:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 6 May 2012 20:59:58 +0300 Message-ID: <3BF363C82C184B46930A905352C2013F02103860@FIESEXC006.nsn-intra.net> In-Reply-To: <8E1AF099-0252-4032-8769-E8F794BFFAD2@mnot.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: APPSDIR review of draft-ietf-pkix-cmp-transport-protocols Thread-Index: Acz6f8TPiRqe89Q0Q/Gje0n/zmSrtwxGHajg References: <8E1AF099-0252-4032-8769-E8F794BFFAD2@mnot.net> From: "Peylo, Martin (NSN - FI/Espoo)" To: "ext Mark Nottingham" , , X-OriginalArrivalTime: 06 May 2012 18:00:02.0459 (UTC) FILETIME=[0F4E86B0:01CD2BB2] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6725 X-purgate-ID: 151667::1336327203-00005945-3E668CB2/0-0/0-0 X-Mailman-Approved-At: Sun, 06 May 2012 16:50:54 -0700 Cc: toka@tectia.com, ext Sean Turner , iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 18:00:08 -0000 Hi Mark, =20 please excuse the long delay and thank you very much for your helpful review comments. Inline below are explanations/notes about the changes which will appear in=20 draft-ietf-pkix-cmp-transport-protocols-17 which should become available here soon: http://tools.ietf.org/html/draft-ietf-pkix-cmp-transport-protocols-17 I hope all your very valid concerns were appropriately addressed! Kind regards, Martin > -----Original Message----- > From: ext Mark Nottingham [mailto:mnot@mnot.net] > Sent: Monday, March 05, 2012 5:26 AM > To: apps-discuss@ietf.org Discuss; draft-ietf-pkix-cmp-transport- > protocols.all@tools.ietf.org > Cc: iesg@ietf.org IESG > Subject: APPSDIR review of draft-ietf-pkix-cmp-transport-protocols >=20 > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > te>). >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-pkix-cmp-transport-protocols-16 > Title: Internet X.509 Public Key Infrastructure -- HTTP Transport for > CMP > Reviewer: Mark Nottingham > Review Date: March 4, 2012 >=20 > Summary: This draft is not ready for publication as a Proposed Standard > and should be revised before publication. >=20 >=20 > Major Issues: >=20 > * This draft describes a HTTP-based protocol that exclusively uses POST; > i.e., it effectively tunnels. >=20 > This is widely recognised as bad practice, and should be avoided where > possible. A good use of HTTP is one that defines resources with > particular behaviours, formats with associated semantics, and then uses > links to navigate / manipulate the state of the application. GET should > be used for retrieval (it's not even clear if it's allowed / used in > this draft). >=20 > Preferably, the draft should be re-worked to use HTTP well, rather than > tunnelling. >=20 > Alternatively, there should be a notice inserted that explains this > draft is tunnelling over HTTP, and this practice should not be emulated. I added the following to the introduction:=20 The usage of HTTP for transporting CMP messages exclusively uses POST method for requests, effectively tunneling CMP over HTTP. While this is generally considered as bad practice and should not be emulated, there are good reasons to do so for transporting CMP. HTTP is used as it is generally easy to implement, traverses network borders utilizing ubiquitous proxies and is already commonly found in existing CMP implementations. Other request methods such as GET are=20 not used as all PKI management operations are triggered using the CMP's PKI=20 messages which need to be transported within a POST request. =20 > Minor Issues: >=20 > * Section 3.1 "HTTP Versions" - the wording here doesn't reflect how > HTTP versioning works; see RFC2145. Suggest: "Clients MUST support > HTTP/1.0 [RFC1945], and SHOULD support HTTP/1.1 [RFC2616]." Suggestion used (but changed "Clients" to "Implementations"). > * Section 3.2 "Persistent Connections" effectively re-specifies part of > HTTP; this section should be removed. I couldn't find HTTP explicitly forbidding (or permitting) to use the information=20 if sequential requests came over the same connection or not on the higher layer=20 - but of course I might have missed that somewhere. As I personally already have=20 experienced this as a fatal source of incompatibility between CMP client and server=20 implementations I would like to keep this paragraph. Trying to avoid sounding like re-specifying parts of HTTP I changed this section to the following: HTTP permits to reuse a connection for subsequent requests. Implementations may use this functionality but MUST NOT rely on this for messages within the same CMP transaction as e.g. intermediate HTTP proxies might terminate the connection after each request/response pair. Do you think it would be OK to keep it like this? > * Section 3.6 "HTTP Request-URI" -- What does "depicting a directly" > mean? HTTP and URIs say nothing about directories. Very valid point, I changed section 3.6 to the following changing=20 "directory" to "path" and removing what I found to be redundant as already specified: 3.6. HTTP Request-URI The Request-URI is formed as specified in [RFC3986]. A server implementation MUST handle Request-URI paths with or without a trailing slash as identical. An example of a Request-Line and a Host header field in an HTTP/1.1 header, sending a CMP request to a server, located in the "/cmp" path of the host "example.com", would be POST /cmp HTTP/1.1 Host: example.com or in the absoluteURI form POST http://example.com/cmp/ HTTP/1.1 Host: example.com > * Section 3.8 "HTTP Considerations" -- Pragma: no-cache is not > meaningful in responses, and shouldn't be limited to just HTTP/1.0, as > versioning is hop-by-hop, not end-to-end. In any case, this paragraph > can be dropped, because POST isn't cacheable by default, and is never > cached in practice. Paragraph dropped. =20 > * Section 3.8 "HTTP Considerations" -- The paragraphs on connection > management and content-codings are re-specifying HTTP, and should be > removed. Paragraphs removed. > * Section 9 "Security Considerations" #2 -- "There is no security at the > HTTP protocol level" is a gross misstatement. Changed to: 2. Without being encapsulated in effective security protocols such as TLS [RFC5246] there is no integrity protection at the HTTP protocol level. Therefore information from the HTTP protocol should not be used to change state of the transaction. > * Section 9 "Security Considerations" #2 -- "The client SHOULD NOT > support the "301 Moved Permanently status code" is ambiguous. Do you > mean that it should never be followed, or that it should not be stored > as a permanent redirect? A statement merely warning of the effects of a > MITM would be more useful here. Changed to: 3. Client users should be aware that storing the target location of a HTTP response with the "301 Moved Permanently" status code could be exploited by a man-in-the-middle attacker to block them permanently from contacting the correct server. > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 From stephen.farrell@cs.tcd.ie Sun May 6 17:16:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D1C21F84C8 for ; Sun, 6 May 2012 17:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZNzlhgFWMeA for ; Sun, 6 May 2012 17:16:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E66621F8475 for ; Sun, 6 May 2012 17:16:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 79DE91714FA; Mon, 7 May 2012 01:16:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1336349794; bh=uie+AtKqvphSqb JYJHVruuDYuk8/YlEb84RJ8uh+6+I=; b=VPaQQjQLo+wRn9mw0yuZrcGk7kv+/3 RkezUYX80oMny4GpH6Jv3gipcMz+j5dUZTX6HTgi5+2jTZb/dZAAb5Atome3zTun dIrb6L9YGuTfbckxya1QPH2dxjxPTc+okzt2sz6iy1ZZXi0GGtWKR8pLgewObTx/ FhGn7I2pk+bAH4ujSJbGpYym5pQ6u1xMiyRdM7MFsFiomWNm/HYqLJTVtiX+Du8f Kqp7itQr0tEu/9X+jKg29ppKxToeGnkMEHIFnHLFqzwFsXHzzU+vVkAsrr04273S CBdKNVvaet3ytgZ9Ga6V+6BGnrWwUxxl4WFECuxXDrHa3buUptLd5gfw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id TQ5iOCwalVMi; Mon, 7 May 2012 01:16:34 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.56.1]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DD4F51714DA; Mon, 7 May 2012 01:16:28 +0100 (IST) Message-ID: <4FA7145C.5020707@cs.tcd.ie> Date: Mon, 07 May 2012 01:16:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Anthony Bryan References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 00:16:36 -0000 Hi, On 05/06/2012 10:18 PM, Anthony Bryan wrote: > On Sun, May 6, 2012 at 7:45 AM, Manger, James H > wrote: >> Section 2 "Basics" of draft-farrell-decade-ni-05 says "when a hash value is truncated the name MUST indicate this". But why? >> >> It is easy to determine the amount of truncation (if any) from the length of the hash value in the 'ni' URI (or 'nih' URI or binary form). Instead of: >> >> nih:sha-256-32;53269057 >> >> why not use: >> >> nih:sha-256;53269057 >> >> The second form saves a few bytes, but more importantly it avoids the need to register a new algorithm name for every truncation length that could have any use. > > that would mean you could also make use of the existing "Hash Function > Textual Names" registry > > http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml That's true and would be an advantage. But IMO outweighed by the security and interop downsides I mentioned before. S > From James.H.Manger@team.telstra.com Sun May 6 17:27:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5663721F845C for ; Sun, 6 May 2012 17:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9qZkBMdvbyD for ; Sun, 6 May 2012 17:27:15 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8978121F8448 for ; Sun, 6 May 2012 17:27:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,540,1330866000"; d="scan'208";a="72703420" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 07 May 2012 10:27:14 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6703"; a="61500312" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbvi.tcif.telstra.com.au with ESMTP; 07 May 2012 10:27:14 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Mon, 7 May 2012 10:27:13 +1000 From: "Manger, James H" To: Stephen Farrell , Apps Discuss Date: Mon, 7 May 2012 10:27:12 +1000 Thread-Topic: Indicating hash size in 'ni' URIs Thread-Index: Ac0rlGtEkwljK418THeBcehBKxD5cAASZWXw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F28540B5@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> <4FA68A60.6030207@cs.tcd.ie> In-Reply-To: <4FA68A60.6030207@cs.tcd.ie> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 00:27:16 -0000 >> ... >> Instead of: >>=20 >> nih:sha-256-32;53269057 >>=20 >> why not use: >>=20 >> nih:sha-256;53269057 >> ... > I'm going to argue against that change for two > reasons. > > First, if the name is received via a stream-cipher > protected channel then not having the length in the > alg might enable some truncation attacks. That's a > bit of a corner-case, but a real issue nonetheless. Yikes! Fix the "protected channel" so it actually gives you integrity, or d= on't rely on it for integrity. Such an attack would also only work if the receiver accepted a short hash (= that the attacker found a collision for) when the receiver should have conf= irmed the hash was crypto-strength. The receiver needs to be fixed (eg to r= equire lengths over 120-bits). Putting lengths in alg names seems to be pap= ering over much bigger underlying problems in this corner-case. > Second, I prefer that there be fewer options overall, > compared to having more options, to encourage interop. > (Interop for these isn't hard though, which makes > this a less convincing argument for me.) IMO the > restricted space for binary format algs is therefore > a good thing. I have no problem with the draft recommending a few specific lengths (eg 32= , 64, 96, 120, 128, 256 bits) if that encourages interop. My guess is you w= ill get better interop without truncation lengths in names. It would encour= age systems to be configured with min and/or max truncation lengths and int= eroperate with any length in that range (eg a SHA-256 has truncated to 160 = bits). The current text means a SHA-256 hash truncated to 160 bits would be= rejected simply because "SHA-256-160" is not explicitly listed. > So, I'd rather keep as-is in this respect. I would still rather ditch the truncation length from the alg names. -- James Manger=20 From likepeng@huawei.com Sun May 6 17:38:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C220921F854D for ; Sun, 6 May 2012 17:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9BItO7r7ztV for ; Sun, 6 May 2012 17:38:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1806421F8549 for ; Sun, 6 May 2012 17:38:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFO56508; Sun, 06 May 2012 20:38:44 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 6 May 2012 17:38:40 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 6 May 2012 17:38:40 -0700 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.182]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 7 May 2012 08:38:35 +0800 From: Likepeng To: Peter Saint-Andre , "Murray S. Kucherawy" Thread-Topic: [apps-discuss] draft-jones-appsawg-webfinger-04 Thread-Index: Ac0qG8eE3EKALRWtQ/iIIohy4m6Gpf//oOqA//wFO/A= Date: Mon, 7 May 2012 00:38:35 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2035806BC@szxeml525-mbs.china.huawei.com> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <4FA4333F.3090101@stpeter.im> In-Reply-To: <4FA4333F.3090101@stpeter.im> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.109.51] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 00:38:46 -0000 PiBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50Lg0KDQorMS4NCg0KS2luZCBS ZWdhcmRzDQpLZXBlbmcNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBhcHBzLWRpc2N1c3Mt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIFBldGVyIFNhaW50LUFuZHJlDQq3osvNyrG85DogMjAxMsTqNdTCNcjVIDM6NTENCsrVvP7I yzogTXVycmF5IFMuIEt1Y2hlcmF3eQ0Ks63LzTogYXBwcy1kaXNjdXNzQGlldGYub3JnDQrW98zi OiBSZTogW2FwcHMtZGlzY3Vzc10gZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXItMDQNCg0K LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiA1LzQv MTIgMTE6MzEgQU0sIE11cnJheSBTLiBLdWNoZXJhd3kgd3JvdGU6DQo+IFRoZSBhYm92ZS1uYW1l ZCBkcmFmdCBoYXMgYmVlbiBvZmZlcmVkIGFzIHRoZSByZWNvbW1lbmRlZCBwYXRoDQo+IGZvcndh cmQgaW4gdGVybXMgb2YgY29udmVyZ2luZyBvbiBhIHNpbmdsZSBkb2N1bWVudCB0byBhZHZhbmNl DQo+IHRocm91Z2ggYXBwc2F3Zy4gVGhlIGNvbnZlcnNhdGlvbiBJIHNhdyB0aGlzIHdlZWsgaW4g dGhhdCByZWdhcmQNCj4gaGFzIHNlZW1lZCBtb3N0bHkgcG9zaXRpdmUuDQo+IA0KPiBQbGVhc2Ug cmV2aWV3IGl0LCBvciBhdCBsZWFzdCB0aGUgZGlmZiwgYW5kIGluZGljYXRlIHlvdXIgc3VwcG9y dA0KPiBvciBvYmplY3Rpb24gb24gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+IDxtYWlsdG86YXBw cy1kaXNjdXNzQGlldGYub3JnPiB0byBhZG9wdGluZyB0aGlzIG9uZSBhcyB0aGUgY29tbW9uDQo+ IHBhdGggZm9yd2FyZC4gV2Ugd291bGQgbGlrZSB0byBtYWtlIGEgZGVjaXNpb24gYWJvdXQgd2hp Y2ggb25lIHRvDQo+IGJlZ2luIGFkdmFuY2luZyBpbiB0aGUgbmV4dCB3ZWVrIG9yIHR3by4NCg0K SSB0aGluayB0aGlzIGlzIGEgZ29vZCBzdGFydGluZyBwb2ludC4NCg0KUGV0ZXINCg0KLSAtLSAN ClBldGVyIFNhaW50LUFuZHJlDQpodHRwczovL3N0cGV0ZXIuaW0vDQoNCg== From stpeter@stpeter.im Sun May 6 18:07:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8821F853D; Sun, 6 May 2012 18:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaGpl+WuXKvD; Sun, 6 May 2012 18:07:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7D00721F852B; Sun, 6 May 2012 18:07:32 -0700 (PDT) Received: from [192.168.0.3] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 96E674005B; Sun, 6 May 2012 19:22:44 -0600 (MDT) Message-ID: <4FA72053.6000704@stpeter.im> Date: Sun, 06 May 2012 19:07:31 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> In-Reply-To: <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org Discuss" , The IESG , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 01:07:33 -0000 On 5/5/12 8:21 AM, Paul Hoffman wrote: > On May 4, 2012, at 3:38 PM, Andrew Sullivan wrote: > >> On Sat, May 05, 2012 at 12:24:50AM +0200, Martin Rex wrote: >>> >>> We added similar text like the above to rfc6066 (TLS extensions) >>> for the description of the extension "Server name indication" here: >> >> The problem in this case, however, is that what the TLSA document is >> doing is building a QNAME for use in the DNS. None of the description >> from RFC 6066 is a domain name. >> >> Remember, the dot-separated labels are the presentation form, but >> _not_ what you send on the wire. Dots aren't part of the DNS on the >> wire. >> >> What we want to do for this case is get the QNAME for the DNS. So we >> take the two labels that come out of steps 1 and 2 in the draft, and >> put them on the front of the DNS name that we're trying to look up, >> creating an absolute, fully qualified name that gets sent in the QNAME >> of the DNS operation. >> >> At least I think that's what the section is trying to do. > > It is indeed what the section is trying to do. > >> I'm also uncomfortable with the "ASCII" stuff, because DNS labels >> aren't in ASCII. They're octets. However, ASCII is treated specially >> in the DNS. (This is one of the sharp edges about the DNS that we'd >> all like to go back and fix if we could.) > > Note that the document explicitly states in the last paragraph of section 1.2 that "This document only relates to securely associating certificates for TLS and DTLS with host names". We are not talking just "domain names" (which are made up of labels of octets) but "host names" which are made up of labels of ASCII. We were told (wisely) not to try to reopen this can of worms, so we didn't. > > As you pointed out, Peter's proposed wording had an issue by mentioning the "dots". That can easily be fixed. I now propose: > > OLD > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. > > NEW > > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string where each label is encoded > using ASCII; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) Works for me. Peter From yaojk@cnnic.cn Sun May 6 19:14:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B84721F858F for ; Sun, 6 May 2012 19:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.38 X-Spam-Level: X-Spam-Status: No, score=-99.38 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_20=-0.74, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDZGDSeCAxFz for ; Sun, 6 May 2012 19:14:53 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 1F3DB21F8581 for ; Sun, 6 May 2012 19:14:51 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 07 May 2012 10:14:49 +0800 Message-ID: <01EDC4A34A33404AABBD98D6658718B0@LENOVO47E041CF> From: "Jiankang YAO" To: "Glenn Parsons" , , References: Date: Mon, 7 May 2012 10:14:32 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DB_01CD2C3A.32153B70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-eai-rfc5721bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 02:14:54 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03DB_01CD2C3A.32153B70 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQoNCkkgdGhpbmsgdGhhdCBBRCBoYXMgY2xhcmlmaWVkIHRoYXQgSUVTRyBkaWQgbm90IGFzayB0 byBtZW50aW9uIHRoZSBvYnNvbGV0ZWQgcmZjIGluIHRoZSBhYnN0cmFjdC4NCg0KSmlhbmthbmcg WWFvDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEdsZW5uIFBhcnNv bnMgDQogIFRvOiBkcmFmdC1pZXRmLWVhaS1yZmM1NzIxYmlzLTA0LmFsbEB0b29scy5pZXRmLm9y ZyA7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZyANCiAgU2VudDogTW9uZGF5LCBNYXkgMDcsIDIwMTIg MTo1OCBBTQ0KICBTdWJqZWN0OiBbYXBwcy1kaXNjdXNzXSBBUFBTRElSIHJldmlldyBvZiBkcmFm dC1pZXRmLWVhaS1yZmM1NzIxYmlzLTA0DQoNCiAgTml0czogDQogIC0tIFRoZSBkcmFmdCBoZWFk ZXIgaW5kaWNhdGVzIHRoYXQgdGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDNTcyMSwgYnV0IHRo ZSBhYnN0cmFjdCBkb2Vzbid0IHNlZW0gdG8gbWVudGlvbiB0aGlzLCB3aGljaCBpdCBzaG91bGQN Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICBhcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0 DQogIGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K ------=_NextPart_000_03DB_01CD2C3A.32153B70 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTIyMiI+PCEtLSBjb252ZXJ0ZWQgZnJvbSBydGYg LS0+DQo8U1RZTEU+LkVtYWlsUXVvdGUgew0KCUJPUkRFUi1MRUZUOiAjODAwMDAwIDJweCBzb2xp ZDsgUEFERElORy1MRUZUOiA0cHQ7IE1BUkdJTi1MRUZUOiAxcHQNCn0NCjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNjY2U4Y2Y+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0 MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0m IzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZh Y2U9JiMyMzQzNTsmIzIwMzA3Oz5JIHRoaW5rIHRoYXQgQUQgaGFzIGNsYXJpZmllZCB0aGF0IElF U0cgZGlkIG5vdCBhc2sgdG8gDQptZW50aW9uIHRoZSBvYnNvbGV0ZWQgcmZjIGluIHRoZSBhYnN0 cmFjdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMw Nzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYj MjAzMDc7PkppYW5rYW5nIFlhbzwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJP UkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkct UklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7 IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQog IDxBIHRpdGxlPWdsZW5uLnBhcnNvbnNAZXJpY3Nzb24uY29tIA0KICBocmVmPSJtYWlsdG86Z2xl bm4ucGFyc29uc0Blcmljc3Nvbi5jb20iPkdsZW5uIFBhcnNvbnM8L0E+IDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSANCiAgdGl0 bGU9ZHJhZnQtaWV0Zi1lYWktcmZjNTcyMWJpcy0wNC5hbGxAdG9vbHMuaWV0Zi5vcmcgDQogIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLWVhaS1yZmM1NzIxYmlzLTA0LmFsbEB0b29scy5pZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1lYWktcmZjNTcyMWJpcy0wNC5hbGxAdG9vbHMuaWV0Zi5vcmc8L0E+IA0K ICA7IDxBIHRpdGxlPWFwcHMtZGlzY3Vzc0BpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmFwcHMt ZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBNb25kYXks IE1heSAwNywgMjAxMiAxOjU4IEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIz NDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gW2FwcHMtZGlzY3Vzc10gQVBQU0RJUiByZXZp ZXcgb2YgDQogIGRyYWZ0LWlldGYtZWFpLXJmYzU3MjFiaXMtMDQ8L0RJVj4NCiAgPERJVj48Rk9O VCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBzZXJpZiI+Jm5ic3A7PC9ESVY+DQogIDxE SVYgc3R5bGU9Ik1BUkdJTi1UT1A6IDVwdDsgTUFSR0lOLUJPVFRPTTogNXB0Ij5OaXRzOiA8L0RJ Vj4NCiAgPERJViBzdHlsZT0iTUFSR0lOLVRPUDogNXB0OyBNQVJHSU4tQk9UVE9NOiA1cHQiPi0t IFRoZSBkcmFmdCBoZWFkZXIgaW5kaWNhdGVzIA0KICB0aGF0IHRoaXMgZG9jdW1lbnQgb2Jzb2xl dGVzIFJGQzU3MjEsIGJ1dCB0aGUgYWJzdHJhY3QgZG9lc24ndCBzZWVtIHRvIG1lbnRpb24gDQog IHRoaXMsIHdoaWNoIGl0IHNob3VsZDwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPSYj MjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBm YWNlPSJBcmlhbCwgc2Fucy1zZXJpZiI+PC9GT05UPiZuYnNwOzwvRElWPjwvRk9OVD4NCiAgPFA+ DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+YXBwcy1kaXNjdXNzIG1haWxpbmcgDQogIGxpc3Q8QlI+YXBwcy1kaXNj dXNzQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBw cy1kaXNjdXNzPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_03DB_01CD2C3A.32153B70-- From ve7jtb@ve7jtb.com Sun May 6 20:32:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3547D21F854A for ; Sun, 6 May 2012 20:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1po+yHmzcSX for ; Sun, 6 May 2012 20:32:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81D0321F849C for ; Sun, 6 May 2012 20:32:39 -0700 (PDT) Received: by yenq13 with SMTP id q13so77376yen.31 for ; Sun, 06 May 2012 20:32:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=CwDOqmQ9geZubutNFwl89CFYZbt33a8RrLew4qd04UM=; b=FHn9+ToJ4grw3dZH25HURfajv/JKLIuvyDCUCrSODpqpehqFNUOwOOpWNxUbwI/x6w 0c5de+XmpD/+tvhz8wN1aJFZI30VmzWvW7qLMcQXBCV+Z5ILmFvSzhPAv6VLbs56oTPt fxncPw4DXJYHAYmXo+xoI50teuy2H7j3MaM7p3E47m0idWjxgW3Xpevjwz9MpVSi1DIa WEO7RBDtWSa9+fTkWUL4g3T3nPeqyT5IJFlgUT7hUzfDloqVSBcvSMCXU/HWA8/qsDT/ ST/rMkjwPdwBtMMEsEQAnKQMp1nJV4+J/dbzNjU7Dw8EianuPfNy4O37y+rY5p2zf2FS 5IDw== Received: by 10.236.75.227 with SMTP id z63mr17277392yhd.87.1336361559127; Sun, 06 May 2012 20:32:39 -0700 (PDT) Received: from [192.168.1.213] (190-20-11-19.baf.movistar.cl. [190.20.11.19]) by mx.google.com with ESMTPS id p3sm25598522and.4.2012.05.06.20.32.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 May 2012 20:32:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D498A97D-090B-43E8-8C45-D951553F5AFD"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> Date: Sun, 6 May 2012 23:32:26 -0400 Message-Id: <99457128-2C62-40DF-897E-8115CC84B5D9@ve7jtb.com> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlcTfghHCuOdkgdvqiCyvcwK2oFkgzSQIbHw8yJJXBvXMAMyqIznlVTBTcfhTISTOOo7DhU Cc: "oauth@ietf.org WG" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 03:32:40 -0000 --Apple-Mail=_D498A97D-090B-43E8-8C45-D951553F5AFD Content-Type: multipart/alternative; boundary="Apple-Mail=_5A8D0118-211B-40B4-A539-BD72D26C9514" --Apple-Mail=_5A8D0118-211B-40B4-A539-BD72D26C9514 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii While it has some rough edges that we will need to work on, I think this = document can form the basis of a single path forward. John B. On 2012-05-04, at 1:31 PM, Murray S. Kucherawy wrote: > The above-named draft has been offered as the recommended path forward = in terms of converging on a single document to advance through appsawg. = The conversation I saw this week in that regard has seemed mostly = positive. > =20 > Please review it, or at least the diff, and indicate your support or = objection on apps-discuss@ietf.org to adopting this one as the common = path forward. We would like to make a decision about which one to begin = advancing in the next week or two. > =20 > Have a good weekend! > =20 > -MSK, APPSAWG co-chair > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5A8D0118-211B-40B4-A539-BD72D26C9514 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii While it has some rough edges that we will need to = work on, I think this document can form the basis of a single path = forward.

John B.
On 2012-05-04, at 1:31 = PM, Murray S. Kucherawy wrote:

The above-named draft has been = offered as the recommended path forward in terms of converging on a = single document to advance through appsawg.  The conversation I saw = this week in that regard has seemed mostly = positive.
 
Please review it, or at least the diff, and indicate your = support or objection on apps-discuss@ietf.org to adopting this one as the = common path forward. We would like to make a decision about which one to = begin advancing in the next week or two.
 
Have a good = weekend!
 
-MSK, APPSAWG co-chair
 
___________________________________________= ____
OAuth mailing list
, Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050605090201080101060201" X-TI-Disclaimer: Disclaimer1 Cc: IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-mboned-mcaddrdoc-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:18:57 -0000 --------------ms050605090201080101060201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mboned-mcaddrdoc-03 Title: Multicast Addresses for Documentation Reviewer: Enrico Marocco Review Date: May 7, 2012 Summary: Besides the IANA-related issues already being discussed within the IESG, from an APPS point of view this draft is ready for publication as an Informational RFC. --------------ms050605090201080101060201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINfjCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHQjCCBiqgAwIBAgIDAt9AMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTEwODIyMDYyNDA2 WhcNMTIwODIyMDM0MDM3WjB8MSAwHgYDVQQNExc0OTAyNDItOU1QZVJYRnFlVVU0QUMybTEo MCYGA1UEAwwfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEuMCwGCSqGSIb3DQEJ ARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALl4L3Uj7TJrMbll5JAyphws2AMR67q3D2FH0JmRqQ5r+ujqaxyeHcrx Kclu2tz/D3SPtZAlcDOclxpEDbpxXlMpo+3DsbNweNgSF6mnyRDYU2ay3qO54ENz21GZ64bl ZRsMI6KsGnxm7sORWLUdx229ijARs3aQD1js9bidUJsnxg26UvnwpJ8eGoFiCLzzsQXUD+OL 3TXEGrTzt+B2RDb13TIOe085T8jzBh08wNKPTDmKjxy5m35Xn8QfRy8b93d0wUs98Fst5iND EgHEHc9CwurwLYrOd/1ZkbfAoRi7kRQ0Ih4wKkP+Lkww/0qHEIrrgW+aVmGjkQ0nidAaE+sC AwEAAaOCA7owggO2MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUYgEiK9qxBHth8ziqydxV7QYZn1QwHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVs ZWNvbWl0YWxpYS5pdDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4G CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUF BwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhp cyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVz IGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0 aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAF4gnxCzZVmINcZh7ZMB6G1+8/kV6pLqDxyUidalFSJ8KLwJxrxhESOb+E7d JHxZBuJFH1NBXuVn+MI7rqa/HI7PkLJjkHhMH8ay7jhR2VVMIFYAqRn9O22oDDw2iEigYkgo HcHP1vD5rtydbGr6mCcHOtWCk5B7FqEoMYTQRO1F6szoqORVaajVtZeSwtVAMufV20tohyUL hpOH5lZDblsej2XueyJVqD8RYSUJp7w4eMpr5CTP9QdNBS0cca83JA070JMudV+ozG6ADIBx mGPrWyPv7PmjBBGIXxPJJRxDsDyJBYhs+qh6fZWNl6WZkQNepkn7IAUB0+0ggds992kxggPQ MIIDzAIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30AwCQYF Kw4DAhoFAKCCAhAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwNTA3MDkxODUwWjAjBgkqhkiG9w0BCQQxFgQUCtDvEL0q/MYCv4bP9mdFft5UXIAwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAt9AMIGnBgsqhkiG 9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30Aw DQYJKoZIhvcNAQEBBQAEggEAQ82ncK5E/ghldaMo67mxwSVjX3+PSQ0JffR7oj3+zaVEAqo5 bfxELSkqb3V//ASTyZQzmltJoGTQxHlwFWwrN3RBFAoQ6ainZEYn+ZeB/x8/WsF/xt6yS7RJ HSWPPOQkMnS08YeyPmbeMpmyCpnKo2r9ETFtX4qLoMIKLzO4HQcMdADumT4AR/wrocdEiQDW FXyejLwltqASKwT/wh+AHPxQP6hTSyNueuM4c3DtZURHQ1+vpufof3gmf4jVWF6zw4WWryj7 nwMUAhWzkcgxPxOFTCq3CuxsTF6iurwl9wxwM1yXz2HRKHeHojFx349Tr5O4xGtmk4VQJYJU uVIGvQAAAAAAAA== --------------ms050605090201080101060201-- From laurentwalter.goix@telecomitalia.it Mon May 7 02:37:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6B321F851B; Mon, 7 May 2012 02:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eig12FvTyOHf; Mon, 7 May 2012 02:37:10 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id CBDB521F84CF; Mon, 7 May 2012 02:37:09 -0700 (PDT) Content-Type: multipart/mixed; boundary="_7fb53cf8-9d45-469c-bd29-09e83174aca5_" Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 7 May 2012 11:37:08 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Mon, 7 May 2012 11:37:08 +0200 From: Goix Laurent Walter To: "Gonzalo Salgueiro (gsalguei)" , "Murray S. Kucherawy" Date: Mon, 7 May 2012 11:37:06 +0200 Thread-Topic: [apps-discuss] draft-jones-appsawg-webfinger-04 Thread-Index: Ac0qLw91jpuP0JfARCag29xw1SJcwACBMmkA Message-ID: References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> In-Reply-To: <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: [apps-discuss] R: draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:37:11 -0000 --_7fb53cf8-9d45-469c-bd29-09e83174aca5_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE52EE435611GRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE52EE435611GRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIHN1cHBvcnQgdGhpcyBkcmFmdCBhcyBhIHdheSBmb3J3YXJkIGZvciB0aGUgZGlzY3Vz c2lvbiB0aGF0IEkgdGhpbmsgY2FwdHVyZXMgdGhlIGVzc2VuY2Ugb2YgYm90aCBwaGlsb3NvcGhp ZXMuDQoNCklmIHN1Y2ggYmFzaXMgaXMgYWdyZWVkIHdoYXQgYXJlIHRoZSBtYWpvciBwZW5kaW5n IGlzc3Vlcz8NCg0KUmVnYXJkcw0KTGF1cmVudC13YWx0ZXINCg0KRGE6IGFwcHMtZGlzY3Vzcy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIFBl ciBjb250byBkaSBHb256YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkpDQpJbnZpYXRvOiB2ZW5lcmTD rCA0IG1hZ2dpbyAyMDEyIDIxLjUwDQpBOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpDYzogb2F1dGhA aWV0Zi5vcmc7IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KT2dnZXR0bzogUmU6IFthcHBzLWRpc2N1 c3NdIGRyYWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyLTA0DQoNCkkgc3VwcG9ydCB0aGlzIGRv YyBiZWluZyBhZG9wdGVkIGFzIHN0YXJ0aW5nIHBvaW50IGZvciBXRyBkaXNjdXNzaW9uLg0KUmVn YXJkcywNCg0KR29uemFsbw0KDQoNCk9uIE1heSA0LCAyMDEyLCBhdCAzOjAzIFBNLCAiTXVycmF5 IFMuIEt1Y2hlcmF3eSIgPG1za0BjbG91ZG1hcmsuY29tPG1haWx0bzptc2tAY2xvdWRtYXJrLmNv bT4+IHdyb3RlOg0KVGhlIGFib3ZlLW5hbWVkIGRyYWZ0IGhhcyBiZWVuIG9mZmVyZWQgYXMgdGhl IHJlY29tbWVuZGVkIHBhdGggZm9yd2FyZCBpbiB0ZXJtcyBvZiBjb252ZXJnaW5nIG9uIGEgc2lu Z2xlIGRvY3VtZW50IHRvIGFkdmFuY2UgdGhyb3VnaCBhcHBzYXdnLiAgVGhlIGNvbnZlcnNhdGlv biBJIHNhdyB0aGlzIHdlZWsgaW4gdGhhdCByZWdhcmQgaGFzIHNlZW1lZCBtb3N0bHkgcG9zaXRp dmUuDQoNClBsZWFzZSByZXZpZXcgaXQsIG9yIGF0IGxlYXN0IHRoZSBkaWZmLCBhbmQgaW5kaWNh dGUgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbiBvbiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFp bHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gdG8gYWRvcHRpbmcgdGhpcyBvbmUgYXMgdGhlIGNv bW1vbiBwYXRoIGZvcndhcmQuIFdlIHdvdWxkIGxpa2UgdG8gbWFrZSBhIGRlY2lzaW9uIGFib3V0 IHdoaWNoIG9uZSB0byBiZWdpbiBhZHZhbmNpbmcgaW4gdGhlIG5leHQgd2VlayBvciB0d28uDQoN CkhhdmUgYSBnb29kIHdlZWtlbmQhDQoNCi1NU0ssIEFQUFNBV0cgY28tY2hhaXINCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3VzcyBt YWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNzQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1 c3MNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBl c2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlh IG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFi YmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2Vt ZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRl IGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUt bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4g cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5 LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNl IGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNl IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbY2lkOjAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXJdUmlzcGV0dGEgbCdhbWJpZW50ZS4g Tm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0KDQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE52EE435611GRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIg MiAzO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uU3RpbGVNZXNzYWdn aW9EaVBvc3RhRWxldHRyb25pY2ExNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJvbmljYTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9 IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYWxzbyBzdXBwb3J0IHRoaXMgZHJhZnQgYXMgYSB3YXkgZm9y d2FyZCBmb3IgdGhlIGRpc2N1c3Npb24gdGhhdCBJIHRoaW5rIGNhcHR1cmVzIHRoZSBlc3NlbmNl IG9mIGJvdGggcGhpbG9zb3BoaWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklmIHN1Y2ggYmFzaXMgaXMgYWdyZWVkIHdo YXQgYXJlIHRoZSBtYWpvciBwZW5kaW5nIGlzc3Vlcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+TGF1cmVudC13YWx0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJJVCIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGE6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJJVCIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5QZXIgY29udG8gZGkgPC9iPkdvbnph bG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSk8YnI+DQo8Yj5JbnZpYXRvOjwvYj4gdmVuZXJkw6wgNCBt YWdnaW8gMjAxMiAyMS41MDxicj4NCjxiPkE6PC9iPiBNdXJyYXkgUy4gS3VjaGVyYXd5PGJyPg0K PGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzsgYXBwcy1kaXNjdXNzQGlldGYub3JnPGJyPg0KPGI+ T2dnZXR0bzo8L2I+IFJlOiBbYXBwcy1kaXNjdXNzXSBkcmFmdC1qb25lcy1hcHBzYXdnLXdlYmZp bmdlci0wNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgc3VwcG9ydCB0aGlzIGRvYyBiZWlu ZyBhZG9wdGVkIGFzIHN0YXJ0aW5nIHBvaW50IGZvciBXRyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvbnphbG88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE1heSA0LCAyMDEyLCBhdCAzOjAzIFBN LCAmcXVvdDtNdXJyYXkgUy4gS3VjaGVyYXd5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXNr QGNsb3VkbWFyay5jb20iPm1za0BjbG91ZG1hcmsuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhYm92ZS1u YW1lZCBkcmFmdCBoYXMgYmVlbiBvZmZlcmVkIGFzIHRoZSByZWNvbW1lbmRlZCBwYXRoIGZvcndh cmQgaW4gdGVybXMgb2YgY29udmVyZ2luZyBvbiBhIHNpbmdsZSBkb2N1bWVudCB0byBhZHZhbmNl IHRocm91Z2ggYXBwc2F3Zy4mbmJzcDsgVGhlIGNvbnZlcnNhdGlvbiBJIHNhdyB0aGlzIHdlZWsg aW4gdGhhdCByZWdhcmQgaGFzIHNlZW1lZCBtb3N0bHkgcG9zaXRpdmUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlBsZWFzZSByZXZpZXcgaXQsIG9yIGF0IGxlYXN0IHRoZSBkaWZmLCBhbmQgaW5k aWNhdGUgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbiBvbg0KPGEgaHJlZj0ibWFpbHRvOmFwcHMt ZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPiB0byBhZG9wdGluZyB0 aGlzIG9uZSBhcyB0aGUgY29tbW9uIHBhdGggZm9yd2FyZC4gV2Ugd291bGQgbGlrZSB0byBtYWtl IGEgZGVjaXNpb24gYWJvdXQgd2hpY2ggb25lIHRvIGJlZ2luIGFkdmFuY2luZyBpbiB0aGUgbmV4 dCB3ZWVrIG9yIHR3by48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2ZSBhIGdvb2Qgd2Vla2Vu ZCE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LU1TSywgQVBQU0FXRyBjby1jaGFpcjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQphcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBw cy1kaXNjdXNzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlz Y3VzczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPg0KPCEtLQ0Kc3Bhbi5HcmFtRSB7 bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLS0+DQo8L3N0eWxlPg0KPHRh YmxlIHN0eWxlPSJ3aWR0aDo2MDBweDsiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJ3aWR0 aDo1ODVweDsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEFyaWFsOyBmb250LXNpemU6MTJweDsgY29s b3I6IzAwMDsgdGV4dC1hbGlnbjoganVzdGlmeSIgd2lkdGg9IjM5NSI+DQo8ZGl2IGFsaWduPSJq dXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 OyBsaW5lLWhlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6VmVyZGFuYSI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGlu ZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVz aW9uZSwgY29waWEgbyBxdWFsc2lhc2kNCiBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNv bm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0 ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBz aWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9u ZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXpp ZS4NCjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8cCBhbGlnbj0ianVzdGlmeSI+PHNwYW4gY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTsgbGluZS1oZWlnaHQ6bm9ybWFs Ij48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTpWZXJkYW5hO21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj5UaGlzIGUtbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzPC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToNCiAgNy41cHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpWZXJkYW5h O21zby1hbnNpLWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8c3BhbiBjbGFzcz0iR3JhbUUiPmlzPC9z cGFuPiZuYnNwOzwvc3Bhbj48L2k+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6DQogIDcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0Ii PmNvbmZpZGVudGlhbA0KIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGlu dGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcs IHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlcg0KIGJ5IHJldHVybiBl LW1haWwsIFRoYW5rcy48L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWFu c2ktbGFuZ3VhZ2U6RU4tR0IiPg0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpWZXJkYW5hIj48aW1nIHNyYz0iY2lkOjAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzQFRJLkRpc2NsYWltZXIiIGFsdD0icmlzcGV0 dGEgbCdhbWJpZW50ZSIgd2lkdGg9IjI2IiBoZWlnaHQ9IjQwIj5SaXNwZXR0YSBsJ2FtYmllbnRl LiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uPC9zcGFuPjwv Yj4NCjxwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_A09A9E0A4B9C654E8672D1DC003633AE52EE435611GRFMBX704BA02_-- --_7fb53cf8-9d45-469c-bd29-09e83174aca5_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_7fb53cf8-9d45-469c-bd29-09e83174aca5_-- From martin.peylo@nsn.com Mon May 7 02:59:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0291B21F857A; Mon, 7 May 2012 02:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5xhUH6vFViR; Mon, 7 May 2012 02:59:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6B21F856C; Mon, 7 May 2012 02:59:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q479x3Xr000344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 May 2012 11:59:03 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q479wwgf005426; Mon, 7 May 2012 11:58:59 +0200 Received: from FIESEXC006.nsn-intra.net ([10.159.0.14]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 11:58:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2012 12:58:49 +0300 Message-ID: <3BF363C82C184B46930A905352C2013F02103D94@FIESEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: APPSDIR review of draft-ietf-pkix-cmp-transport-protocols Thread-Index: Ac0r4rEJl95KJo3dSmCER59iPVrQEAAU+f/w References: <8E1AF099-0252-4032-8769-E8F794BFFAD2@mnot.net> <3BF363C82C184B46930A905352C2013F02103860@FIESEXC006.nsn-intra.net> From: "Peylo, Martin (NSN - FI/Espoo)" To: "ext Mark Nottingham" X-OriginalArrivalTime: 07 May 2012 09:58:58.0696 (UTC) FILETIME=[05939080:01CD2C38] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1433 X-purgate-ID: 151667::1336384744-00001F01-0FF2679B/0-0/0-0 Cc: toka@tectia.com, draft-ietf-pkix-cmp-transport-protocols.all@tools.ietf.org, ext Sean Turner , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:59:09 -0000 Hi Mark, thank you for that! [...] > We're clarifying this in HTTPbis, but of course that doesn't help you > *right* now. >=20 > I'd change to something like: >=20 > HTTP persistent connections [ref to 2616] allow multiple interactions to > take place on the same HTTP connection. However, neither HTTP nor this > protocol are designed to correlate messages on the same connection in > any meaningful way; persistent connections are only a performance > optimisation. In particular, intermediaries can do things like mix > connections from different clients into one "upstream" connections, > terminate persistent connections and forward requests as non-persistent > requests, etc. As such, implementations MUST NOT infer that requests on > the same connection come from the same client (e.g., for purposes of > authentication); every message is to be evaluated in isolation. Excellent paragraph - it will certainly stand out in terms of technical and linguistic quality! I will take that 1:1 but would like to change the "(e.g., for purposes of authentication)" to "(e.g., for correlating PKI messages with ongoing transactions)" as this better describes the most probable use case CMP implementers could be tempted to use this for. When that is OK for you I'll insert that and upload the draft for which Sean then can issue the LC (provided everything is OK for him). Kind regards, Martin From mnot@mnot.net Mon May 7 03:08:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B9021F85AD; Mon, 7 May 2012 03:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMIThQcllYAu; Mon, 7 May 2012 03:08:22 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 867AF21F8567; Mon, 7 May 2012 03:08:14 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.44.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 75A9E22E1F4; Mon, 7 May 2012 06:08:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <3BF363C82C184B46930A905352C2013F02103D94@FIESEXC006.nsn-intra.net> Date: Mon, 7 May 2012 20:08:06 +1000 Content-Transfer-Encoding: 7bit Message-Id: <01E8ED34-102F-47D9-8F62-A91A5E271202@mnot.net> References: <8E1AF099-0252-4032-8769-E8F794BFFAD2@mnot.net> <3BF363C82C184B46930A905352C2013F02103860@FIESEXC006.nsn-intra.net> <3BF363C82C184B46930A905352C2013F02103D94@FIESEXC006.nsn-intra.net> To: "Peylo, Martin (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1257) Cc: toka@tectia.com, draft-ietf-pkix-cmp-transport-protocols.all@tools.ietf.org, ext Sean Turner , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 10:08:23 -0000 Works for me. Cheers, On 07/05/2012, at 7:58 PM, Peylo, Martin (NSN - FI/Espoo) wrote: > Hi Mark, > > thank you for that! > > [...] >> We're clarifying this in HTTPbis, but of course that doesn't help you >> *right* now. >> >> I'd change to something like: >> >> HTTP persistent connections [ref to 2616] allow multiple interactions > to >> take place on the same HTTP connection. However, neither HTTP nor this >> protocol are designed to correlate messages on the same connection in >> any meaningful way; persistent connections are only a performance >> optimisation. In particular, intermediaries can do things like mix >> connections from different clients into one "upstream" connections, >> terminate persistent connections and forward requests as > non-persistent >> requests, etc. As such, implementations MUST NOT infer that requests > on >> the same connection come from the same client (e.g., for purposes of >> authentication); every message is to be evaluated in isolation. > > Excellent paragraph - it will certainly stand out in terms of technical > and linguistic quality! I will take that 1:1 but would like to change > the "(e.g., for purposes of authentication)" to "(e.g., for correlating > PKI messages with ongoing transactions)" as this better describes the > most probable use case CMP implementers could be tempted to use this > for. > > When that is OK for you I'll insert that and upload the draft for which > Sean then can issue the LC (provided everything is OK for him). > > Kind regards, > Martin -- Mark Nottingham http://www.mnot.net/ From paulej@packetizer.com Mon May 7 06:17:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B70E21F85BD; Mon, 7 May 2012 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwV7R2QK6nE6; Mon, 7 May 2012 06:17:00 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4256A21F85B7; Mon, 7 May 2012 06:17:00 -0700 (PDT) Received: from [156.106.244.92] ([156.106.244.92]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q47DGXam007831 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 7 May 2012 09:16:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336396595; bh=Dpf2khUBG8MtxU9NenIHHSD8szNTUOiKpGpy7ugK+pw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=YYcC/pxhW9+W5TcY35jfMpRsqyciejQRCh85ZAHuZ/ZFB39idNwiyM+8lgd8Yl28P Cd5dAZtS9unS/Hqv5wkuc2CNJPgEEPBi0mFPfnO7epbsVEkyLTbVc+fR5VAAxURfP/ lbpl18EGHi6y6ETWoWq85XJGuElsJNpNpoMLRqYA= Message-ID: <4FA7CB3A.4020000@packetizer.com> Date: Mon, 07 May 2012 09:16:42 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Goix Laurent Walter References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050404080207070600040108" Cc: "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:17:01 -0000 This is a multi-part message in MIME format. --------------050404080207070600040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Walter, I'm not sure what the full set of issues will be, but I only have a couple of small edits queued for -05 at present (one being "template" should be "href" in the example at the end of 4.2 that you pointed out to me privately). We've already worked through a number of issues to get to this point, so there may not be a lot of changes needed. I'll not dismiss the possibility that there are editorial issues, but I hope we've resolved most of the technical details. We probably still need to have the discussion of keeping CORS and what additions are needed to the security section. We've made a few changes there already, but I'm not sure if it still fully addresses some of the privacy concerns. Paul On 5/7/2012 5:37 AM, Goix Laurent Walter wrote: > > I also support this draft as a way forward for the discussion that I > think captures the essence of both philosophies. > > If such basis is agreed what are the major pending issues? > > Regards > > Laurent-walter > > *Da:*apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] *Per conto di *Gonzalo > Salgueiro (gsalguei) > *Inviato:* venerdì 4 maggio 2012 21.50 > *A:* Murray S. Kucherawy > *Cc:* oauth@ietf.org; apps-discuss@ietf.org > *Oggetto:* Re: [apps-discuss] draft-jones-appsawg-webfinger-04 > > I support this doc being adopted as starting point for WG discussion. > > Regards, > > Gonzalo > > > On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" > wrote: > > The above-named draft has been offered as the recommended path > forward in terms of converging on a single document to advance > through appsawg. The conversation I saw this week in that regard > has seemed mostly positive. > > Please review it, or at least the diff, and indicate your support > or objection on apps-discuss@ietf.org > to adopting this one as the common > path forward. We would like to make a decision about which one to > begin advancing in the next week or two. > > Have a good weekend! > > -MSK, APPSAWG co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --------------050404080207070600040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Walter,

I'm not sure what the full set of issues will be, but I only have a couple of small edits queued for -05 at present (one being "template" should be "href" in the example at the end of 4.2 that you pointed out to me privately).  We've already worked through a number of issues to get to this point, so there may not be a lot of changes needed.  I'll not dismiss the possibility that there are editorial issues, but I hope we've resolved most of the technical details.

We probably still need to have the discussion of keeping CORS and what additions are needed to the security section.  We've made a few changes there already, but I'm not sure if it still fully addresses some of the privacy concerns.

Paul

On 5/7/2012 5:37 AM, Goix Laurent Walter wrote:

I also support this draft as a way forward for the discussion that I think captures the essence of both philosophies.

 

If such basis is agreed what are the major pending issues?

 

Regards

Laurent-walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Gonzalo Salgueiro (gsalguei)
Inviato: venerdì 4 maggio 2012 21.50
A: Murray S. Kucherawy
Cc: oauth@ietf.org; apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] draft-jones-appsawg-webfinger-04

 

I support this doc being adopted as starting point for WG discussion.

Regards,

 

Gonzalo

 


On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" <msk@cloudmark.com> wrote:

The above-named draft has been offered as the recommended path forward in terms of converging on a single document to advance through appsawg.  The conversation I saw this week in that regard has seemed mostly positive.

 

Please review it, or at least the diff, and indicate your support or objection on apps-discuss@ietf.org to adopting this one as the common path forward. We would like to make a decision about which one to begin advancing in the next week or two.

 

Have a good weekend!

 

-MSK, APPSAWG co-chair

 

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--------------050404080207070600040108-- From ajs@anvilwalrusden.com Mon May 7 08:13:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CD021F85E7; Mon, 7 May 2012 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMzt1lhfmFh6; Mon, 7 May 2012 08:13:05 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 01B8A21F85D6; Mon, 7 May 2012 08:13:03 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 238181ECB41D; Mon, 7 May 2012 15:13:03 +0000 (UTC) Date: Mon, 7 May 2012 11:13:01 -0400 From: Andrew Sullivan To: Paul Hoffman Message-ID: <20120507151257.GH8963@mail.yitter.info> References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: The IESG , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 15:13:06 -0000 On Sat, May 05, 2012 at 07:21:51AM -0700, Paul Hoffman wrote: > > Note that the document explicitly states in the last paragraph of > section 1.2 that "This document only relates to securely associating > certificates for TLS and DTLS with host names". We are not talking > just "domain names" (which are made up of labels of octets) but > "host names" which are made up of labels of ASCII. We were told > (wisely) not to try to reopen this can of worms, so we didn't. Aha, good point. I guess this needs a normative reference to RFC 952, then? That's actually the most recent RFC that establishes the host rules. > OLD > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. > > NEW > > 3. The domain name is appended to the result of step 2 to complete > the prepared domain name. (The domain name is the fully > qualified DNS domain name [RFC1035] of the TLS server and is > represented as a byte string where each label is encoded > using ASCII; this enables support for internationalized > domain names through the use of A-labels as defined in > [RFC5890].) I'm still uncomfortable with this, because it's not technically accurate. When you send the QNAME, it's not a "byte string" and the labels aren't encoded. They're octets, not strings. How about 3. The base domain name is appended to the result of step 2 to complete the prepared domain name. The base domain name is the fully-qualified DNS domain name [RFC1035] of the TLS server, with the additional restriction that every label must meet the rules of [RFC952]. The latter restriction means that, if the query is for an internationalized domain name, it must use the A-label form as defined in [RFC5890]. ? I added the modifier "base" to this to make it clear that we're not defining what domain names are, although I don't myself feel too strongly about that addition. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon May 7 08:14:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403C621F85F1; Mon, 7 May 2012 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1IarkI-ekLg; Mon, 7 May 2012 08:14:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C07FF21F85ED; Mon, 7 May 2012 08:14:39 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EBC611ECB41D; Mon, 7 May 2012 15:14:38 +0000 (UTC) Date: Mon, 7 May 2012 11:14:37 -0400 From: Andrew Sullivan To: Martin Rex Message-ID: <20120507151437.GI8963@mail.yitter.info> References: <20120504223816.GV7394@crankycanuck.ca> <201205050438.q454cC0K021676@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205050438.q454cC0K021676@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, paul.hoffman@vpnc.org Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 15:14:40 -0000 On Sat, May 05, 2012 at 06:38:12AM +0200, Martin Rex wrote: > Do we expect the target audience (folks implementing DANE protocol) > to use an API like that of libresolv's res_query(), where the representation > appears to be still a single string rather than individual DNS labels, > or that they're caller of even lower APIs? They'll certainly need to call something other than getaddrinfo(), because they need to know whether validation succeeded and you can't find it out that way. > res_query? The default behaviour of gethostbyname(), trying completion > of a name that doesn't end with a dot/period with (default) domain or > entries from a (domain) searchlist (res_search?) would likely > risk unpleasant consequences. Indeed. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From martin.thomson@gmail.com Mon May 7 08:56:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F72C21F84AF for ; Mon, 7 May 2012 08:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.774 X-Spam-Level: X-Spam-Status: No, score=-3.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp-99Tj2lhTa for ; Mon, 7 May 2012 08:56:03 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73E1A21F849D for ; Mon, 7 May 2012 08:56:03 -0700 (PDT) Received: by bkty8 with SMTP id y8so4651584bkt.31 for ; Mon, 07 May 2012 08:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M3Sbbtvi2L04q0cHnX/jVoOSCbGwMm4rnwH0QUYTH4U=; b=g3bERe9TYA7FaqWeBWElZgryTV30GcgbpQnhbLf2BOxWI8kjKQIlwvkdGHbsnjeUk9 xAVXQtJOI13GUOAnrdF6aKBK/vcUwlfcm9CvETMam2t0M/+1E0axQoU6jFiqkFtlx/CZ SzwcF+7bxc8q9w0S1y1qp1EINSdyMsZ4KSr/Cub9dJGEJhIFXR3RXbjkL3C2IFfKl0Pg NnwTugEJWwrUuxDArSkk8JjerGD8JF6NTTKYd64t3i1LsI9bahYh6B57bIYhLsuPR/CR cL6sAu93SSxZ68t5V26xBFAq8HVQ/R/MBoGTvQ0CexAj+WOoAxp4fO+D8GDuc5r3aepH vOdA== MIME-Version: 1.0 Received: by 10.204.153.204 with SMTP id l12mr5635488bkw.49.1336406162442; Mon, 07 May 2012 08:56:02 -0700 (PDT) Received: by 10.204.185.205 with HTTP; Mon, 7 May 2012 08:56:02 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F28540B5@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> <4FA68A60.6030207@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F28540B5@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 7 May 2012 08:56:02 -0700 Message-ID: From: Martin Thomson To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 15:56:04 -0000 > I would still rather ditch the truncation length from the alg names. I'm with James on this one. Concerns about checking too-short hashes don't seem so serious. After all, the incentive is with the client to check as much of the hash as they can. Thus, the only concern is if an attacker can force a shorter hash somehow. The example of a truncated stream cipher seems contrived to me. From turners@ieca.com Mon May 7 03:13:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E061821F859E for ; Mon, 7 May 2012 03:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAiRHTc-voIw for ; Mon, 7 May 2012 03:13:42 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.124.13]) by ietfa.amsl.com (Postfix) with ESMTP id 32B7021F8593 for ; Mon, 7 May 2012 03:13:42 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 83FB254802153; Mon, 7 May 2012 05:13:41 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 78E9654802120 for ; Mon, 7 May 2012 05:13:41 -0500 (CDT) Received: from [71.191.4.88] (port=45334 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRKwm-0000hx-Rs; Mon, 07 May 2012 05:13:41 -0500 Message-ID: <4FA7A053.7090706@ieca.com> Date: Mon, 07 May 2012 06:13:39 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Peylo, Martin (NSN - FI/Espoo)" References: <8E1AF099-0252-4032-8769-E8F794BFFAD2@mnot.net> <3BF363C82C184B46930A905352C2013F02103860@FIESEXC006.nsn-intra.net> <3BF363C82C184B46930A905352C2013F02103D94@FIESEXC006.nsn-intra.net> <01E8ED34-102F-47D9-8F62-A91A5E271202@mnot.net> In-Reply-To: <01E8ED34-102F-47D9-8F62-A91A5E271202@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-4-88.washdc.east.verizon.net (thunderfish.local) [71.191.4.88]:45334 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= X-Mailman-Approved-At: Mon, 07 May 2012 09:17:35 -0700 Cc: toka@tectia.com, Mark Nottingham , draft-ietf-pkix-cmp-transport-protocols.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 10:13:43 -0000 Great post a new version and I'll get the IETF LC started. spt On 5/7/12 6:08 AM, Mark Nottingham wrote: > Works for me. > > Cheers, > > On 07/05/2012, at 7:58 PM, Peylo, Martin (NSN - FI/Espoo) wrote: > >> Hi Mark, >> >> thank you for that! >> >> [...] >>> We're clarifying this in HTTPbis, but of course that doesn't help you >>> *right* now. >>> >>> I'd change to something like: >>> >>> HTTP persistent connections [ref to 2616] allow multiple interactions >> to >>> take place on the same HTTP connection. However, neither HTTP nor this >>> protocol are designed to correlate messages on the same connection in >>> any meaningful way; persistent connections are only a performance >>> optimisation. In particular, intermediaries can do things like mix >>> connections from different clients into one "upstream" connections, >>> terminate persistent connections and forward requests as >> non-persistent >>> requests, etc. As such, implementations MUST NOT infer that requests >> on >>> the same connection come from the same client (e.g., for purposes of >>> authentication); every message is to be evaluated in isolation. >> >> Excellent paragraph - it will certainly stand out in terms of technical >> and linguistic quality! I will take that 1:1 but would like to change >> the "(e.g., for purposes of authentication)" to "(e.g., for correlating >> PKI messages with ongoing transactions)" as this better describes the >> most probable use case CMP implementers could be tempted to use this >> for. >> >> When that is OK for you I'll insert that and upload the draft for which >> Sean then can issue the LC (provided everything is OK for him). >> >> Kind regards, >> Martin > > -- > Mark Nottingham http://www.mnot.net/ > > > > From iesg-secretary@ietf.org Mon May 7 12:51:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82FF21F8661; Mon, 7 May 2012 12:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75oS5jpOK9Qq; Mon, 7 May 2012 12:51:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6521F861E; Mon, 7 May 2012 12:51:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507195115.20045.36703.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 12:51:15 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Media Type Specifications and Registration Procedures) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 19:51:17 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Media Type Specifications and Registration Procedures' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/ballot/ No IPR declarations have been submitted directly on this I-D. From glenn.parsons@ericsson.com Mon May 7 18:16:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE09421F8534 for ; Mon, 7 May 2012 18:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iavhChMO1LoK for ; Mon, 7 May 2012 18:16:53 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E85C121F84E6 for ; Mon, 7 May 2012 18:16:52 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q481Gl9M013355; Mon, 7 May 2012 20:16:48 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.132]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 7 May 2012 21:16:41 -0400 From: Glenn Parsons To: Jiankang YAO , "draft-ietf-eai-rfc5721bis-04.all@tools.ietf.org" , "apps-discuss@ietf.org" Date: Mon, 7 May 2012 21:16:39 -0400 Thread-Topic: [apps-discuss] APPSDIR review of draft-ietf-eai-rfc5721bis-04 Thread-Index: Ac0r9zUD56HbnpBISxCJ46iJsFjYAgAwGdzw Message-ID: References: <01EDC4A34A33404AABBD98D6658718B0@LENOVO47E041CF> In-Reply-To: <01EDC4A34A33404AABBD98D6658718B0@LENOVO47E041CF> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FFB5EEUSAACMS0714e_" MIME-Version: 1.0 Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-eai-rfc5721bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 01:16:53 -0000 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FFB5EEUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On this point, I would think that consistency between draft-ietf-eai-rfc572= 1bis and draft-iet= f-eai-5738bis would b= e appropriate. That is they should either both mention it in the abstract or not. My sugg= estion, based on the Nit tool, was that they should mention it. Cheers, Glenn. ________________________________ From: Jiankang YAO [mailto:yaojk@cnnic.cn] Sent: May-06-12 10:15 PM To: Glenn Parsons; draft-ietf-eai-rfc5721bis-04.all@tools.ietf.org; apps-di= scuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-eai-rfc5721bis-04 I think that AD has clarified that IESG did not ask to mention the obsolete= d rfc in the abstract. Jiankang Yao ----- Original Message ----- From: Glenn Parsons To: draft-ietf-eai-rfc5721bis-04.all@tools.ietf.org ; apps-discuss@ietf.org Sent: Monday, May 07, 2012 1:58 AM Subject: [apps-discuss] APPSDIR review of draft-ietf-eai-rfc5721bis-04 Nits: -- The draft header indicates that this document obsoletes RFC5721, but the= abstract doesn't seem to mention this, which it should ________________________________ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FFB5EEUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On this point, I would think that consistency betw= een draft-ietf-eai-rfc5721bis and draft-ietf-eai-5738bis would be appropriate.
 
That is they should either both mention it in the = abstract=20 or not.  My suggestion, based on the Nit tool, was that they should me= ntion=20 it.
 
Cheers,
Glenn.

From: Jiankang YAO [mailto:yaojk@cnnic.= cn]=20
Sent: May-06-12 10:15 PM
To: Glenn Parsons;=20 draft-ietf-eai-rfc5721bis-04.all@tools.ietf.org;=20 apps-discuss@ietf.org
Subject: Re: [apps-discuss] APPSDIR review = of=20 draft-ietf-eai-rfc5721bis-04

 
 
I think that AD has clarified t= hat IESG did not ask to=20 mention the obsoleted rfc in the abstract.
 
Jiankang Yao
----- Original Message -----
From:=20 Glenn Parsons
To: draft-iet= f-eai-rfc5721bis-04.all@tools.ietf.org=20 ; apps-discuss@ietf.org
Sent: Monday, May 07, 20= 12 1:58 AM
Subject: [apps-discuss] = APPSDIR review of=20 draft-ietf-eai-rfc5721bis-04
 
Nits:
-- The draft header in= dicates=20 that this document obsoletes RFC5721, but the abstract doesn't seem to me= ntion=20 this, which it should
 
 

_______________________________________________
apps-discuss ma= iling=20 list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/ap= ps-discuss
--_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34B295FFB5EEUSAACMS0714e_-- From ned.freed@mrochek.com Mon May 7 19:37:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A921E21F85D8 for ; Mon, 7 May 2012 19:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJhrMNY+ShiJ for ; Mon, 7 May 2012 19:37:19 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5B121F85D7 for ; Mon, 7 May 2012 19:37:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7OBAE5MO0013MU@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 7 May 2012 19:37:16 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com>; Mon, 7 May 2012 19:37:13 -0700 (PDT) Message-id: <01OF7OB8QAPI0006TF@mauve.mrochek.com> Date: Mon, 07 May 2012 19:30:53 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 07 May 2012 21:16:39 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01EDC4A34A33404AABBD98D6658718B0@LENOVO47E041CF> To: Glenn Parsons Cc: "draft-ietf-eai-rfc5721bis-04.all@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-eai-rfc5721bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 02:37:19 -0000 > On this point, I would think that consistency between > draft-ietf-eai-rfc5721bis > and > draft-ietf-eai-5738bis > would be appropriate. By that standard, they should not mention it, because RFCs 6530-6533 do not. > That is they should either both mention it in the abstract or not. My > suggestion, based on the Nit tool, was that they should mention it. Rather than following the advice from a piece of software, I suggest thinking about the two purposes abstracts serve and whether or not such a sentence actually makes sense for either one. My conclusion was that it doesn't. Ned From romeda@gmail.com Mon May 7 23:40:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBB321F85C4; Mon, 7 May 2012 23:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.536 X-Spam-Level: X-Spam-Status: No, score=-103.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE2ZSTuNiJle; Mon, 7 May 2012 23:40:49 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C80DD21F85C2; Mon, 7 May 2012 23:40:48 -0700 (PDT) Received: by lagj5 with SMTP id j5so4550009lag.31 for ; Mon, 07 May 2012 23:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CHqqTCvn+dFkGCAp2J6+QwyOokSSSR3Bv5TTf/nmAps=; b=EoKIS66ujabwvB/0posTm5KGgcHqe9K5cejyMjzYVZnlIcKp89o9LmtHNbXPZlb3OD aZZL9NP+zqLLm7PBztybQnSKBfeIG4eJYaT0t6zR7LStIBdCg8de6IwB61faaQIbo9Xf h1VydtOBOEc8lV14ejpDTq+pvjFva1FWUkCHxeecm3sh/grysepp0kVWpta0hKH/AGus 554gSB/Hep6jDGq3i6EQvGD2YQfsi2fAPqjJgBDRfJezZwo11HHo8G+5vv0qMpUwSu/4 KV4YQ+vqlJJGa4BSGXF510jRgsCtiKVRQT9sW3IJGuUPSY8OkoLBbE+4fnyCtJOaCMHs uRgg== MIME-Version: 1.0 Received: by 10.152.146.163 with SMTP id td3mr16605432lab.25.1336459247613; Mon, 07 May 2012 23:40:47 -0700 (PDT) Received: by 10.152.24.229 with HTTP; Mon, 7 May 2012 23:40:46 -0700 (PDT) Received: by 10.152.24.229 with HTTP; Mon, 7 May 2012 23:40:46 -0700 (PDT) In-Reply-To: <4FA7CB3A.4020000@packetizer.com> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <4FA7CB3A.4020000@packetizer.com> Date: Tue, 8 May 2012 08:40:46 +0200 Message-ID: From: Blaine Cook To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f234567b5f66d04bf80aa04 Cc: apps-discuss@ietf.org, "oauth@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] R: draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 06:40:51 -0000 --e89a8f234567b5f66d04bf80aa04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I disagree that the current spec is a good starting point - the issues I've raised have been ignored, and the spec is now much more complicated from both sides of the implementation fence. On May 7, 2012 3:17 PM, "Paul E. Jones" wrote: > Walter, > > I'm not sure what the full set of issues will be, but I only have a coupl= e > of small edits queued for -05 at present (one being "template" should be > "href" in the example at the end of 4.2 that you pointed out to me > privately). We've already worked through a number of issues to get to th= is > point, so there may not be a lot of changes needed. I'll not dismiss the > possibility that there are editorial issues, but I hope we've resolved mo= st > of the technical details. > > We probably still need to have the discussion of keeping CORS and what > additions are needed to the security section. We've made a few changes > there already, but I'm not sure if it still fully addresses some of the > privacy concerns. > > Paul > > On 5/7/2012 5:37 AM, Goix Laurent Walter wrote: > > I also support this draft as a way forward for the discussion that I > think captures the essence of both philosophies. **** > > ** ** > > If such basis is agreed what are the major pending issues?**** > > ** ** > > Regards**** > > Laurent-walter**** > > ** ** > > *Da:* apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > *Per conto di *Gonzalo Salgueiro (gsalguei) > *Inviato:* venerd=C3=AC 4 maggio 2012 21.50 > *A:* Murray S. Kucherawy > *Cc:* oauth@ietf.org; apps-discuss@ietf.org > *Oggetto:* Re: [apps-discuss] draft-jones-appsawg-webfinger-04**** > > ** ** > > I support this doc being adopted as starting point for WG discussion.**** > > Regards,**** > > ** ** > > Gonzalo**** > > ** ** > > > On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" > wrote:**** > > The above-named draft has been offered as the recommended path forward > in terms of converging on a single document to advance through appsawg. > The conversation I saw this week in that regard has seemed mostly positiv= e. > **** > > **** > > Please review it, or at least the diff, and indicate your support or > objection on apps-discuss@ietf.org to adopting this one as the common > path forward. We would like to make a decision about which one to begin > advancing in the next week or two.**** > > **** > > Have a good weekend!**** > > **** > > -MSK, APPSAWG co-chair**** > > **** > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --e89a8f234567b5f66d04bf80aa04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I disagree that the current spec is a good starting point - the issues I= 've raised have been ignored, and the spec is now much more complicated= from both sides of the implementation fence.

On May 7, 2012 3:17 PM, "Paul E. Jones"= ; <paulej@packetizer.com>= ; wrote:
=20 =20 =20
Walter,

I'm not sure what the full set of issues will be, but I only have a couple of small edits queued for -05 at present (one being "template" should be "href" in the example at the e= nd of 4.2 that you pointed out to me privately).=C2=A0 We've already worked throug= h a number of issues to get to this point, so there may not be a lot of changes needed.=C2=A0 I'll not dismiss the possibility that there a= re editorial issues, but I hope we've resolved most of the technical details.

We probably still need to have the discussion of keeping CORS and what additions are needed to the security section.=C2=A0 We've made= a few changes there already, but I'm not sure if it still fully addresses some of the privacy concerns.

Paul

On 5/7/2012 5:37 AM, Goix Laurent Walter wrote:
=20 =20 =20

I also support this draft as a way forward for the discussion that I think captures the essence of both philosophies.

=C2=A0

If such basis is agreed what are the major pending issues?<= u>

=C2=A0

Regards

Laurent-walter

=C2=A0

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Gonzalo Salgueiro (gsalguei)
Inviato: venerd=C3=AC 4 maggio 2012 21.50
A: Murray S. Kucherawy
Cc: oauth@ietf.org; apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] draft-jones-appsawg-webfinger-04

=C2=A0

I support this doc being adopted as starting point for WG discussion.

Regards,

=C2=A0

Gonzalo

=C2=A0


On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" &= lt;msk@cloudmark.com= > wrote:

The above-named draft has been offered as the recommended path forward in terms of converging on a single document to advance through appsawg.=C2=A0 The conversation I saw this week in that regard has seemed mostly positive.

=C2=A0

Please review it, or at least the diff, and indicate your support or objection on = apps-discuss@ietf.org to adopting this one as the common path forward. We would like to make a decision about which one to begin advancing in the next week or two.

=C2=A0

Have a good weekend!

=C2=A0

-MSK, APPSAWG co-chair

=C2=A0

________________________________= _______________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>



_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--e89a8f234567b5f66d04bf80aa04-- From eran@hueniverse.com Mon May 7 23:50:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6EA21F85D8 for ; Mon, 7 May 2012 23:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsLXjPPi8f-l for ; Mon, 7 May 2012 23:50:53 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCB421F85D6 for ; Mon, 7 May 2012 23:50:53 -0700 (PDT) Received: from P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id 7Jqs1j0040EuLVk01JqsSo; Mon, 07 May 2012 23:50:52 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT003.ex2.secureserver.net ([184.168.131.11]) with mapi id 14.02.0247.003; Mon, 7 May 2012 23:50:52 -0700 From: Eran Hammer To: Blaine Cook , "Paul E. Jones" Thread-Topic: [apps-discuss] [OAUTH-WG] R: draft-jones-appsawg-webfinger-04 Thread-Index: AQHNLOWEDc34xiwz8UyUqTbvUwqrbZa/cxTw Date: Tue, 8 May 2012 06:50:51 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20102287D@P3PWEX2MB008.ex2.secureserver.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <4FA7CB3A.4020000@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: multipart/alternative; boundary="_000_0CBAEB56DDB3A140BA8E8C124C04ECA20102287DP3PWEX2MB008ex2_" MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] R: draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 06:50:55 -0000 --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20102287DP3PWEX2MB008ex2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsIHRoZSBpc3N1ZXMgcmFpc2VkIHNob3VsZCBiZSB0aGUgc3RhcnRpbmcgcG9pbnQgZm9yIGRp c2N1c3Npb24gb24gdGhpcyBhcyBhIFdHIGl0ZW0uIEkgZG8gbm90IHRoaW5rIGFueSBvZiB0aGVt IGhhcyBiZWVuIHJlc29sdmVkLiBUaGUgb25seSBwb2ludCBoZXJlIGlzIHRoYXQgd2UgaGF2ZSBh IHNpbmdsZSBkb2N1bWVudCBmb3IgYSBzdGFydGluZyBwb2ludC4gVXNpbmcgdGhpcyBkb2N1bWVu dCBkb2VzIG5vdCByZWZsZWN0IGFueSBjb25zZW5zdXMgb24gdGhlIGZpbmFsIHByb2R1Y3QuIFlv dXIgdGhyZWUgaXRlbXMgc2hvdWxkIGJlIGxpc3RlZCBpbiB0aGUgaXNzdWUgdHJhY2tlciBhcyBz b29uIGFzIHRoaXMgaGFzIHByb2dyZXNzZWQgZW5vdWdoLg0KDQpFSA0KDQpGcm9tOiBhcHBzLWRp c2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQmxhaW5lIENvb2sNClNlbnQ6IE1vbmRheSwgTWF5IDA3LCAyMDEy IDExOjQxIFBNDQpUbzogUGF1bCBFLiBKb25lcw0KQ2M6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzsg b2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBbT0FVVEgtV0ddIFI6 IGRyYWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyLTA0DQoNCg0KSSBkaXNhZ3JlZSB0aGF0IHRo ZSBjdXJyZW50IHNwZWMgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50IC0gdGhlIGlzc3VlcyBJJ3Zl IHJhaXNlZCBoYXZlIGJlZW4gaWdub3JlZCwgYW5kIHRoZSBzcGVjIGlzIG5vdyBtdWNoIG1vcmUg Y29tcGxpY2F0ZWQgZnJvbSBib3RoIHNpZGVzIG9mIHRoZSBpbXBsZW1lbnRhdGlvbiBmZW5jZS4N Ck9uIE1heSA3LCAyMDEyIDM6MTcgUE0sICJQYXVsIEUuIEpvbmVzIiA8cGF1bGVqQHBhY2tldGl6 ZXIuY29tPG1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20+PiB3cm90ZToNCldhbHRlciwNCg0K SSdtIG5vdCBzdXJlIHdoYXQgdGhlIGZ1bGwgc2V0IG9mIGlzc3VlcyB3aWxsIGJlLCBidXQgSSBv bmx5IGhhdmUgYSBjb3VwbGUgb2Ygc21hbGwgZWRpdHMgcXVldWVkIGZvciAtMDUgYXQgcHJlc2Vu dCAob25lIGJlaW5nICJ0ZW1wbGF0ZSIgc2hvdWxkIGJlICJocmVmIiBpbiB0aGUgZXhhbXBsZSBh dCB0aGUgZW5kIG9mIDQuMiB0aGF0IHlvdSBwb2ludGVkIG91dCB0byBtZSBwcml2YXRlbHkpLiAg V2UndmUgYWxyZWFkeSB3b3JrZWQgdGhyb3VnaCBhIG51bWJlciBvZiBpc3N1ZXMgdG8gZ2V0IHRv IHRoaXMgcG9pbnQsIHNvIHRoZXJlIG1heSBub3QgYmUgYSBsb3Qgb2YgY2hhbmdlcyBuZWVkZWQu ICBJJ2xsIG5vdCBkaXNtaXNzIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRoZXJlIGFyZSBlZGl0b3Jp YWwgaXNzdWVzLCBidXQgSSBob3BlIHdlJ3ZlIHJlc29sdmVkIG1vc3Qgb2YgdGhlIHRlY2huaWNh bCBkZXRhaWxzLg0KDQpXZSBwcm9iYWJseSBzdGlsbCBuZWVkIHRvIGhhdmUgdGhlIGRpc2N1c3Np b24gb2Yga2VlcGluZyBDT1JTIGFuZCB3aGF0IGFkZGl0aW9ucyBhcmUgbmVlZGVkIHRvIHRoZSBz ZWN1cml0eSBzZWN0aW9uLiAgV2UndmUgbWFkZSBhIGZldyBjaGFuZ2VzIHRoZXJlIGFscmVhZHks IGJ1dCBJJ20gbm90IHN1cmUgaWYgaXQgc3RpbGwgZnVsbHkgYWRkcmVzc2VzIHNvbWUgb2YgdGhl IHByaXZhY3kgY29uY2VybnMuDQoNClBhdWwNCg0KT24gNS83LzIwMTIgNTozNyBBTSwgR29peCBM YXVyZW50IFdhbHRlciB3cm90ZToNCkkgYWxzbyBzdXBwb3J0IHRoaXMgZHJhZnQgYXMgYSB3YXkg Zm9yd2FyZCBmb3IgdGhlIGRpc2N1c3Npb24gdGhhdCBJIHRoaW5rIGNhcHR1cmVzIHRoZSBlc3Nl bmNlIG9mIGJvdGggcGhpbG9zb3BoaWVzLg0KDQpJZiBzdWNoIGJhc2lzIGlzIGFncmVlZCB3aGF0 IGFyZSB0aGUgbWFqb3IgcGVuZGluZyBpc3N1ZXM/DQoNClJlZ2FyZHMNCkxhdXJlbnQtd2FsdGVy DQoNCkRhOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YXBwcy1kaXNjdXNz LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmdd IFBlciBjb250byBkaSBHb256YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkpDQpJbnZpYXRvOiB2ZW5l cmTDrCA0IG1hZ2dpbyAyMDEyIDIxLjUwDQpBOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpDYzogb2F1 dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPjsgYXBwcy1kaXNjdXNzQGlldGYub3Jn PG1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmc+DQpPZ2dldHRvOiBSZTogW2FwcHMtZGlzY3Vz c10gZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXItMDQNCg0KSSBzdXBwb3J0IHRoaXMgZG9j IGJlaW5nIGFkb3B0ZWQgYXMgc3RhcnRpbmcgcG9pbnQgZm9yIFdHIGRpc2N1c3Npb24uDQpSZWdh cmRzLA0KDQpHb256YWxvDQoNCg0KT24gTWF5IDQsIDIwMTIsIGF0IDM6MDMgUE0sICJNdXJyYXkg Uy4gS3VjaGVyYXd5IiA8bXNrQGNsb3VkbWFyay5jb208bWFpbHRvOm1za0BjbG91ZG1hcmsuY29t Pj4gd3JvdGU6DQpUaGUgYWJvdmUtbmFtZWQgZHJhZnQgaGFzIGJlZW4gb2ZmZXJlZCBhcyB0aGUg cmVjb21tZW5kZWQgcGF0aCBmb3J3YXJkIGluIHRlcm1zIG9mIGNvbnZlcmdpbmcgb24gYSBzaW5n bGUgZG9jdW1lbnQgdG8gYWR2YW5jZSB0aHJvdWdoIGFwcHNhd2cuICBUaGUgY29udmVyc2F0aW9u IEkgc2F3IHRoaXMgd2VlayBpbiB0aGF0IHJlZ2FyZCBoYXMgc2VlbWVkIG1vc3RseSBwb3NpdGl2 ZS4NCg0KUGxlYXNlIHJldmlldyBpdCwgb3IgYXQgbGVhc3QgdGhlIGRpZmYsIGFuZCBpbmRpY2F0 ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9uIG9uIGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWls dG86YXBwcy1kaXNjdXNzQGlldGYub3JnPiB0byBhZG9wdGluZyB0aGlzIG9uZSBhcyB0aGUgY29t bW9uIHBhdGggZm9yd2FyZC4gV2Ugd291bGQgbGlrZSB0byBtYWtlIGEgZGVjaXNpb24gYWJvdXQg d2hpY2ggb25lIHRvIGJlZ2luIGFkdmFuY2luZyBpbiB0aGUgbmV4dCB3ZWVrIG9yIHR3by4NCg0K SGF2ZSBhIGdvb2Qgd2Vla2VuZCENCg0KLU1TSywgQVBQU0FXRyBjby1jaGFpcg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1h aWxpbmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3JnPG1haWx0bzphcHBzLWRpc2N1c3NAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vz cw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20102287DP3PWEX2MB008ex2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsbCB0aGUgaXNzdWVzIHJh aXNlZCBzaG91bGQgYmUgdGhlIHN0YXJ0aW5nIHBvaW50IGZvciBkaXNjdXNzaW9uIG9uIHRoaXMg YXMgYSBXRyBpdGVtLiBJIGRvIG5vdCB0aGluayBhbnkgb2YgdGhlbSBoYXMgYmVlbiByZXNvbHZl ZC4gVGhlIG9ubHkgcG9pbnQgaGVyZSBpcw0KIHRoYXQgd2UgaGF2ZSBhIHNpbmdsZSBkb2N1bWVu dCBmb3IgYSBzdGFydGluZyBwb2ludC4gVXNpbmcgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCByZWZs ZWN0IGFueSBjb25zZW5zdXMgb24gdGhlIGZpbmFsIHByb2R1Y3QuIFlvdXIgdGhyZWUgaXRlbXMg c2hvdWxkIGJlIGxpc3RlZCBpbiB0aGUgaXNzdWUgdHJhY2tlciBhcyBzb29uIGFzIHRoaXMgaGFz IHByb2dyZXNzZWQgZW5vdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RUg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Qmxh aW5lIENvb2s8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMDcsIDIwMTIgMTE6NDEgUE08 YnI+DQo8Yj5Ubzo8L2I+IFBhdWwgRS4gSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IGFwcHMtZGlzY3Vz c0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFthcHBz LWRpc2N1c3NdIFtPQVVUSC1XR10gUjogZHJhZnQtam9uZXMtYXBwc2F3Zy13ZWJmaW5nZXItMDQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5JIGRpc2FncmVlIHRoYXQgdGhlIGN1cnJlbnQg c3BlYyBpcyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgLSB0aGUgaXNzdWVzIEkndmUgcmFpc2VkIGhh dmUgYmVlbiBpZ25vcmVkLCBhbmQgdGhlIHNwZWMgaXMgbm93IG11Y2ggbW9yZSBjb21wbGljYXRl ZCBmcm9tIGJvdGggc2lkZXMgb2YgdGhlIGltcGxlbWVudGF0aW9uIGZlbmNlLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1heSA3LCAyMDEyIDM6MTcgUE0s ICZxdW90O1BhdWwgRS4gSm9uZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFj a2V0aXplci5jb20iPnBhdWxlakBwYWNrZXRpemVyLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldhbHRlciw8YnI+DQo8YnI+DQpJ J20gbm90IHN1cmUgd2hhdCB0aGUgZnVsbCBzZXQgb2YgaXNzdWVzIHdpbGwgYmUsIGJ1dCBJIG9u bHkgaGF2ZSBhIGNvdXBsZSBvZiBzbWFsbCBlZGl0cyBxdWV1ZWQgZm9yIC0wNSBhdCBwcmVzZW50 IChvbmUgYmVpbmcgJnF1b3Q7dGVtcGxhdGUmcXVvdDsgc2hvdWxkIGJlICZxdW90O2hyZWYmcXVv dDsgaW4gdGhlIGV4YW1wbGUgYXQgdGhlIGVuZCBvZiA0LjIgdGhhdCB5b3UgcG9pbnRlZCBvdXQg dG8gbWUgcHJpdmF0ZWx5KS4mbmJzcDsgV2UndmUgYWxyZWFkeSB3b3JrZWQgdGhyb3VnaA0KIGEg bnVtYmVyIG9mIGlzc3VlcyB0byBnZXQgdG8gdGhpcyBwb2ludCwgc28gdGhlcmUgbWF5IG5vdCBi ZSBhIGxvdCBvZiBjaGFuZ2VzIG5lZWRlZC4mbmJzcDsgSSdsbCBub3QgZGlzbWlzcyB0aGUgcG9z c2liaWxpdHkgdGhhdCB0aGVyZSBhcmUgZWRpdG9yaWFsIGlzc3VlcywgYnV0IEkgaG9wZSB3ZSd2 ZSByZXNvbHZlZCBtb3N0IG9mIHRoZSB0ZWNobmljYWwgZGV0YWlscy48YnI+DQo8YnI+DQpXZSBw cm9iYWJseSBzdGlsbCBuZWVkIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24gb2Yga2VlcGluZyBDT1JT IGFuZCB3aGF0IGFkZGl0aW9ucyBhcmUgbmVlZGVkIHRvIHRoZSBzZWN1cml0eSBzZWN0aW9uLiZu YnNwOyBXZSd2ZSBtYWRlIGEgZmV3IGNoYW5nZXMgdGhlcmUgYWxyZWFkeSwgYnV0IEknbSBub3Qg c3VyZSBpZiBpdCBzdGlsbCBmdWxseSBhZGRyZXNzZXMgc29tZSBvZiB0aGUgcHJpdmFjeSBjb25j ZXJucy48YnI+DQo8YnI+DQpQYXVsPGJyPg0KPGJyPg0KT24gNS83LzIwMTIgNTozNyBBTSwgR29p eCBMYXVyZW50IFdhbHRlciB3cm90ZTogPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhbHNvIHN1cHBvcnQg dGhpcyBkcmFmdCBhcyBhIHdheSBmb3J3YXJkIGZvciB0aGUgZGlzY3Vzc2lvbiB0aGF0IEkgdGhp bmsgY2FwdHVyZXMgdGhlIGVzc2VuY2Ugb2YgYm90aCBwaGlsb3NvcGhpZXMuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiBzdWNoIGJhc2lzIGlzIGFncmVlZCB3 aGF0IGFyZSB0aGUgbWFqb3IgcGVuZGluZyBpc3N1ZXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkxhdXJlbnQtd2FsdGVy PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJJVCI+ RGE6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJJVCI+DQo8YSBocmVmPSJtYWlsdG86YXBwcy1kaXNj dXNzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hcHBzLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5QZXIgY29udG8gZGkgPC9iPkdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSk8 YnI+DQo8Yj5JbnZpYXRvOjwvYj4gdmVuZXJkw6wgNCBtYWdnaW8gMjAxMiAyMS41MDxicj4NCjxi PkE6PC9iPiBNdXJyYXkgUy4gS3VjaGVyYXd5PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzphcHBzLWRpc2N1c3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmFw cHMtZGlzY3Vzc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5PZ2dldHRvOjwvYj4gUmU6IFthcHBzLWRp c2N1c3NdIGRyYWZ0LWpvbmVzLWFwcHNhd2ctd2ViZmluZ2VyLTA0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5JIHN1cHBvcnQgdGhpcyBkb2MgYmVp bmcgYWRvcHRlZCBhcyBzdGFydGluZyBwb2ludCBmb3IgV0cgZGlzY3Vzc2lvbi48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Hb256YWxvPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCk9uIE1heSA0LCAyMDEyLCBhdCAzOjAzIFBNLCAmcXVvdDtNdXJyYXkgUy4gS3VjaGVy YXd5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXNrQGNsb3VkbWFyay5jb20iIHRhcmdldD0i X2JsYW5rIj5tc2tAY2xvdWRtYXJrLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBhYm92ZS1uYW1lZCBk cmFmdCBoYXMgYmVlbiBvZmZlcmVkIGFzIHRoZSByZWNvbW1lbmRlZCBwYXRoIGZvcndhcmQgaW4g dGVybXMgb2YgY29udmVyZ2luZyBvbiBhIHNpbmdsZSBkb2N1bWVudCB0byBhZHZhbmNlIHRocm91 Z2ggYXBwc2F3Zy4mbmJzcDsgVGhlIGNvbnZlcnNhdGlvbiBJIHNhdyB0aGlzIHdlZWsNCiBpbiB0 aGF0IHJlZ2FyZCBoYXMgc2VlbWVkIG1vc3RseSBwb3NpdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlBsZWFzZSByZXZpZXcgaXQsIG9yIGF0IGxlYXN0IHRoZSBkaWZmLCBhbmQgaW5k aWNhdGUgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbiBvbg0KPGEgaHJlZj0ibWFpbHRvOmFwcHMt ZGlzY3Vzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFwcHMtZGlzY3Vzc0BpZXRmLm9yZzwv YT4gdG8gYWRvcHRpbmcgdGhpcyBvbmUgYXMgdGhlIGNvbW1vbiBwYXRoIGZvcndhcmQuIFdlIHdv dWxkIGxpa2UgdG8gbWFrZSBhIGRlY2lzaW9uIGFib3V0IHdoaWNoIG9uZSB0byBiZWdpbiBhZHZh bmNpbmcgaW4gdGhlIG5leHQgd2VlayBvciB0d28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IYXZlIGEgZ29vZCB3ZWVrZW5kITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LU1TSywg QVBQU0FXRyBjby1jaGFpcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCmFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YXBwcy1kaXNjdXNz QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYXBwcy1kaXNjdXNzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3M8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0CBAEB56DDB3A140BA8E8C124C04ECA20102287DP3PWEX2MB008ex2_-- From paulej@packetizer.com Tue May 8 01:25:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0D921F84E2; Tue, 8 May 2012 01:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBjz-i8Aq4OP; Tue, 8 May 2012 01:25:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5A321F84DD; Tue, 8 May 2012 01:25:33 -0700 (PDT) Received: from [156.106.244.190] ([156.106.244.190]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q488PRRx004538 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 8 May 2012 04:25:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1336465530; bh=RKm+3EoBhCv52J09nQLCmv9TUdlljICY+1q0GfMtyvo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=SMzgwwf9JdsOu6VrHbF+O2dWvDTblZBGrx0SoV1QC5wOuqlVwYzt1uGUg/WrKSmOR MRN+IblJd6hGkj/Xz2igj3x+sZlPcSIKs+PPPGMzqfXQce2JyIDIa7TqMganHFMwNV 5TW+W0m9v9NZFCTpfx3PlzrzD7bzGXcD/fI6vtrw= Message-ID: <4FA8D877.1040806@packetizer.com> Date: Tue, 08 May 2012 04:25:27 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Blaine Cook References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <4FA7CB3A.4020000@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090607020801010701060004" Cc: apps-discuss@ietf.org, "oauth@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] R: draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 08:25:34 -0000 This is a multi-part message in MIME format. --------------090607020801010701060004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Blaine, Your issues were not ignored, but I do not think there was consensus one way or the other on them. Your points were: 1) Recommendation to use JSON only 2) A question about what the JSON format would look like 3) Direct vs. indirect queries (i.e., whether to use resource parameter) I replied to each of these and others commented on parts, too. My opinions: 1) Given that RFC 6415 already specifies use of XML and is only months old, I hesitate to demand that only XML be used. Further, it's trivial for the server to do both. The client will be able to use whatever it prefers. I can be convinced to drop XML, but I think we should make this decision carefully and with everyone in agreement. 2) I suggested we use JRD since it is defined. Was there any disagreement on that? 3) This issue is a point where there was clear division. The OpenID Connect team wants to be able to issue a single query and get a reply. You had an interest to use a static server. I investigated how we could do both. If one used Apache, for example, one could build a static site and still support the resource URI. Here's a couple of ways to do it: http://www.packetizer.com/webfinger/server.html (using either .htaccess or the global config file). What cannot be accomodated is the "rel" parameter, but I'd guess static sites will not produce voluminous results, anyway. So, it's not accurate to say your issues were ignored. We simply did not have strong consensus one way or the other. There were strong opinions on (3), so I tried to find a solution that might be acceptable. We may need more discussion on all of these points, of course. Paul On 5/8/2012 2:40 AM, Blaine Cook wrote: > > I disagree that the current spec is a good starting point - the issues > I've raised have been ignored, and the spec is now much more > complicated from both sides of the implementation fence. > > On May 7, 2012 3:17 PM, "Paul E. Jones" > wrote: > > Walter, > > I'm not sure what the full set of issues will be, but I only have > a couple of small edits queued for -05 at present (one being > "template" should be "href" in the example at the end of 4.2 that > you pointed out to me privately). We've already worked through a > number of issues to get to this point, so there may not be a lot > of changes needed. I'll not dismiss the possibility that there > are editorial issues, but I hope we've resolved most of the > technical details. > > We probably still need to have the discussion of keeping CORS and > what additions are needed to the security section. We've made a > few changes there already, but I'm not sure if it still fully > addresses some of the privacy concerns. > > Paul > > On 5/7/2012 5:37 AM, Goix Laurent Walter wrote: >> >> I also support this draft as a way forward for the discussion >> that I think captures the essence of both philosophies. >> >> If such basis is agreed what are the major pending issues? >> >> Regards >> >> Laurent-walter >> >> *Da:*apps-discuss-bounces@ietf.org >> >> [mailto:apps-discuss-bounces@ietf.org] *Per conto di *Gonzalo >> Salgueiro (gsalguei) >> *Inviato:* venerdì 4 maggio 2012 21.50 >> *A:* Murray S. Kucherawy >> *Cc:* oauth@ietf.org ; >> apps-discuss@ietf.org >> *Oggetto:* Re: [apps-discuss] draft-jones-appsawg-webfinger-04 >> >> I support this doc being adopted as starting point for WG discussion. >> >> Regards, >> >> Gonzalo >> >> >> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" >> > wrote: >> >> The above-named draft has been offered as the recommended >> path forward in terms of converging on a single document to >> advance through appsawg. The conversation I saw this week in >> that regard has seemed mostly positive. >> >> Please review it, or at least the diff, and indicate your >> support or objection on apps-discuss@ietf.org >> to adopting this one as the >> common path forward. We would like to make a decision about >> which one to begin advancing in the next week or two. >> >> Have a good weekend! >> >> -MSK, APPSAWG co-chair >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090607020801010701060004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit  Blaine,

Your issues were not ignored, but I do not think there was consensus one way or the other on them.  Your points were:
1) Recommendation to use JSON only
2) A question about what the JSON format would look like
3) Direct vs. indirect queries (i.e., whether to use resource parameter)

I replied to each of these and others commented on parts, too.  My opinions:

1) Given that RFC 6415 already specifies use of XML and is only months old, I hesitate to demand that only XML be used.  Further, it's trivial for the server to do both.  The client will be able to use whatever it prefers.  I can be convinced to drop XML, but I think we should make this decision carefully and with everyone in agreement.
2) I suggested we use JRD since it is defined.  Was there any disagreement on that?
3) This issue is a point where there was clear division.  The OpenID Connect team wants to be able to issue a single query and get a reply.  You had an interest to use a static server.  I investigated how we could do both.  If one used Apache, for example, one could build a static site and still support the resource URI.  Here's a couple of ways to do it: http://www.packetizer.com/webfinger/server.html (using either .htaccess or the global config file).  What cannot be accomodated is the "rel" parameter, but I'd guess static sites will not produce voluminous results, anyway.

So, it's not accurate to say your issues were ignored.  We simply did not have strong consensus one way or the other.  There were strong opinions on (3), so I tried to find a solution that might be acceptable.  We may need more discussion on all of these points, of course.

Paul

On 5/8/2012 2:40 AM, Blaine Cook wrote:

I disagree that the current spec is a good starting point - the issues I've raised have been ignored, and the spec is now much more complicated from both sides of the implementation fence.

On May 7, 2012 3:17 PM, "Paul E. Jones" <paulej@packetizer.com> wrote:
Walter,

I'm not sure what the full set of issues will be, but I only have a couple of small edits queued for -05 at present (one being "template" should be "href" in the example at the end of 4.2 that you pointed out to me privately).  We've already worked through a number of issues to get to this point, so there may not be a lot of changes needed.  I'll not dismiss the possibility that there are editorial issues, but I hope we've resolved most of the technical details.

We probably still need to have the discussion of keeping CORS and what additions are needed to the security section.  We've made a few changes there already, but I'm not sure if it still fully addresses some of the privacy concerns.

Paul

On 5/7/2012 5:37 AM, Goix Laurent Walter wrote:

I also support this draft as a way forward for the discussion that I think captures the essence of both philosophies.

 

If such basis is agreed what are the major pending issues?

 

Regards

Laurent-walter

 

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto di Gonzalo Salgueiro (gsalguei)
Inviato: venerdì 4 maggio 2012 21.50
A: Murray S. Kucherawy
Cc: oauth@ietf.org; apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] draft-jones-appsawg-webfinger-04

 

I support this doc being adopted as starting point for WG discussion.

Regards,

 

Gonzalo

 


On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" <msk@cloudmark.com> wrote:

The above-named draft has been offered as the recommended path forward in terms of converging on a single document to advance through appsawg.  The conversation I saw this week in that regard has seemed mostly positive.

 

Please review it, or at least the diff, and indicate your support or objection on apps-discuss@ietf.org to adopting this one as the common path forward. We would like to make a decision about which one to begin advancing in the next week or two.

 

Have a good weekend!

 

-MSK, APPSAWG co-chair

 

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------090607020801010701060004-- From stephen.farrell@cs.tcd.ie Tue May 8 02:44:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A35221F84C9 for ; Tue, 8 May 2012 02:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN9phJaN6mO3 for ; Tue, 8 May 2012 02:44:44 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6078021F84B8 for ; Tue, 8 May 2012 02:44:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D3188171622; Tue, 8 May 2012 10:44:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1336470282; bh=hRgqQogiG6BK2w mlSy2NxRrHuo/8o9bTZKX4uKl+Fbs=; b=Ws5N5i6a44UoJwBvIFmRuqNlpFCKWA qQXKNgP3QSJQ6WrjsAnZqzZ+/xGArMoHYCaN9AQTumshdGBpJKTuTv8WwWdPTJdl PYkMMZgggTWdXsRLqjOclyRZG9XSLqS+nTx2vy6RkSA4yA938XbR+rLcwxlP7Tns StniwmvKtVpGuJEK1+PK89LzUGudI1d7U/2fTQBQwzyiFrc7yt4z4uOQbHkMuXSg OJe9Jg0q2hMBIbmE/a5/c5V3CMeRagfJiLhdPV2C3EVWBndg/NK0XoFLCo/75Oj/ m7G2Zk5NcaNNpo6fyTI9sxUEB/7qvjbxRDE8C7zJAf0SV8G3BB1MGidA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id E49SkgyFpmxV; Tue, 8 May 2012 10:44:42 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 26D7B17161E; Tue, 8 May 2012 10:44:37 +0100 (IST) Message-ID: <4FA8EB06.4020004@cs.tcd.ie> Date: Tue, 08 May 2012 10:44:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Martin Thomson References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> <4FA68A60.6030207@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F28540B5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 09:44:45 -0000 On 05/07/2012 04:56 PM, Martin Thomson wrote: >> I would still rather ditch the truncation length from the alg names. > > I'm with James on this one. Concerns about checking too-short hashes > don't seem so serious. After all, the incentive is with the client to > check as much of the hash as they can. Thus, the only concern is if > an attacker can force a shorter hash somehow. The example of a > truncated stream cipher seems contrived to me. Not to me. I think that omitting the size would mean that anyone using these would need to go think about potential truncation attacks, and having to do that is bad, since most times they won't do it at all and even if they do, those attacks, if they apply, will be likely be very subtle. So even if you try figure it out, you may not get the analysis right. Avoiding all that is just better IMO. I also think that limiting the available truncation options will make it (a bit) more likely that people won't truncate when they don't need to. Maybe the text on that ought be tightened up though, e.g. to say that you SHOULD use full length hashes unless you have a real reason why you need to truncate. Happy to take suggestions there. Additionally, if we took out the length then we'd have to figure whether or not (or when, yuk) ni:///sha-256;abc is the "same" as ni:///sha-256;abcdef and even if we declare that its never the same, that's something people are liable to get wrong, since sometimes both would actually refer to the same thing. Yuk yuk yuk;-) S. From fanf2@hermes.cam.ac.uk Tue May 8 04:51:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C3C21F84FF; Tue, 8 May 2012 04:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9kvF-m21a9I; Tue, 8 May 2012 04:51:17 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id D11A521F84F8; Tue, 8 May 2012 04:51:16 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44718) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SRiwj-0001gx-Wj (Exim 4.72) (return-path ); Tue, 08 May 2012 12:51:13 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SRiwj-0007fs-4H (Exim 4.67) (return-path ); Tue, 08 May 2012 12:51:13 +0100 Date: Tue, 8 May 2012 12:51:13 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Andrew Sullivan In-Reply-To: <20120507151257.GH8963@mail.yitter.info> Message-ID: References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> <20120507151257.GH8963@mail.yitter.info> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG list , Paul Hoffman , "apps-discuss@ietf.org Discuss" , The IESG Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 11:51:19 -0000 Andrew Sullivan wrote: > > 3. The base domain name is appended to the result of step 2 to > complete the prepared domain name. The base domain name is the > fully-qualified DNS domain name [RFC1035] of the TLS server, > with the additional restriction that every label must meet the > rules of [RFC952]. The latter restriction means that, if the > query is for an internationalized domain name, it must use the > A-label form as defined in [RFC5890]. I like this. Tony. -- f.anthony.n.finch http://dotat.at/ Sole: Variable 4 in east at first, otherwise northeasterly 5 to 7. Moderate or rough. Occasional rain. Moderate or good. From stpeter@stpeter.im Tue May 8 05:39:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C525821F8549; Tue, 8 May 2012 05:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwgyzJfYaD-8; Tue, 8 May 2012 05:39:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52321F84C5; Tue, 8 May 2012 05:39:01 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5CA2B40058; Tue, 8 May 2012 06:54:18 -0600 (MDT) Message-ID: <4FA913E2.6050302@stpeter.im> Date: Tue, 08 May 2012 06:38:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tony Finch References: <20120504220713.GR7394@crankycanuck.ca> <201205042224.q44MOo03029933@fs4113.wdf.sap.corp> <20120504223816.GV7394@crankycanuck.ca> <1EF0ACEE-52ED-4BDE-BF34-C995F117783D@vpnc.org> <20120507151257.GH8963@mail.yitter.info> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org Discuss" , Paul Hoffman , IETF DANE WG list Subject: Re: [apps-discuss] [dane] AppsDir review of X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 12:39:03 -0000 On 5/8/12 5:51 AM, Tony Finch wrote: > Andrew Sullivan wrote: >> >> 3. The base domain name is appended to the result of step 2 to >> complete the prepared domain name. The base domain name is the >> fully-qualified DNS domain name [RFC1035] of the TLS server, >> with the additional restriction that every label must meet the >> rules of [RFC952]. The latter restriction means that, if the >> query is for an internationalized domain name, it must use the >> A-label form as defined in [RFC5890]. > > I like this. WFM. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba.mailing.lists@gmail.com Tue May 8 07:06:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E258021F8617 for ; Tue, 8 May 2012 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3XN3exK6n80 for ; Tue, 8 May 2012 07:06:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF25A21F84D3 for ; Tue, 8 May 2012 07:06:31 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4841671lbb.31 for ; Tue, 08 May 2012 07:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=GdLj/F719canDdn+43h1DZdt+eH/nal0ba9pgvrUWpY=; b=PvJKzXSGJeSqFvMpFUpoBXnrufZcIF8DXfP9UQq2y1id89nA/PAn7kN/DzqKi1zeRQ snPq/9z0cp2y8XmKPNNOCqfSP8qq80zOZGvwjSgzaMWzvqmtVoAwNvbfpzm1b4SVDnYX PP6nfDjjZDwXyeNYehXHBxVCeScmeoDd1qogMHTrUJSsMpSvJp8/GMhEA5L7nxkQ8lwW ivGRQ3carqTAWhBV/1ieEHc7LA9D7UUbh5TZ6Z45FvgBcWe2HVXnslXhT2qarWrEMoOn zjtKjAKtx64nM2TvNdUIbi+UXFqpSizVxhPSMsdWtMzv9G0DCv/i9uqNXxFoV//UZdo4 jGzQ== MIME-Version: 1.0 Received: by 10.152.105.19 with SMTP id gi19mr18074933lab.11.1336485990750; Tue, 08 May 2012 07:06:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.7.7 with HTTP; Tue, 8 May 2012 07:06:30 -0700 (PDT) In-Reply-To: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> Date: Tue, 8 May 2012 10:06:30 -0400 X-Google-Sender-Auth: C3YYRn0X-CrGLJ5lh7WX666Cnas Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Last Call: (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:06:33 -0000 > Abstract > =A0 This document changes RFC 2046 rules regarding default charset > =A0 parameter values for text/* media types to better align with common > =A0 usage by existing clients and servers. ... > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/b= allot/ This document sailed through IETF last call with no comments, but something has come up in IESG evaluation -- Robert chatted with me about this, and I suggested that he put a DISCUSS ballot in until we resolve it. The document makes it very clear that "existing registrations" are not affected (and therefore retain their RFC 2046 default of US-ASCII for charset). But how does someone TELL that a subtype is "existing"? Chasing documentation pointers and checking dates is not a reasonable way. Five years from now, when 60 more text subtypes have been added to the 60 that are there, how will anyone know *which* of those 120 are affected by this spec and which are not? Further, both (a) and (b) in section 3 are things that SHOULD be done; what if a new registration does neither, violating both SHOULDs? How will someone know what its default is? I think the right way to fix this is to put new text in near the end of section 3, just to make things absolutely clear: -------- OLD New subtypes of the "text" media type, thus, SHOULD NOT define a default "charset" value. If there is a strong reason to do so despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as the default. NEW New subtypes of the "text" media type, thus, SHOULD NOT define a default "charset" value. If there is a strong reason to do so despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as the default. To maintain compatibility with existing registrations, this fallback rule applies: any subtype of the "text" media type that does not comply with the rules above retains US-ASCII as its default, as originally specified in RFC 2046. -------- The document editors are OK with this text, but we want to pass it by the working group for comment. Does anyone object to this suggestion? Does anyone think the issue should be addressed differently? Barry, Applications AD From hannes.tschofenig@gmx.net Tue May 8 07:55:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5932721F8658 for ; Tue, 8 May 2012 07:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsLsCdgYECji for ; Tue, 8 May 2012 07:55:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5348121F8648 for ; Tue, 8 May 2012 07:55:14 -0700 (PDT) Received: (qmail invoked by alias); 08 May 2012 14:55:12 -0000 Received: from unknown (EHLO dhcp50-94-118-50.hil-dcaaedt.dca.wayport.net) [65.89.200.2] by mail.gmx.net (mp032) with SMTP; 08 May 2012 16:55:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19CNEw774lCiM02z77/BCAeYv4Yx5gExuXcDTIw0S KwSwameQBg7VTw Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> Date: Tue, 8 May 2012 17:55:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7C8C2724-8BB3-4B45-9144-D2645E3D0B4D@gmx.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 14:55:15 -0000 Hi Murray,=20 it is great to see that you are pushing things forward here but I = believe you are going a bit too fast.=20 =46rom the comments I have seen so far I got the impression that many = got confused by UR schemes: mailto: and the acct: are different.=20 The discussions around XML vs. JSON are unfortunately also hiding the = real important discussion, namely privacy.=20 We are actually building, without further thinking about it, a mechanism = that offers worse privacy properties compared to what we have in other = protocols today. See this in terms of the interaction between a relying party and an = identity provider then other IETF protocols today (e.g., AAA) does not = require the relying party to see the username part of the identifier. In = fact AAA offers various mechanisms to hide the username component to the = relying party since it is really only needed by the identity provider. So, I would encourage the group to think about how to accomplish = equivalent functionality without unnecessarily revealing identifiers to = parties that are not supposed to get them. I also think it is useful to think about the bigger picture,namely the = integration with other protocols (such as OAuth). This will in most = cases be needed when you actually fetch the data that is behind the = discovered URIs. Assuming that all information is public anyway is not = realistic and protocol design has to work with the difficult assumptions = (not with the simplest). Furthermore, the usage of CORS is completely = confused in the document.=20 Hence, I heavily object to use this document as a starting point.=20 I may also be the case that WebFinger is not the right tool for = something like OAuth (and for discovery of protected resources = altogether) since we do not want to design a solution that on one hand = allows us not to reveal any user identifiers to the relying party (the = client in OAuth) based on the current design and then completely destroy = these properties when we add the discovery mechanisms in front of it.=20 Ciao Hannes PS: I met some W3C folks last week and they mentioned that we should = also take a look at Web Intents. I have not done that yet and do not = know how suitable the W3C developed mechanisms therefore is.=20 On May 4, 2012, at 8:31 PM, Murray S. Kucherawy wrote: > The above-named draft has been offered as the recommended path forward = in terms of converging on a single document to advance through appsawg. = The conversation I saw this week in that regard has seemed mostly = positive. > =20 > Please review it, or at least the diff, and indicate your support or = objection on apps-discuss@ietf.org to adopting this one as the common = path forward. We would like to make a decision about which one to begin = advancing in the next week or two. > =20 > Have a good weekend! > =20 > -MSK, APPSAWG co-chair > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Tue May 8 08:02:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31EC11E8081 for ; Tue, 8 May 2012 08:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBQfzP2J6UFg for ; Tue, 8 May 2012 08:02:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D623711E8080 for ; Tue, 8 May 2012 08:02:32 -0700 (PDT) Received: (qmail invoked by alias); 08 May 2012 14:55:52 -0000 Received: from unknown (EHLO dhcp50-94-118-50.hil-dcaaedt.dca.wayport.net) [65.89.200.2] by mail.gmx.net (mp032) with SMTP; 08 May 2012 16:55:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/o1wErNwbom7qxnhY18+9d01vzOiucorUk3EZBiF gdcndorvwRlXyz Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> Date: Tue, 8 May 2012 17:55:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> To: Gonzalo Salgueiro (gsalguei) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:02:34 -0000 Gonzalo: it is great that you, as a co-author, support your own document = but I don't think it is particular helpful.=20 On May 4, 2012, at 10:49 PM, Gonzalo Salgueiro (gsalguei) wrote: > I support this doc being adopted as starting point for WG discussion. >=20 > Regards, >=20 > Gonzalo >=20 >=20 > On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" = wrote: >=20 >> The above-named draft has been offered as the recommended path = forward in terms of converging on a single document to advance through = appsawg. The conversation I saw this week in that regard has seemed = mostly positive. >> =20 >> Please review it, or at least the diff, and indicate your support or = objection on apps-discuss@ietf.org to adopting this one as the common = path forward. We would like to make a decision about which one to begin = advancing in the next week or two. >> =20 >> Have a good weekend! >> =20 >> -MSK, APPSAWG co-chair >> =20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From eran@hueniverse.com Tue May 8 08:03:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFB811E8087 for ; Tue, 8 May 2012 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK7CTVLGr3xX for ; Tue, 8 May 2012 08:03:52 -0700 (PDT) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2395511E807F for ; Tue, 8 May 2012 08:03:52 -0700 (PDT) Received: from P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id 7T3r1j00B0Dcg9U01T3r7G; Tue, 08 May 2012 08:03:51 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT002.ex2.secureserver.net ([184.168.131.10]) with mapi id 14.02.0247.003; Tue, 8 May 2012 08:03:51 -0700 From: Eran Hammer To: Hannes Tschofenig , Gonzalo Salgueiro Thread-Topic: [OAUTH-WG] [apps-discuss] draft-jones-appsawg-webfinger-04 Thread-Index: AQHNLSulZUNxyoIHCEGy9bqFghgqtpa//Q2Q Date: Tue, 8 May 2012 15:03:51 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:03:52 -0000 Neither was this comment. EH > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Tuesday, May 08, 2012 7:56 AM > To: Gonzalo Salgueiro > Cc: oauth@ietf.org; apps-discuss@ietf.org > Subject: Re: [OAUTH-WG] [apps-discuss] draft-jones-appsawg-webfinger-04 >=20 > Gonzalo: it is great that you, as a co-author, support your own document = but > I don't think it is particular helpful. >=20 > On May 4, 2012, at 10:49 PM, Gonzalo Salgueiro (gsalguei) wrote: >=20 > > I support this doc being adopted as starting point for WG discussion. > > > > Regards, > > > > Gonzalo > > > > > > On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" > wrote: > > > >> The above-named draft has been offered as the recommended path > forward in terms of converging on a single document to advance through > appsawg. The conversation I saw this week in that regard has seemed > mostly positive. > >> > >> Please review it, or at least the diff, and indicate your support or o= bjection > on apps-discuss@ietf.org to adopting this one as the common path forward. > We would like to make a decision about which one to begin advancing in th= e > next week or two. > >> > >> Have a good weekend! > >> > >> -MSK, APPSAWG co-chair > >> > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From romeda@gmail.com Tue May 8 08:16:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5753411E807F for ; Tue, 8 May 2012 08:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khv3NegVH0QR for ; Tue, 8 May 2012 08:16:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A96B821F84D5 for ; Tue, 8 May 2012 08:16:57 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4906994lbb.31 for ; Tue, 08 May 2012 08:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=RDO8eI5usIhFsZQgGdV8zK2f/TRMoLOmp22ie5ZMAQM=; b=XrSQqeAQLb1OmG+cELEMJAhku67DSJiazB7h1j/wKc6nNAD83VCLqovLDllTgb6YNq 8S/4G7qGJLkbZgDaqIYmDOvrDMlvisLJmC59s180mevSu5NRCM/9QAfKx//ip55HkXGt aInhBgVampzS5awj8IxUOr++5Q9cp1moyVymMTR5ILK5lmLiQSxoZLRgzJRsSSEBXdQl L452wnFpLudYxJMvFf1KA0+UZuGKnAhimW1TXIV6OYNv9QCuf0/14r+gieDDsWM7MDYx R02k/p/LI0zenB1o1SIl0g8SQ7dmJ/EFnlkPGz7CJbYcsSgNRpfo+bNfCKMLrJnFP/9r apvA== Received: by 10.112.87.69 with SMTP id v5mr595437lbz.49.1336490216468; Tue, 08 May 2012 08:16:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.24.229 with HTTP; Tue, 8 May 2012 08:16:36 -0700 (PDT) In-Reply-To: <4FA8D877.1040806@packetizer.com> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <4FA7CB3A.4020000@packetizer.com> <4FA8D877.1040806@packetizer.com> From: Blaine Cook Date: Tue, 8 May 2012 17:16:36 +0200 Message-ID: To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] [OAUTH-WG] R: draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:16:59 -0000 I just meant that my comments aren't reflected in the document, not that they were ignored completely. I'm not sure what the difference is between this process and the one that comes next, but I trust that various concerns will be addressed. b. On 8 May 2012 10:25, Paul E. Jones wrote: > =C2=A0Blaine, > > Your issues were not ignored, but I do not think there was consensus one = way > or the other on them.=C2=A0 Your points were: > 1) Recommendation to use JSON only > 2) A question about what the JSON format would look like > 3) Direct vs. indirect queries (i.e., whether to use resource parameter) > > I replied to each of these and others commented on parts, too.=C2=A0 My o= pinions: > > 1) Given that RFC 6415 already specifies use of XML and is only months ol= d, > I hesitate to demand that only XML be used.=C2=A0 Further, it's trivial f= or the > server to do both.=C2=A0 The client will be able to use whatever it prefe= rs.=C2=A0 I > can be convinced to drop XML, but I think we should make this decision > carefully and with everyone in agreement. > 2) I suggested we use JRD since it is defined.=C2=A0 Was there any disagr= eement > on that? > 3) This issue is a point where there was clear division.=C2=A0 The OpenID= Connect > team wants to be able to issue a single query and get a reply.=C2=A0 You = had an > interest to use a static server.=C2=A0 I investigated how we could do bot= h.=C2=A0 If > one used Apache, for example, one could build a static site and still > support the resource URI.=C2=A0 Here's a couple of ways to do it: > http://www.packetizer.com/webfinger/server.html (using either .htaccess o= r > the global config file).=C2=A0 What cannot be accomodated is the "rel" pa= rameter, > but I'd guess static sites will not produce voluminous results, anyway. > > So, it's not accurate to say your issues were ignored.=C2=A0 We simply di= d not > have strong consensus one way or the other.=C2=A0 There were strong opini= ons on > (3), so I tried to find a solution that might be acceptable.=C2=A0 We may= need > more discussion on all of these points, of course. > > Paul > > > On 5/8/2012 2:40 AM, Blaine Cook wrote: > > I disagree that the current spec is a good starting point - the issues I'= ve > raised have been ignored, and the spec is now much more complicated from > both sides of the implementation fence. > > On May 7, 2012 3:17 PM, "Paul E. Jones" wrote: >> >> Walter, >> >> I'm not sure what the full set of issues will be, but I only have a coup= le >> of small edits queued for -05 at present (one being "template" should be >> "href" in the example at the end of 4.2 that you pointed out to me >> privately).=C2=A0 We've already worked through a number of issues to get= to this >> point, so there may not be a lot of changes needed.=C2=A0 I'll not dismi= ss the >> possibility that there are editorial issues, but I hope we've resolved m= ost >> of the technical details. >> >> We probably still need to have the discussion of keeping CORS and what >> additions are needed to the security section.=C2=A0 We've made a few cha= nges >> there already, but I'm not sure if it still fully addresses some of the >> privacy concerns. >> >> Paul >> >> On 5/7/2012 5:37 AM, Goix Laurent Walter wrote: >> >> I also support this draft as a way forward for the discussion that I thi= nk >> captures the essence of both philosophies. >> >> >> >> If such basis is agreed what are the major pending issues? >> >> >> >> Regards >> >> Laurent-walter >> >> >> >> Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >> Per conto di Gonzalo Salgueiro (gsalguei) >> Inviato: venerd=C3=AC 4 maggio 2012 21.50 >> A: Murray S. Kucherawy >> Cc: oauth@ietf.org; apps-discuss@ietf.org >> Oggetto: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 >> >> >> >> I support this doc being adopted as starting point for WG discussion. >> >> Regards, >> >> >> >> Gonzalo >> >> >> >> >> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" >> wrote: >> >> The above-named draft has been offered as the recommended path forward i= n >> terms of converging on a single document to advance through appsawg.=C2= =A0 The >> conversation I saw this week in that regard has seemed mostly positive. >> >> >> >> Please review it, or at least the diff, and indicate your support or >> objection on apps-discuss@ietf.org to adopting this one as the common pa= th >> forward. We would like to make a decision about which one to begin advan= cing >> in the next week or two. >> >> >> >> Have a good weekend! >> >> >> >> -MSK, APPSAWG co-chair >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From hannes.tschofenig@gmx.net Tue May 8 08:23:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228EA21F8551 for ; Tue, 8 May 2012 08:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWsABIOcippf for ; Tue, 8 May 2012 08:23:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1FD2F21F8533 for ; Tue, 8 May 2012 08:23:10 -0700 (PDT) Received: (qmail invoked by alias); 08 May 2012 15:23:08 -0000 Received: from unknown (EHLO dhcp50-94-118-50.hil-dcaaedt.dca.wayport.net) [65.89.200.2] by mail.gmx.net (mp031) with SMTP; 08 May 2012 17:23:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19xY+4f6/pxvzn26Lg7ywwGxgBhNibGqdJB8gcbjP 7antsTgdBOex9e Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> Date: Tue, 8 May 2012 18:23:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> To: Eran Hammer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:23:12 -0000 So, you think it is a good practice if the authors + their co-workers = indicate support for their own documents? On May 8, 2012, at 6:03 PM, Eran Hammer wrote: > Neither was this comment. >=20 > EH >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Hannes Tschofenig >> Sent: Tuesday, May 08, 2012 7:56 AM >> To: Gonzalo Salgueiro >> Cc: oauth@ietf.org; apps-discuss@ietf.org >> Subject: Re: [OAUTH-WG] [apps-discuss] = draft-jones-appsawg-webfinger-04 >>=20 >> Gonzalo: it is great that you, as a co-author, support your own = document but >> I don't think it is particular helpful. >>=20 >> On May 4, 2012, at 10:49 PM, Gonzalo Salgueiro (gsalguei) wrote: >>=20 >>> I support this doc being adopted as starting point for WG = discussion. >>>=20 >>> Regards, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" >> wrote: >>>=20 >>>> The above-named draft has been offered as the recommended path >> forward in terms of converging on a single document to advance = through >> appsawg. The conversation I saw this week in that regard has seemed >> mostly positive. >>>>=20 >>>> Please review it, or at least the diff, and indicate your support = or objection >> on apps-discuss@ietf.org to adopting this one as the common path = forward. >> We would like to make a decision about which one to begin advancing = in the >> next week or two. >>>>=20 >>>> Have a good weekend! >>>>=20 >>>> -MSK, APPSAWG co-chair >>>>=20 >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From romeda@gmail.com Tue May 8 08:31:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01311E8091; Tue, 8 May 2012 08:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4M-DfH1QVDz; Tue, 8 May 2012 08:31:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C86811E808A; Tue, 8 May 2012 08:31:13 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4919773lbb.31 for ; Tue, 08 May 2012 08:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=RnZKTFAxjVbXrxPaJo9ZD9KrZotICYYqotJX6EXBh2I=; b=dpAaGhD//YjUMNQtty4rGmHsH06gW2npt5qeaccUFtqSM6yMqmhfS9h03A1FBd4pgF WqxdMIFuYE0AACa+kYZPgqT+MqqWQuI6ldHjWzvqyeUhZLnqUhEnTv72eRzHl2tq9Rlt WgdgLenx/OL1PwBHz2shndcywL1TK0TILNKzDFEZgnx1qpS5mFPxdLYtMrpkykqh61aP h8CSp3N0gV5PcGmQ5RP9zDw6JlQBYWERqUofc3envKRQVF/UhMT90PCimeH+RPTu+stk PVe7vMhvGF/sslyBEyUkRyPAt/ri4nam9tTVRN72hn0o7B+rQBX2m0+6Ib2bAj8ELKd4 Ju/g== Received: by 10.152.109.198 with SMTP id hu6mr2605109lab.21.1336491072259; Tue, 08 May 2012 08:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.24.229 with HTTP; Tue, 8 May 2012 08:30:52 -0700 (PDT) In-Reply-To: <7C8C2724-8BB3-4B45-9144-D2645E3D0B4D@gmx.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <7C8C2724-8BB3-4B45-9144-D2645E3D0B4D@gmx.net> From: Blaine Cook Date: Tue, 8 May 2012 17:30:52 +0200 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org WG" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:31:14 -0000 On 8 May 2012 16:55, Hannes Tschofenig wrote: > The discussions around XML vs. JSON are unfortunately also hiding the rea= l important discussion, namely privacy. > > We are actually building, without further thinking about it, a mechanism = that offers worse privacy properties compared to what we have in other prot= ocols today. > > See this in terms of the interaction between a relying party and an ident= ity provider then other IETF protocols today (e.g., AAA) does not require t= he relying party to see the username part of the identifier. In fact AAA of= fers various mechanisms to hide the username component to the relying party= since it is really only needed by the identity provider. > > So, I would encourage the group to think about how to accomplish equivale= nt functionality without unnecessarily revealing identifiers to parties tha= t are not supposed to get them. Webfinger isn't about authentication. It is *explicitly* about discovering information about an entity (usually a person) when you (the relying party) *already have* their identifier. Again: There is NO privacy leak in exposing the identifier to the RP, because they already know it. Again: There is NO privacy leak in exposing the identifier to the SP, because they control it. Even in the context of authentication, I'm surprised you're saying this because I've repeatedly claimed that the *major failing* with OpenID *.* is that the relying party isn't given knowledge of *who* is trying to authenticate in the first place. It's a cryptographic property that looks lovely on paper, but is a damaging folly when translated to something that end users are expected to interact with. > I also think it is useful to think about the bigger picture,namely the in= tegration with other protocols (such as OAuth). This will in most cases be = needed when you actually fetch the data that is behind the discovered URIs.= Assuming that all information is public anyway is not realistic and protoc= ol design has to work with the difficult assumptions (not with the simplest= ). Agreed, the actual information conveyed by Webfinger will normally be private. *However*, as discussed on this list, on the OAuth list, and in many other places, the mechanism(s) for authentication and authorisation to access the relevant Webfinger profiles is best dealt with by allowing any valid HTTP mechanisms. Specific protocols that rely upon webfinger should define their own authentication requirements, where sensible. > Hence, I heavily object to use this document as a starting point. I have many concerns with this document, too, as mentioned earlier. > I may also be the case that WebFinger is not the right tool for something= like OAuth (and for discovery of protected resources altogether) since we = do not want to design a solution that on one hand allows us not to reveal a= ny user identifiers to the relying party (the client in OAuth) based on the= current design and then completely destroy these properties when we add th= e discovery mechanisms in front of it. No-one is forcing all OAuth services to rely upon webfinger discovery. OpenID Connect needs something like this, because users (and their RPs in turn) need to know their identifier in order to be able to sign in. Some RPs that interact with OAuth-enabled services (e.g., cloud document services) will benefit from webfinger. Others won't, especially where the RP shouldn't or can't know who the user is, but should have access to a service. FWIW, I think you're blowing the privacy concerns way out of proportion, especially in the context of a world where many actively hostile actors can identify users by analysing router traffic that they obtain from back-doors in switches manufactured by Ericsson. ;-) b. From stpeter@stpeter.im Tue May 8 08:31:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A0621F85CF for ; Tue, 8 May 2012 08:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQhNfuqZeQuN for ; Tue, 8 May 2012 08:31:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4A39221F85CE for ; Tue, 8 May 2012 08:31:40 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 536834005B; Tue, 8 May 2012 09:46:57 -0600 (MDT) Message-ID: <4FA93C5A.1020708@stpeter.im> Date: Tue, 08 May 2012 09:31:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Blaine Cook References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <4FA7CB3A.4020000@packetizer.com> <4FA8D877.1040806@packetizer.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] R: draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:31:41 -0000 Hi Blaine, The question is: "do we think that draft-jones-appsawg-webfinger-04 will provide a good starting point for a solution to this problem?" I too have feedback and concerns that I shall raise if this working group decides that this Internet-Draft is a good starting point. Peter On 5/8/12 9:16 AM, Blaine Cook wrote: > I just meant that my comments aren't reflected in the document, not > that they were ignored completely. I'm not sure what the difference is > between this process and the one that comes next, but I trust that > various concerns will be addressed. > > b. > > On 8 May 2012 10:25, Paul E. Jones wrote: >> Blaine, >> >> Your issues were not ignored, but I do not think there was consensus one way >> or the other on them. Your points were: >> 1) Recommendation to use JSON only >> 2) A question about what the JSON format would look like >> 3) Direct vs. indirect queries (i.e., whether to use resource parameter) >> >> I replied to each of these and others commented on parts, too. My opinions: >> >> 1) Given that RFC 6415 already specifies use of XML and is only months old, >> I hesitate to demand that only XML be used. Further, it's trivial for the >> server to do both. The client will be able to use whatever it prefers. I >> can be convinced to drop XML, but I think we should make this decision >> carefully and with everyone in agreement. >> 2) I suggested we use JRD since it is defined. Was there any disagreement >> on that? >> 3) This issue is a point where there was clear division. The OpenID Connect >> team wants to be able to issue a single query and get a reply. You had an >> interest to use a static server. I investigated how we could do both. If >> one used Apache, for example, one could build a static site and still >> support the resource URI. Here's a couple of ways to do it: >> http://www.packetizer.com/webfinger/server.html (using either .htaccess or >> the global config file). What cannot be accomodated is the "rel" parameter, >> but I'd guess static sites will not produce voluminous results, anyway. >> >> So, it's not accurate to say your issues were ignored. We simply did not >> have strong consensus one way or the other. There were strong opinions on >> (3), so I tried to find a solution that might be acceptable. We may need >> more discussion on all of these points, of course. >> >> Paul >> >> >> On 5/8/2012 2:40 AM, Blaine Cook wrote: >> >> I disagree that the current spec is a good starting point - the issues I've >> raised have been ignored, and the spec is now much more complicated from >> both sides of the implementation fence. >> >> On May 7, 2012 3:17 PM, "Paul E. Jones" wrote: >>> >>> Walter, >>> >>> I'm not sure what the full set of issues will be, but I only have a couple >>> of small edits queued for -05 at present (one being "template" should be >>> "href" in the example at the end of 4.2 that you pointed out to me >>> privately). We've already worked through a number of issues to get to this >>> point, so there may not be a lot of changes needed. I'll not dismiss the >>> possibility that there are editorial issues, but I hope we've resolved most >>> of the technical details. >>> >>> We probably still need to have the discussion of keeping CORS and what >>> additions are needed to the security section. We've made a few changes >>> there already, but I'm not sure if it still fully addresses some of the >>> privacy concerns. >>> >>> Paul >>> >>> On 5/7/2012 5:37 AM, Goix Laurent Walter wrote: >>> >>> I also support this draft as a way forward for the discussion that I think >>> captures the essence of both philosophies. >>> >>> >>> >>> If such basis is agreed what are the major pending issues? >>> >>> >>> >>> Regards >>> >>> Laurent-walter >>> >>> >>> >>> Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >>> Per conto di Gonzalo Salgueiro (gsalguei) >>> Inviato: venerdì 4 maggio 2012 21.50 >>> A: Murray S. Kucherawy >>> Cc: oauth@ietf.org; apps-discuss@ietf.org >>> Oggetto: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 >>> >>> >>> >>> I support this doc being adopted as starting point for WG discussion. >>> >>> Regards, >>> >>> >>> >>> Gonzalo >>> >>> >>> >>> >>> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" >>> wrote: >>> >>> The above-named draft has been offered as the recommended path forward in >>> terms of converging on a single document to advance through appsawg. The >>> conversation I saw this week in that regard has seemed mostly positive. >>> >>> >>> >>> Please review it, or at least the diff, and indicate your support or >>> objection on apps-discuss@ietf.org to adopting this one as the common path >>> forward. We would like to make a decision about which one to begin advancing >>> in the next week or two. >>> >>> >>> >>> Have a good weekend! >>> >>> >>> >>> -MSK, APPSAWG co-chair >>> From eran@hueniverse.com Tue May 8 08:37:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2721F8622 for ; Tue, 8 May 2012 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y9zrDT94T0J for ; Tue, 8 May 2012 08:37:21 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id E7F3221F861C for ; Tue, 8 May 2012 08:37:20 -0700 (PDT) Received: from P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id 7TdL1j00D0CJzpC01TdLCi; Tue, 08 May 2012 08:37:20 -0700 Received: from P3PWEX2MB008.ex2.secureserver.net ([169.254.8.88]) by P3PWEX2HT001.ex2.secureserver.net ([184.168.131.9]) with mapi id 14.02.0247.003; Tue, 8 May 2012 08:37:20 -0700 From: Eran Hammer To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] [apps-discuss] draft-jones-appsawg-webfinger-04 Thread-Index: AQHNLSulZUNxyoIHCEGy9bqFghgqtpa//Q2QgAB64wD//4xuIA== Date: Tue, 8 May 2012 15:37:19 +0000 Message-ID: <0CBAEB56DDB3A140BA8E8C124C04ECA201023431@P3PWEX2MB008.ex2.secureserver.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> In-Reply-To: <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.74.213.174] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:37:21 -0000 I think it is perfectly fair, and common practice. You make it sound like it's some sort of competition or process manipulatio= n. Everyone here has bias. I don't recall you raising an issue on the OAuth= list every time a certain Microsoft employee affirmed support for his co-w= orker documents and positions (in fact those two have *never* "voted" diffe= rently). This criticism seems to be reserved for cases where *you* disagree with the= outcome.=20 EH > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Tuesday, May 08, 2012 8:23 AM > To: Eran Hammer > Cc: Hannes Tschofenig; Gonzalo Salgueiro; apps-discuss@ietf.org > Subject: Re: [OAUTH-WG] [apps-discuss] draft-jones-appsawg-webfinger-04 >=20 > So, you think it is a good practice if the authors + their co-workers ind= icate > support for their own documents? >=20 > On May 8, 2012, at 6:03 PM, Eran Hammer wrote: >=20 > > Neither was this comment. > > > > EH > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Hannes Tschofenig > >> Sent: Tuesday, May 08, 2012 7:56 AM > >> To: Gonzalo Salgueiro > >> Cc: oauth@ietf.org; apps-discuss@ietf.org > >> Subject: Re: [OAUTH-WG] [apps-discuss] > >> draft-jones-appsawg-webfinger-04 > >> > >> Gonzalo: it is great that you, as a co-author, support your own > >> document but I don't think it is particular helpful. > >> > >> On May 4, 2012, at 10:49 PM, Gonzalo Salgueiro (gsalguei) wrote: > >> > >>> I support this doc being adopted as starting point for WG discussion. > >>> > >>> Regards, > >>> > >>> Gonzalo > >>> > >>> > >>> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" > >> wrote: > >>> > >>>> The above-named draft has been offered as the recommended path > >> forward in terms of converging on a single document to advance > >> through appsawg. The conversation I saw this week in that regard has > >> seemed mostly positive. > >>>> > >>>> Please review it, or at least the diff, and indicate your support > >>>> or objection > >> on apps-discuss@ietf.org to adopting this one as the common path > forward. > >> We would like to make a decision about which one to begin advancing > >> in the next week or two. > >>>> > >>>> Have a good weekend! > >>>> > >>>> -MSK, APPSAWG co-chair > >>>> > >>>> _______________________________________________ > >>>> apps-discuss mailing list > >>>> apps-discuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/apps-discuss > >>> _______________________________________________ > >>> apps-discuss mailing list > >>> apps-discuss@ietf.org > >>> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Tue May 8 08:47:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DD511E80A2 for ; Tue, 8 May 2012 08:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtyG6ZAemYb3 for ; Tue, 8 May 2012 08:47:47 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45A1021F8652 for ; Tue, 8 May 2012 08:47:47 -0700 (PDT) Received: by yhq56 with SMTP id 56so6614744yhq.31 for ; Tue, 08 May 2012 08:47:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=D3HP0mJwW3pHzhmJ128oYEcqBf/HC85X11wt0wfJnqg=; b=ABTwABRi1K4ibrIO2Zqx25OiqJ5hAsEPdJUVj0gDRPNA7/qFrWCVthBWN+2kXYvZQd nC8hXv2cK3t9DgIpMyfVD6A3cZOmo4/jeSBJ8QkGSiutA/nCjn0UnkCWG1qsxeV/uZMb 9hx5IHlNDF3CGyIxsWxuHV6t1L7uWmWFCh0G9XtgG0vJgR/wZBVLepz9efn9xRet49wx e/K/ZMNZ7IQRq/Mqgn1DwVtSMml4v2o5jEc3gixYehXgfGY51iSpVL5pGGdeR4OTWcG7 WGRNvegTUlPlCJvaNluSqOU9XoW/5po7f9uZ0uQB8iRLWQDIg4NXi3K6p278P2aAcLiN +W7w== Received: by 10.236.136.8 with SMTP id v8mr6978214yhi.101.1336492066813; Tue, 08 May 2012 08:47:46 -0700 (PDT) Received: from [192.168.1.213] (190-20-29-176.baf.movistar.cl. [190.20.29.176]) by mx.google.com with ESMTPS id a13sm14605475anm.5.2012.05.08.08.47.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 08:47:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_15D87320-3F18-4638-ABFE-77C67CB465D1"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> Date: Tue, 8 May 2012 11:47:35 -0400 Message-Id: References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnYTshEnvDKJ9nUACWgqUmxwwfO85dE5fDuna7wZc43o2Z27cxoR33SKCu9xjAMt4y6Puku Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 15:47:48 -0000 --Apple-Mail=_15D87320-3F18-4638-ABFE-77C67CB465D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hannes, Deep breath. The question is not if the document is perfect, only if it can be the = starting point. I suspect you are mixing up authentication in your comments. SWD and WF provide information about identifiers. =20 It is true that WF can also provide alias information that can be used = to correlate, though that is sort of the point of publicly listing them. We have agreed that WF can optionally be a protected resource to allow = selective disclosure at providers that want to support that. The goal was to not prevent some sites that only want to serve public = information from doing so. I too have concerns about defining a new URI scheme and the likelihood = of getting that approved. However we need someplace to start.=20 Are you advocating using SWD as the starting document, or more specific = changes to WF? John B. On 2012-05-08, at 11:23 AM, Hannes Tschofenig wrote: > So, you think it is a good practice if the authors + their co-workers = indicate support for their own documents? >=20 > On May 8, 2012, at 6:03 PM, Eran Hammer wrote: >=20 >> Neither was this comment. >>=20 >> EH >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>> Of Hannes Tschofenig >>> Sent: Tuesday, May 08, 2012 7:56 AM >>> To: Gonzalo Salgueiro >>> Cc: oauth@ietf.org; apps-discuss@ietf.org >>> Subject: Re: [OAUTH-WG] [apps-discuss] = draft-jones-appsawg-webfinger-04 >>>=20 >>> Gonzalo: it is great that you, as a co-author, support your own = document but >>> I don't think it is particular helpful. >>>=20 >>> On May 4, 2012, at 10:49 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>=20 >>>> I support this doc being adopted as starting point for WG = discussion. >>>>=20 >>>> Regards, >>>>=20 >>>> Gonzalo >>>>=20 >>>>=20 >>>> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" >>> wrote: >>>>=20 >>>>> The above-named draft has been offered as the recommended path >>> forward in terms of converging on a single document to advance = through >>> appsawg. The conversation I saw this week in that regard has seemed >>> mostly positive. >>>>>=20 >>>>> Please review it, or at least the diff, and indicate your support = or objection >>> on apps-discuss@ietf.org to adopting this one as the common path = forward. >>> We would like to make a decision about which one to begin advancing = in the >>> next week or two. >>>>>=20 >>>>> Have a good weekend! >>>>>=20 >>>>> -MSK, APPSAWG co-chair >>>>>=20 >>>>> _______________________________________________ >>>>> apps-discuss mailing list >>>>> apps-discuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>> _______________________________________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_15D87320-3F18-4638-ABFE-77C67CB465D1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUw ODE1NDczNlowIwYJKoZIhvcNAQkEMRYEFAr1kYMzx9OuAjtqpnSvLszum5M8MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AC2FbxYTM9dKa6wgOeQB8PeBxJI04dC27MBHpJs+PWBhTAnbHyq+OPCoPGOp1ikeenyqho8wGf8K /AeueoPnmBUAJ7GdYaKaFGacYHjfoLp4m+OuJzZPfxpwbyM+2H6Nv1ZkbX7D4D94W/tG133gArva 0IKsJLaLO/VGTBqzdoU38NotrwtIozG4t1FpsVy0RBF3hvnUCHFd1nPRsdjC5h80t8EhuD+0HI95 qPURU5b7tQK0kpnMeHAQmqtXb1N7lO8T63MIYnMWtixd2zX9K5EF6c+rmzk5GCu6rkGXWYITzc8P AwUX8pEml+hBzn/iFffN7qvNb0soBVbop6zIdmsAAAAAAAA= --Apple-Mail=_15D87320-3F18-4638-ABFE-77C67CB465D1-- From msk@cloudmark.com Tue May 8 09:24:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9121F855F for ; Tue, 8 May 2012 09:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NvRbWA8WH90 for ; Tue, 8 May 2012 09:24:32 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id CA50521F84DD for ; Tue, 8 May 2012 09:24:32 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 7UQX1j0030ZaKgw01UQXTJ; Tue, 08 May 2012 09:24:31 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=R/iB6KtX c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=z-d0dY4iUb8A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=2dLDzdADIg2MKMq0ohMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 8 May 2012 09:24:32 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 Thread-Index: AQHNLSvMrMrpjjpTdU+LHwoBBDKmp5bAd/AA//+boeA= Date: Tue, 8 May 2012 16:24:31 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039281194FE@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> In-Reply-To: <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336494272; bh=Kl+9cHXlqC4Tl+3nJFFVF9xKykbY2DT1mZzw0Di4GSg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=yB5T58gm+eJ8fSJI8uHZH5RFjCjKq6QOcNnN4Hy+jpIYb3jiMU7Y9HlNWR9nxPY14 EQ0nTBGEZw9Ye7VkkU20aRAQZyk1p5vI2C1d4g2bORdWiNutfaEMdbCy50TOXM6Uwl UCsSUOvVNn5nhodcy2hsRcS8HRk7M3XRYaAhgThU= Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:24:33 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Hannes Tschofenig > Sent: Tuesday, May 08, 2012 8:23 AM > To: Eran Hammer > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 >=20 > So, you think it is a good practice if the authors + their co-workers > indicate support for their own documents? I find the comment harmless, since the people who have to evaluate consensu= s are quite aware of who the authors are. -MSK From gsalguei@cisco.com Tue May 8 11:53:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C689121F8573 for ; Tue, 8 May 2012 11:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=-3.970, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UsGJEQ4SsxG for ; Tue, 8 May 2012 11:53:05 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7921F853B for ; Tue, 8 May 2012 11:53:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q48Ir4E1002077 for ; Tue, 8 May 2012 14:53:04 -0400 (EDT) Received: from rtp-vpn4-1896.cisco.com (rtp-vpn4-1896.cisco.com [10.82.215.104]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q48Ir3aa016231; Tue, 8 May 2012 14:53:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: Date: Tue, 8 May 2012 14:52:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E199AF5-39B4-46F5-86FC-C0884480EDEB@cisco.com> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1257) Cc: oauth@ietf.org, "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 18:53:05 -0000 Hannes: While I'm clearly honored by your interest in me and my = activities, it is not my intent to artificially pump up a document on = which I am a co-author. Everyone on this list knows I am an author on = it as we have discussed it exhaustively for the past month and a half. I = was merely indicating my support of the compromised direction being = proposed (as we were at a bit of an impasse with two documents in call = for adoption that were proposing a solution for the same problem space). = It took a good bit of on-list and off-list discussion for the SWD and WF = camps to draw a line in the sand and come to an agreement on a = compromise that was a mutually satisfying starting point that the WG = could get behind. This proposal was put forth (and supported) separately = by Mike Jones (a co-author on SWD) and Paul Jones (a co-author on WF). = I, as another co-author of WF, was voicing my support of the compromise = as a starting point. I don't believe any of the co-authors involved were = at fault or acted with irregularity. Cheers, Gonzalo On May 8, 2012, at 10:55 AM, Hannes Tschofenig wrote: > Gonzalo: it is great that you, as a co-author, support your own = document but I don't think it is particular helpful.=20 >=20 > On May 4, 2012, at 10:49 PM, Gonzalo Salgueiro (gsalguei) wrote: >=20 >> I support this doc being adopted as starting point for WG discussion. >>=20 >> Regards, >>=20 >> Gonzalo >>=20 >>=20 >> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" = wrote: >>=20 >>> The above-named draft has been offered as the recommended path = forward in terms of converging on a single document to advance through = appsawg. The conversation I saw this week in that regard has seemed = mostly positive. >>>=20 >>> Please review it, or at least the diff, and indicate your support or = objection on apps-discuss@ietf.org to adopting this one as the common = path forward. We would like to make a decision about which one to begin = advancing in the next week or two. >>>=20 >>> Have a good weekend! >>>=20 >>> -MSK, APPSAWG co-chair >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 From sm@resistor.net Tue May 8 12:18:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5785421F8595 for ; Tue, 8 May 2012 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX7OeRQXajIC for ; Tue, 8 May 2012 12:18:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEE021F8593 for ; Tue, 8 May 2012 12:18:02 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q48JHsJb005056; Tue, 8 May 2012 12:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1336504679; i=@resistor.net; bh=+FC2taadXNnUdPeTAnomUY/FRnGtdXLWWS5Ut50Xj+g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X7BT2ynBtXL0pRdiH80SUya5lq7mPtapr40CWEYkmadlJwB3zdJmiGAHVda5hkIch 7+QEb7IsdEvu2L6KjP2oGAhTaZNyoZBQAncZzd0hmnjU7qa4t5rAZ1dlHzNaxd8xhJ Iki6QAlKtD1UaAYkfZgtgxedvFK3qAg0HMZupzPk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1336504679; i=@resistor.net; bh=+FC2taadXNnUdPeTAnomUY/FRnGtdXLWWS5Ut50Xj+g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aDx2HvbDGBz4r4j7MtlvYiJn4T5aaMUKZuITK3++slpkmlp3366x467ZEpTqieJu5 fmaLDA6jMPvztraYLsiQpbbTPEUYy2Wjt5xNAGio26jFR20elOuXIQ+rZ2f+AH7mt8 Oze2SnXL4MwnpGWH94bOqjfHoRQ9rOg29yINqARc= Message-Id: <6.2.5.6.2.20120508121042.09e064b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 08 May 2012 12:16:05 -0700 To: Hannes Tschofenig From: SM In-Reply-To: <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 19:18:04 -0000 Hi Hannes, At 08:23 08-05-2012, Hannes Tschofenig wrote: >So, you think it is a good practice if the authors + their >co-workers indicate support for their own documents? It does not matter in the case of the author it is considered as a "no operation performed". Any other individual, even a co-worker, may indicate support for the document. Regards, -sm From phil.hunt@oracle.com Tue May 8 12:32:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E75921F84EA for ; Tue, 8 May 2012 12:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.581 X-Spam-Level: X-Spam-Status: No, score=-9.581 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktnY0sbrVyfM for ; Tue, 8 May 2012 12:32:51 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id B317121F84E4 for ; Tue, 8 May 2012 12:32:51 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q48JWlbG032630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 May 2012 19:32:48 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q48JWl0k012544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 May 2012 19:32:47 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q48JWkI8015575; Tue, 8 May 2012 14:32:47 -0500 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 May 2012 12:32:46 -0700 References: <9452079D1A51524AA5749AD23E00392810E4CA@exch-mbx901.corp.cloudmark.com> <5876011F-2C2C-4889-9452-E8BDC1438713@cisco.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20102324B@P3PWEX2MB008.ex2.secureserver.net> <36DACB68-A001-4B9D-8E0D-C10EE1BB8D82@gmx.net> <6.2.5.6.2.20120508121042.09e064b0@resistor.net> In-Reply-To: <6.2.5.6.2.20120508121042.09e064b0@resistor.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <71787930-D1B9-4835-A814-887F9D60CFFC@oracle.com> X-Mailer: iPhone Mail (9B179) From: Phil Hunt Date: Tue, 8 May 2012 12:34:23 -0700 To: SM X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 19:32:52 -0000 It took the author's agreement in the larger context of starting with the do= c and making the discussed changes. =20 Phil On 2012-05-08, at 12:16, SM wrote: > Hi Hannes, > At 08:23 08-05-2012, Hannes Tschofenig wrote: >> So, you think it is a good practice if the authors + their co-workers ind= icate support for their own documents? >=20 > It does not matter in the case of the author it is considered as a "no ope= ration performed". Any other individual, even a co-worker, may indicate sup= port for the document. >=20 > Regards, > -sm=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ned.freed@mrochek.com Tue May 8 14:28:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9211E8079 for ; Tue, 8 May 2012 14:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clQPScXLlsuw for ; Tue, 8 May 2012 14:28:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04E11E8072 for ; Tue, 8 May 2012 14:28:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF8RSR6RB4000VXS@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 8 May 2012 14:28:26 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com>; Tue, 8 May 2012 14:28:23 -0700 (PDT) Message-id: <01OF8RSPPS320006TF@mauve.mrochek.com> Date: Tue, 08 May 2012 14:09:32 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 08 May 2012 10:06:30 -0400" References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> To: Barry Leiba Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 21:28:29 -0000 > > Abstract > >   This document changes RFC 2046 rules regarding default charset > >   parameter values for text/* media types to better align with common > >   usage by existing clients and servers. > ... > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/ballot/ > This document sailed through IETF last call with no comments, but > something has come up in IESG evaluation -- Robert chatted with me > about this, and I suggested that he put a DISCUSS ballot in until we > resolve it. > The document makes it very clear that "existing registrations" are not > affected (and therefore retain their RFC 2046 default of US-ASCII for > charset). But how does someone TELL that a subtype is "existing"? This was brought up and resolved during last call comments. The current rules allow a text/* media type to say anything about charsets, and if it allows a optional charset parameter, there's no need to state what the default is. The new rules say that a media type either (1) Specifies that no charset parameter is used and that the charset is determined from inspection of the content, or (2) Requires inclusion of a charset parameter specifying what the charset is, or (3) Explicitly states what the default charset is. (Either with or without allowing an optional charset parameter as a means of overriding the default.) The last option is dicouraged (SHOULD NOT). No other options are given, so it follows that a media type that fails to do one of these things is supposed to be rejected by the reviewer. As such, there is no possibility of confusion. An old text/* media type can get away without specifying charset information and relying on the language in RFC 2045; a new one cannot. > Chasing documentation pointers and checking dates is not a reasonable > way. Five years from now, when 60 more text subtypes have been added > to the 60 that are there, how will anyone know *which* of those 120 > are affected by this spec and which are not? A nonissue. See above. > Further, both (a) and (b) in section 3 are things that SHOULD be done; > what if a new registration does neither, violating both SHOULDs? How > will someone know what its default is? And this is precisely why it is so important to be able to use compliance language in registration RFCs. SHOULD means "do it unless you have a good reason not to". In this case this isn't a judgement call made by an implementor; the question is whether or not you can convince the reviewer you have sufficient cause to violate the SHOULD. > I think the right way to fix this is to put new text in near the end > of section 3, just to make things absolutely clear: > -------- > OLD > New subtypes of the "text" media type, thus, SHOULD NOT define a > default "charset" value. If there is a strong reason to do so > despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as > the default. > NEW > New subtypes of the "text" media type, thus, SHOULD NOT define a > default "charset" value. If there is a strong reason to do so > despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as > the default. > To maintain compatibility with existing registrations, this fallback rule > applies: any subtype of the "text" media type that does not comply with > the rules above retains US-ASCII as its default, as originally specified > in RFC 2046. > -------- That's a really bad idea for all sorts of reasons, including but not limited to it makes the document self-contradictory. You shouldn't remove a rule then say it's OK to fall back on it. Now, if you want to add something that says: Regardless of the approach chosen, all text/* registrations MUST clearly specify how the charset of the content is determined and MUST NOT rely on the RFC 2045 rule. I think this falls out of the existing text, but if you want to make it crystal clear I don't have a problem. > The document editors are OK with this text, but we want to pass it by > the working group for comment. Does anyone object to this suggestion? I strongly object. > Does anyone think the issue should be addressed differently? See above. Ned From James.H.Manger@team.telstra.com Tue May 8 18:02:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71209E8015 for ; Tue, 8 May 2012 18:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvMCrSd+oOJT for ; Tue, 8 May 2012 18:02:23 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 09C179E8012 for ; Tue, 8 May 2012 18:02:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,554,1330866000"; d="scan'208,217";a="75179327" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 09 May 2012 11:02:17 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6705"; a="62041089" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdvi.tcif.telstra.com.au with ESMTP; 09 May 2012 11:02:15 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 9 May 2012 11:02:16 +1000 From: "Manger, James H" To: Stephen Farrell , Martin Thomson Date: Wed, 9 May 2012 11:02:14 +1000 Thread-Topic: [apps-discuss] Indicating hash size in 'ni' URIs Thread-Index: Ac0s/zRSPuXpWyz7TtWNUPfKeVGPLwAd0l+Q Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2A1546E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> <4FA68A60.6030207@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F28540B5@WSMSG3153V.srv.dir.telstra.com> <4FA8EB06.4020004@cs.tcd.ie> In-Reply-To: <4FA8EB06.4020004@cs.tcd.ie> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Discuss Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 01:02:24 -0000 >>> I would still rather ditch the truncation length from the alg names. =20 >> I'm with James on this one. >> ... The example of a truncated stream cipher seems contrived to me. > Not to me. > > I think that omitting the size would mean that anyone using > these would need to go think about potential truncation attacks, > and having to do that is bad, since most times they won't do > it at all and even if they do, those attacks, if they apply, > will be likely be very subtle. So even if you try figure it > out, you may not get the analysis right. Avoiding all that > is just better IMO. I am trying to understand the truncation attacks you are concerned about. W= ould an example be an HTTPS web connection that abruptly stops mid stream? = All the received TLS records are properly encrypted and have valid MACs. Ho= wever, only half of the HTML page has been delivered: it might end " tag and acts on the wrong (truncated) URI. The fault is not with the 'ni' URI. Solving this situation would require al= l protocols (not just 'ni' identifiers) to be "prefix-free" (eg no prefix o= f a protocol can be meaningful). That is not realistic. An 'ni' URI can have query parameters. Couldn't a truncation attack strip t= hose regardless of whether the hash length is in the alg name? Why isn't th= at a problem? > Additionally, if we took out the length then we'd have to > figure whether or not (or when, yuk) ni:///sha-256;abc is the > "same" as ni:///sha-256;abcdef and even if we declare that its > never the same, that's something people are liable to get > wrong, since sometimes both would actually refer to the same > thing. Yuk yuk yuk;-) Implementations are just as likely to consider that the following are the "= same": ni:///sha-256-32;abcdef ni:///sha-256-64;abcdefghijk If a truncation attack really needs to be defended against, we should speci= fy that the output length (and algorithm) are inputs to the hash. For examp= le, Truncate_to_n(Hash(alg || n || content)). -- James Manger From ned.freed@mrochek.com Tue May 8 18:03:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE7411E8074 for ; Tue, 8 May 2012 18:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P02h2NyQQ0a0 for ; Tue, 8 May 2012 18:03:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 574CE9E8015 for ; Tue, 8 May 2012 18:03:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF8ZBUAG5C00061N@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 8 May 2012 18:03:52 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com>; Tue, 8 May 2012 18:03:49 -0700 (PDT) Message-id: <01OF8ZBSJ23M0006TF@mauve.mrochek.com> Date: Tue, 08 May 2012 18:02:13 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 08 May 2012 14:09:32 -0700 (PDT)" <01OF8RSPPS320006TF@mauve.mrochek.com> References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> <01OF8RSPPS320006TF@mauve.mrochek.com> To: Ned Freed Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 01:03:56 -0000 > > > Abstract > > >   This document changes RFC 2046 rules regarding default charset > > >   parameter values for text/* media types to better align with common > > >   usage by existing clients and servers. > > ... > > > The file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/ballot/ > > This document sailed through IETF last call with no comments, but > > something has come up in IESG evaluation -- Robert chatted with me > > about this, and I suggested that he put a DISCUSS ballot in until we > > resolve it. > > The document makes it very clear that "existing registrations" are not > > affected (and therefore retain their RFC 2046 default of US-ASCII for > > charset). But how does someone TELL that a subtype is "existing"? > This was brought up and resolved during last call comments. > The current rules allow a text/* media type to say anything about charsets, Correction: "anything" -> "nothing" > and if it allows a optional charset parameter, there's no need to state what > the default is. > The new rules say that a media type either > (1) Specifies that no charset parameter is used and that the charset is > determined from inspection of the content, or > (2) Requires inclusion of a charset parameter specifying what the charset > is, or > (3) Explicitly states what the default charset is. (Either with or without > allowing an optional charset parameter as a means of overriding the > default.) > The last option is dicouraged (SHOULD NOT). > No other options are given, so it follows that a media type that fails to do > one of these things is supposed to be rejected by the reviewer. > As such, there is no possibility of confusion. An old text/* media type can get > away without specifying charset information and relying on the language in RFC > 2045; a new one cannot. > > Chasing documentation pointers and checking dates is not a reasonable > > way. Five years from now, when 60 more text subtypes have been added > > to the 60 that are there, how will anyone know *which* of those 120 > > are affected by this spec and which are not? > A nonissue. See above. > > Further, both (a) and (b) in section 3 are things that SHOULD be done; > > what if a new registration does neither, violating both SHOULDs? How > > will someone know what its default is? > And this is precisely why it is so important to be able to use compliance > language in registration RFCs. SHOULD means "do it unless you have a good > reason not to". In this case this isn't a judgement call made by an > implementor; the question is whether or not you can convince the reviewer you > have sufficient cause to violate the SHOULD. > > I think the right way to fix this is to put new text in near the end > > of section 3, just to make things absolutely clear: > > -------- > > OLD > > New subtypes of the "text" media type, thus, SHOULD NOT define a > > default "charset" value. If there is a strong reason to do so > > despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as > > the default. > > NEW > > New subtypes of the "text" media type, thus, SHOULD NOT define a > > default "charset" value. If there is a strong reason to do so > > despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as > > the default. > > To maintain compatibility with existing registrations, this fallback rule > > applies: any subtype of the "text" media type that does not comply with > > the rules above retains US-ASCII as its default, as originally specified > > in RFC 2046. > > -------- > That's a really bad idea for all sorts of reasons, including but not limited to > it makes the document self-contradictory. You shouldn't remove a rule then say > it's OK to fall back on it. > Now, if you want to add something that says: > Regardless of the approach chosen, all text/* registrations MUST clearly > specify how the charset of the content is determined and MUST NOT rely > on the RFC 2045 rule. > I think this falls out of the existing text, but if you want to make it crystal > clear I don't have a problem. > > The document editors are OK with this text, but we want to pass it by > > the working group for comment. Does anyone object to this suggestion? > I strongly object. > > Does anyone think the issue should be addressed differently? > See above. > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From barryleiba@gmail.com Tue May 8 18:18:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6E9E8015 for ; Tue, 8 May 2012 18:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.968 X-Spam-Level: X-Spam-Status: No, score=-102.968 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC2dV7uSq12Z for ; Tue, 8 May 2012 18:18:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 310F69E8012 for ; Tue, 8 May 2012 18:18:21 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so12538713obb.31 for ; Tue, 08 May 2012 18:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YAuO4jWCl/4tlZ2dQ4hEhjpDdD3bWQ37dXNamvU4h3I=; b=dbh1EFtRRwURob8UKur6CAfRo9FuKG9XvWDDvEjYuq8pZfQFp/QGfNou5MCs92srgq abBfiFzqfrnUiTnt5gkvHrQuIUMxUxXaGsQutjS24iale3e5qWZKh7jQf5t2M3fu+ZTU QeI9RkjsAc2OdD3vZ14UwCLdCfPlIdY1VI2RehRimD6wGiX6CI7ZcLcVNaz5vUufS8sM EwcBXJDuzuio5EyIJJsNI1oZ4EX+Qtj7URIWTo8BC1p4sJosc0N2eF7yOD8nVVMG3EHj pgnIwcx9TwmqTBy0SghqmbaEXN09iSKvEExPtF1m3bgvhhEPIUPBmkUbP4MIlznMvFk4 3XSQ== MIME-Version: 1.0 Received: by 10.182.172.100 with SMTP id bb4mr1647227obc.22.1336526300848; Tue, 08 May 2012 18:18:20 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Tue, 8 May 2012 18:18:20 -0700 (PDT) In-Reply-To: <01OF8RSPPS320006TF@mauve.mrochek.com> References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> <01OF8RSPPS320006TF@mauve.mrochek.com> Date: Tue, 8 May 2012 21:18:20 -0400 X-Google-Sender-Auth: GxPxV4bZRZ9Xq9i_1ur4juzBrSQ Message-ID: From: Barry Leiba To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 01:18:21 -0000 > The new rules say that a media type either > > (1) Specifies that no charset parameter is used and that the charset is > =A0 =A0determined from inspection of the content, or > > (2) Requires inclusion of a charset parameter specifying what the charset > =A0 =A0is, or > > (3) Explicitly states what the default charset is. (Either with or withou= t > =A0 =A0allowing an optional charset parameter as a means of overriding th= e > =A0 =A0default.) The document makes all of those SHOULD. From section 3: In order to improve interoperability with deployed agents, "text/*" media type registrations SHOULD either a. specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (such as in "text/xml"), or b. require explicit unconditional inclusion of the "charset" parameter eliminating the need for a default value. There's nothing that I read in this document that says that registrations MUST do anything with regard to charset parameters. Now, you may say that the designated expert would never accept a registration that didn't (and well you might say that), but someone looking at the registrations and their associated documentation won't know that. > As such, there is no possibility of confusion. An old text/* media type c= an get > away without specifying charset information and relying on the language i= n RFC > 2045; a new one cannot. There is absolutely a possibility of confusion. Someone who doesn't know you and the process well may see something registered and be completely uncertain whether it's old (and therefore gets US-ASCII as its default) or whether it's new and doesn't comply with the SHOULDs here (and therefore gets &deity only knows what as its default). > the question is whether or not you can convince the reviewer you > have sufficient cause to violate the SHOULD. And if you do so convince the reviewer, what does the default value wind up being? And, again, how's an arbitrary person to know? >> =A0 To maintain compatibility with existing registrations, this fallback= rule >> =A0 applies: any subtype of the "text" media type that does not comply w= ith >> =A0 the rules above retains US-ASCII as its default, as originally speci= fied >> =A0 in RFC 2046. > > That's a really bad idea for all sorts of reasons, including but not limi= ted to > it makes the document self-contradictory. You shouldn't remove a rule the= n say > it's OK to fall back on it. Well, I disagree with that. No matter, see below. > Now, if you want to add something that says: > > =A0Regardless of the approach chosen, all text/* registrations MUST clear= ly > =A0specify how the charset of the content is determined and MUST NOT rely > =A0on the RFC 2045 rule. I'd change that to "all new text/* registrations", and I still want to add a sentence that says that existing text/* registrations that don't specify this retain the 2045 rule. > I think this falls out of the existing text, but if you want to make it c= rystal > clear I don't have a problem. I think it does not fall out of the existing text at all. Barry From ned.freed@mrochek.com Tue May 8 22:37:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8021F85E1 for ; Tue, 8 May 2012 22:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dPvIt4d5j02 for ; Tue, 8 May 2012 22:37:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2100021F85D9 for ; Tue, 8 May 2012 22:37:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF98WHN0JK001ATE@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 8 May 2012 22:37:49 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OF7HODY84G0006TF@mauve.mrochek.com>; Tue, 8 May 2012 22:37:46 -0700 (PDT) Message-id: <01OF98WFXDKI0006TF@mauve.mrochek.com> Date: Tue, 08 May 2012 19:33:43 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 08 May 2012 21:18:20 -0400" References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> <01OF8RSPPS320006TF@mauve.mrochek.com> To: Barry Leiba Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 05:37:53 -0000 > > The new rules say that a media type either > > > > (1) Specifies that no charset parameter is used and that the charset is > >    determined from inspection of the content, or > > > > (2) Requires inclusion of a charset parameter specifying what the charset > >    is, or > > > > (3) Explicitly states what the default charset is. (Either with or without > >    allowing an optional charset parameter as a means of overriding the > >    default.) > The document makes all of those SHOULD. From section 3: > In order to improve interoperability with deployed agents, "text/*" > media type registrations SHOULD either > a. specify that the "charset" parameter is not used for the defined > subtype, because the charset information is transported inside > the payload (such as in "text/xml"), or > b. require explicit unconditional inclusion of the "charset" > parameter eliminating the need for a default value. > There's nothing that I read in this document that says that > registrations MUST do anything with regard to charset parameters. I never said it did. The requirement falls out of the options this document provides coupled with something I thought was obvious: The requirement that registrations not be obviously ambiguous. > Now, you may say that the designated expert would never accept a > registration that didn't (and well you might say that), but someone > looking at the registrations and their associated documentation won't > know that. So what you're saying is that someone could look at this document and conclude that it allows inherently ambiguous registrations? I guess I give the people who'd actually bother to read these specifications at this level of detail a bit more credit than that, but fair enough. > > As such, there is no possibility of confusion. An old text/* media type can get > > away without specifying charset information and relying on the language in RFC > > 2045; a new one cannot. > There is absolutely a possibility of confusion. Someone who doesn't > know you and the process well may see something registered and be > completely uncertain whether it's old (and therefore gets US-ASCII as > its default) or whether it's new and doesn't comply with the SHOULDs > here (and therefore gets &deity only knows what as its default). This has nothing to do with me. I would expect any reviewer to perform this level of checking. In fact one of the reasons expert review was instituted was that IANA internal review wasn't familiar enough with the technical details and thus was incapable of performing these sorts of checks. > > the question is whether or not you can convince the reviewer you > > have sufficient cause to violate the SHOULD. > And if you do so convince the reviewer, what does the default value > wind up being? And, again, how's an arbitrary person to know? Well, as it happens a similar case has come up in the past, so I don't have to guess. There was a text media type that was intended for use with video subtitles, where the format of the text was controlled by bilateral agreement between the sender and the receiver. So the security considerations could not be specified because they were entirely dependent on the format arranged by that agreement (could contain dangerous active content, might be nothing but ASCII, or anything in between). But the closest thing we allow for is to say "security considerations have not be assessed", which doesn't really fit. In that case I allowed the registration to say "... the security considerations of this type cannot be assessed because the format is determined by bilateral agreement ...". But what would never be allowed is to do something similar with a charset definition without saying *why* it was being done. > >>   To maintain compatibility with existing registrations, this fallback rule > >>   applies: any subtype of the "text" media type that does not comply with > >>   the rules above retains US-ASCII as its default, as originally specified > >>   in RFC 2046. > > > > That's a really bad idea for all sorts of reasons, including but not limited to > > it makes the document self-contradictory. You shouldn't remove a rule then say > > it's OK to fall back on it. > Well, I disagree with that. No matter, see below. > > Now, if you want to add something that says: > > > >  Regardless of the approach chosen, all text/* registrations MUST clearly > >  specify how the charset of the content is determined and MUST NOT rely > >  on the RFC 2045 rule. > I'd change that to "all new text/* registrations", and I still want to > add a sentence that says that existing text/* registrations that don't > specify this retain the 2045 rule. It's still a bad idea to continue to rely on the old rule in any way. The other problem with the RFC 2045 rule is that it fell apart the minute HTTP overrode it and said that text/html without a charset parameter defaults to iso-8859-1. So right there you have what is likely the most commonly used subtype of text at this point breaking the rule you're now saying is what old types fall back to. Talk about confusing! (Really, in regards to that rule, all this document is doing is formalizing something that's been true for almost two decades.) So how about: Rgardless of the approach chosen, all new text/* registrations MUST clearly specify how the charset of the content is determined; relying on the RFC 2045 is no longer permitted. However, existing text/* registrations that fail to specify how the charset is determined still default to US-ASCII. Note that this is different than the old rule, which says that if no charset parameter is present the charset must default to us-ascii. And we probably want to update the main registration document with something similar. Ned From barryleiba@gmail.com Wed May 9 03:54:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A1321F85B5 for ; Wed, 9 May 2012 03:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.968 X-Spam-Level: X-Spam-Status: No, score=-102.968 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLM8tbUcIRpY for ; Wed, 9 May 2012 03:54:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBB0A21F85AF for ; Wed, 9 May 2012 03:54:19 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so199138obb.31 for ; Wed, 09 May 2012 03:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RF0zLmQ6kZhY/3l2LWj1Q5WWXmU8qmuORdi/T++7ZEw=; b=tuQihDIfxxM7PsIKwZwxVO2Bx1/y9mK3c71fakz6/OB1BJ2rPtBStgJkhuIXmhp9+T yXYYqBIcMGXUv/CJNEjX63DrHCg4FIm5fEmRXy6t3OPCa58xZuTfdG/1/npPCigDswhD KzpruDhDTuqcJXv/KjJ/vMT7OhmxhvXsHwcWYYnjxX95zT1VWIIrf2yzE98zomN8tQu0 FuO6IDQZTUsqrrqRAehPYA0Wx1pTmJQHYHnnYwrs77XU4Jpq1v4iLaOV5/z5oK0qBKNF mGbHH6UqP9unDK1a+GNSlZJEpT3PtVn46/0KZS0mFJm2H/PDmg+OWLzKXeaT0F76qy8P 6cDA== MIME-Version: 1.0 Received: by 10.60.29.10 with SMTP id f10mr31247878oeh.32.1336560859462; Wed, 09 May 2012 03:54:19 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Wed, 9 May 2012 03:54:19 -0700 (PDT) In-Reply-To: <01OF98WFXDKI0006TF@mauve.mrochek.com> References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> <01OF8RSPPS320006TF@mauve.mrochek.com> <01OF98WFXDKI0006TF@mauve.mrochek.com> Date: Wed, 9 May 2012 06:54:19 -0400 X-Google-Sender-Auth: SYJjzpH3YSlg-T0sN4TpixYemmA Message-ID: From: Barry Leiba To: Ned Freed Content-Type: multipart/alternative; boundary=e89a8ff1c89a3fbdc104bf98535c Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Last Call: (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 10:54:20 -0000 --e89a8ff1c89a3fbdc104bf98535c Content-Type: text/plain; charset=ISO-8859-1 > > So how about: > > Rgardless of the approach chosen, all new text/* registrations MUST > clearly specify how the charset of the content is determined; relying > on the RFC 2045 is no longer permitted. However, existing text/* > registrations that fail to specify how the charset is determined still > default to US-ASCII. > That works for me. Barry --e89a8ff1c89a3fbdc104bf98535c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So how about:

=A0 Rgardless of the approach chosen, all new text/* registrations MUST =A0 clearly specify how the charset of the content is determined; relying<= br> =A0 on the RFC 2045 is no longer permitted. However, existing text/*
=A0 registrations that fail to specify how the charset is determined still=
=A0 default to US-ASCII.

That works for me.

Barry=A0
--e89a8ff1c89a3fbdc104bf98535c-- From julian.reschke@gmx.de Wed May 9 04:04:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4726921F85AF for ; Wed, 9 May 2012 04:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.089 X-Spam-Level: X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+eqEra1TI5J for ; Wed, 9 May 2012 04:04:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5484A21F854B for ; Wed, 9 May 2012 04:04:16 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2012 11:04:14 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 09 May 2012 13:04:14 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18J0n0zZesJtpR3VtStURxDl+ROJPheMjsjh07Mzn SFQShdwyDxkL/n Message-ID: <4FAA4F2B.3000307@gmx.de> Date: Wed, 09 May 2012 13:04:11 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ned Freed References: <20120423132812.32410.11259.idtracker@ietfa.amsl.com> <01OF8RSPPS320006TF@mauve.mrochek.com> <01OF98WFXDKI0006TF@mauve.mrochek.com> In-Reply-To: <01OF98WFXDKI0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Update to MIME regarding Charset Parameter Handling in Textual Media Types) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:04:17 -0000 On 2012-05-09 04:33, Ned Freed wrote: > ... > So what you're saying is that someone could look at this document and conclude > that it allows inherently ambiguous registrations? > > I guess I give the people who'd actually bother to read these specifications at > this level of detail a bit more credit than that, but fair enough. > ... +1 > It's still a bad idea to continue to rely on the old rule in any way. The other > problem with the RFC 2045 rule is that it fell apart the minute HTTP overrode > it and said that text/html without a charset parameter defaults to iso-8859-1. Actually, text/*. But we have fixed this in httpbis (). > So right there you have what is likely the most commonly used subtype of text > at this point breaking the rule you're now saying is what old types fall back > to. Talk about confusing! (Really, in regards to that rule, all this document > is doing is formalizing something that's been true for almost two decades.) > > So how about: > > Rgardless of the approach chosen, all new text/* registrations MUST > clearly specify how the charset of the content is determined; relying > on the RFC 2045 is no longer permitted. However, existing text/* > registrations that fail to specify how the charset is determined still > default to US-ASCII. Sounds good to me. > Note that this is different than the old rule, which says that if no charset > parameter is present the charset must default to us-ascii. > > And we probably want to update the main registration document with something > similar. I consider this document to be an RFC-ized erratum. If we're going to update RFC 2045, it should include the changes we're doing here, and obsolete this document (-> historic), right? Best regards, Julian From stephen.farrell@cs.tcd.ie Wed May 9 04:57:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDF221F84BF for ; Wed, 9 May 2012 04:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N4mKvihYnZr for ; Wed, 9 May 2012 04:57:39 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 33FDD21F8494 for ; Wed, 9 May 2012 04:57:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A5D98171538; Wed, 9 May 2012 12:57:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1336564657; bh=GYo3wMHcpnbpdc JLWGyADOCIV8nKrWDhpqV1HN/nQLc=; b=Bx+vU44PZ2g+LbtQN/NFi5HuH072qN l5ArUO17wtUUUQQWL+KIOkDI0NojyNUJJrLzAgPOEtcr1iihvFbCCb2mk+PtTmY7 si+M7EMRCF/FhKwru+raIuWck5+dIZnaARwBKBErDxGQpneaXVlAOFtS2U3Icijj AQ4NmAPS1Vqf9UnezT8UKf4xIYANHlBuh9a8F8cYZ99sOlonlzfj/vazckyCMLyh qFrUyeCNSzK1X+B5wuthHn+vzjBARPDKM2nKGBl0qLI/2Q+n2sXcCNrhlbLLq+Dr AzWzlSJrgoG819vxjyVEai/0gk1dVjj7t2jmke6RGO0f7B+9Izj/E2Vw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Td7cLIPBtd8W; Wed, 9 May 2012 12:57:37 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 14B88171537; Wed, 9 May 2012 12:57:32 +0100 (IST) Message-ID: <4FAA5B6D.5040208@cs.tcd.ie> Date: Wed, 09 May 2012 12:56:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E114F1DD400E@WSMSG3153V.srv.dir.telstra.com> <4F9E8055.1080209@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F23970AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2853D2C@WSMSG3153V.srv.dir.telstra.com> <4FA68A60.6030207@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F28540B5@WSMSG3153V.srv.dir.telstra.com> <4FA8EB06.4020004@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E114F2A1546E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2A1546E@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Indicating hash size in 'ni' URIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 11:57:43 -0000 Hiya, I think the main thing to keep in mind is that we don't want people to make the mistake of thinking two names are the same when they aren't. In other words a name with a 32 bit truncated sha-256 hash is not the same as a name with the full 256 bits of hash output, even if the hash value for one is a prefix of that for the other. The reason being that if an application treats those the same then that'd open up a bunch of attacks. For example, if I publish an object with the full hash, then I probably (in general) don't want some other application to treat a name with just the first 32 bits of that as referring to the same thing, since the 32 bit name will have lots of colliding objects. If this stuff gets used, there will be many cases where names will occur more than once in application protocols, and it'll be unpredictable which instance of the name will be used for name-data integrity checking. (Maybe we ought add a bit more security considerations text to explain that better, suggestions welcome.) Now, IMO, the syntax we have makes that mistake less likely, whereas your proposal makes it more likely to happen, due to developer carelessness or misunderstanding. We also have code [1] that implements the current syntax, so for us at least, we'd want to see a benefit to switching, and I only see a downside right now. That code is very early, so it's not a major major deal, but I'd not want to break stuff for fun, and given that we've implemented this in a bunch of languages, it'd be a chunk of work. (Developer enthusiasm, after many months of discussion and ppt engineering lead to a burst of coding activity resulting in c, ruby, java, php, python, clojure and a few application examples, including wget and curl all of which do the ni URI as per the current draft:-) On 05/09/2012 02:02 AM, Manger, James H wrote: >>>> I would still rather ditch the truncation length from the alg names. > >>> I'm with James on this one. >>> ... The example of a truncated stream cipher seems contrived to me. > >> Not to me. >> >> I think that omitting the size would mean that anyone using >> these would need to go think about potential truncation attacks, >> and having to do that is bad, since most times they won't do >> it at all and even if they do, those attacks, if they apply, >> will be likely be very subtle. So even if you try figure it >> out, you may not get the analysis right. Avoiding all that >> is just better IMO. > > I am trying to understand the truncation attacks you are concerned about. Would an example be an HTTPS web connection that abruptly stops mid stream? All the received TLS records are properly encrypted and have valid MACs. However, only half of the HTML page has been delivered: it might end "