From anthonybryan@gmail.com Sun Mar 3 00:41:53 2013 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 1304E21F8628 for ; Sun, 3 Mar 2013 00:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYfUvN2AjRa5 for ; Sun, 3 Mar 2013 00:41:52 -0800 (PST) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4943F21F8626 for ; Sun, 3 Mar 2013 00:41:52 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id s14so2895365qeb.11 for ; Sun, 03 Mar 2013 00:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=wCctMRquwvN1BnhZFWBmzYSnQ2gsWbSliMjXtOw64r8=; b=vmuSjB6SE+rxRajwUjzzGPvUEs+unJX6X8tgeUo9twd23mhfIEZdU8muwIv9eCfFC+ a34/rr2c0MpL1Q425XBbjzPklqM1aMbHCinS5ZJ+kxsPJCT8d67CyEGNm5oVwn2ibW5V JanHLwr/IWdcdBrDuUnMq6+zuK+6Gzbmer8jmGfNHQUf47dCTmA+40aX/Tnw5x5t8Lv8 EK5ehsXXF0SyVVnnY7jc/JYeE51SOiDcb3lA/KBJkRxlF42PtNLxeMFcowNUOIHKCZDI r/4vwzwAiYcgGFKICdS8boLHh/weNk4AF5QUd/w+/fWjf0X1JoluzLeI3L53ClP54UhX 67rw== MIME-Version: 1.0 X-Received: by 10.49.127.139 with SMTP id ng11mr27626679qeb.54.1362300111853; Sun, 03 Mar 2013 00:41:51 -0800 (PST) Received: by 10.49.71.140 with HTTP; Sun, 3 Mar 2013 00:41:51 -0800 (PST) Date: Sun, 3 Mar 2013 03:41:51 -0500 Message-ID: From: Anthony Bryan To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] more editing questions 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, 03 Mar 2013 08:41:53 -0000 RFC 5854 describes the Metalink/XML format but it only has the barest normative requirements for clients - but not all, hence this new draft on clients. http://tools.ietf.org/html/draft-bryan-metalink-client what's the best way to call attention to these, just quote them outright? "RFC 5854 introduced these requirements for Metalink clients, which are still in effect..."? we're not updating any requirements from RFC 5854, just adding more, but we'd like them all in the same place. we also have the FTP RANG command to specify a byte range. we use this with the HASH command, for partial file hashing. inside the RANG ID, we specify how it works with RETR & STOR (section 4) as well. RANG is well solidified on it's own, but we're still working on section 4. my question is, should we split section 4 into a separate ID so there's just RANG on it's own, with HASH and a "RANG with RETR/STOR" both depending on it. that seems like it would make RANG on it's own more simple. http://tools.ietf.org/html/draft-bryan-ftp-range http://tools.ietf.org/html/draft-bryan-ftpext-hash thanks, -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From frsyuki@gmail.com Mon Mar 4 00:01:21 2013 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 385B921F8868; Mon, 4 Mar 2013 00:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=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 E7ZdUKijPp0Y; Mon, 4 Mar 2013 00:01:20 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6121F886A; Mon, 4 Mar 2013 00:01:17 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so2426716dan.37 for ; Mon, 04 Mar 2013 00:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=esE5O15hpYl+P0Ek4vPjVxrX2iYE4w7pIYUDi9hdF+o=; b=lDgbbYAiR7E6PZDbE5G64dvzAEVspkzFaN7lT/UGkN+1rCkkvFfIAyN2XOQV0lmVaL fZty6zVLcvxM3oLI2FXt0Yt3KzYFgVqj7VP+BEfyK5aP6VK21ddx5McDtmkpKUfihDqc jaJTjs8/zTKM2aIkt70SxR12RgyuACv/JutfWJMprshsZd3k7ns5+SDkY03H1tHPHos5 vKXfOdYTB5En2fWtZq8JCkoA6jjzT/mqXFIeXMfFi1zNRXKIzKhrlHKzGVlZKkcw7Dxj iSXn17cO9Yd2VCKbzzXlPVXgOwaDeHra9m1QVakxVlmXLb+JKI/3wqC3/mwYTODAEobJ nOeg== X-Received: by 10.68.129.163 with SMTP id nx3mr27161899pbb.13.1362384076928; Mon, 04 Mar 2013 00:01:16 -0800 (PST) Received: from [192.168.1.2] (c-98-248-36-6.hsd1.ca.comcast.net. [98.248.36.6]) by mx.google.com with ESMTPS id ol7sm21486662pbb.14.2013.03.04.00.01.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 00:01:14 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sadayuki Furuhashi In-Reply-To: <85CB7BA1-2C92-4C52-A1C3-7FD430396725@tzi.org> Date: Mon, 4 Mar 2013 00:01:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <284DE42D-B03B-450D-865B-C2914D6C0681@gmail.com> References: <7EB82E7A-F664-46F8-8137-83DF0C3F5536@tzi.org> <85CB7BA1-2C92-4C52-A1C3-7FD430396725@tzi.org> To: "apps-discuss@ietf.org" , "json@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [apps-discuss] [Json] msgpack/binarypack (Re: JSON mailing list and BoF) 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, 04 Mar 2013 08:01:21 -0000 I'm frsyuki (Sadyuki Furuhashi). As the initial developer of the MessagePack specification, I am feeling = unrest in bringing MessagePack to IETF as an Internet-Draft at this very = moment. I don't against having a standard itself but I really have difficulty on = its downside: incompatibility. Because at least I already have hundreds TBs of data stored in = MessagePack format. And there're already many other users who don't expect incompatible = changes. Here is a list of users: (This list is quite old, though. There're more users now. You'll see the = list includes Pinterest, Redis, etc.) http://wiki.msgpack.org/display/MSGPACK/PoweredBy Thus compatibility is an essential problem of msgpack. So I can't help = opposing drafts which are incompatible with MessagePack. Another problem which makes this decision complicated is that we're = discussing on changing the msgpack spec. We'll likely add string or binary type to msgpack. = Prof. Dr. Bormann kindly joined us to help happening this change. But we have not updated = implementations based on the new spec yet. It's not validated by users. It means that we need to = disscuss about the change of spec, implement it in many languages, validate them on = production environments, and write documents. I don't think we can make them all happen soon, at = the same time. I don't against having a standard itself but we're not prepared to start = it now. However, even writing an individual Internet-Draft under my name is an our possible = option. Meaning that sooner or later, we'll have a document about the new MessagePack spec = (which includes the string/binary types). I can't commit the timing at this time, = though. We're focunsing on the new spec right now. Let me keep updated about discussion on our issue thread: https://github.com/msgpack/msgpack/issues/129 -- Sadayuki Furuhashi http://fluentd.org http://msgpack.org twitter:@frsyuki On 2013/02/24, at 5:11, Carsten Bormann wrote: >=20 > On Feb 19, 2013, at 17:39, Carsten Bormann wrote: >=20 >> On Feb 19, 2013, at 00:47, "Joe Hildebrand (jhildebr)" = wrote: >>=20 >>> As an individual, I'm +1 on that. I love msgpack, and don't mind = the >>> addition of UTF8 as a separate type. Was frsyuki involved in the = draft, >>> or at least know that it happened? >>=20 >> I tried to involve him. >=20 > Well, I did engage the msgpack community some more. >=20 > You can find a transcript of some 275 messages about separating byte = and UTF-8 strings at: >=20 > https://github.com/msgpack/msgpack/issues/121 >=20 > Summary: > Some members of the msgpack community are very enraged that this = change hasn't happened earlier. > Of course, some have gone off and done their own incompatible forks. > Others are very enraged that any change is happening at all, and that = new people are intruding on their turf. > (And some probably feel guilty that it took a ****storm from outside = to finally make this change.) >=20 > frsyuki is now working on a proposal that solves the problem: >=20 > https://gist.github.com/frsyuki/5022569 >=20 > The proposal is technically complete (and has already been = implemented). > It already is pretty good at the details, too, but this whole thing is = being done in a process that is closer to Japanese consensus processes = than to IETF culture. >=20 > My -01 will be fully aligned with whatever the state of frsyuki's = proposal will be on Monday's I-D deadline (find today's snapshot at = http://www.tzi.de/~cabo/draft-bormann-apparea-bpack-01pre2.txt). > (frsyuki's proposal may change some more, but those will in all = likelihood be minor details.) > I think his overall thinking is fine, but it is much more dominated by = a requirement for backwards compatibility than an IETF process would be. >=20 > So, the larger question on whether the msgpack community is ready to = take part (or just endure) in an IETF-style consensus process (including = handing over change control) still looms. >=20 > That doesn't diminish from the requirement for a msgpack-like format, = and I think we should use Hallway Time in Orlando to discuss potential = ways forward. >=20 > I any case, I definitely don't want to disturb the constructive = discussion about chartering a very narrow JSON fixup WG with this work. > (I do want to find a home for it, soon, though: I want to build other = specs on top of it.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From barryleiba.mailing.lists@gmail.com Mon Mar 4 09:04:16 2013 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 554CD21F85E0 for ; Mon, 4 Mar 2013 09:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.660, 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 irKnF4JH4499 for ; Mon, 4 Mar 2013 09:04:12 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBDF21F85DF for ; Mon, 4 Mar 2013 09:04:12 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jx10so4837545veb.39 for ; Mon, 04 Mar 2013 09:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=uccg4dBWxJNxAv+O2LLFjKwGZrigx795g0F/wtBDkVE=; b=wNsdYjdt2abVHoYB3pooIyy21tWQzzPk4Lrdv6Ge6KkQpOQFI9eR4u/qsS56TZPukV 1fXcgyOPGUs+/q2vjHZlI5PS5IAFZricOG+0Afj6EJuEMxQywfQl3xihFMQZqviwRavZ CiloQhzjzvZzbOn/zQ8kTQnYKPF6nWA0KUuM+/irC/kDg81ITX4rMotOhkZNzlPsEf5v gf6XOEsV9Hyg9hs9ieevM74Ua8fOzvWmDTpZpIpCQM5byPMttdX6bTHP/isoQVjvMRsS qHUsdeTitG92q6yjM8ew//Gp58qIGhSHyZaXKV3VuPPH7uwZXWcANZbeNg+n0aN//Fsc G5dA== MIME-Version: 1.0 X-Received: by 10.52.24.229 with SMTP id x5mr7018647vdf.84.1362416651442; Mon, 04 Mar 2013 09:04:11 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 4 Mar 2013 09:04:11 -0800 (PST) Date: Mon, 4 Mar 2013 12:04:11 -0500 X-Google-Sender-Auth: Btw4GPVSkYwy7uSF0ejlfaaFfiA Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Publication has been requested for draft-ietf-appsawg-webfinger 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, 04 Mar 2013 17:04:16 -0000 FYI, because I haven't seen anything posted here: Salvatore has requested publication of version -10 of the webfinger document: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ I am reviewing it now; the next step will be a two-week Last Call, followed by evaluation by the IESG. It will likely be scheduled on the 28 March IESG telechat. Barry, Applications AD From jhildebr@cisco.com Mon Mar 4 10:36:51 2013 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 E185E21F8DEE; Mon, 4 Mar 2013 10:36:51 -0800 (PST) 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 oKIcZ9dnIWC3; Mon, 4 Mar 2013 10:36:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3617821F8DEF; Mon, 4 Mar 2013 10:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2599; q=dns/txt; s=iport; t=1362422211; x=1363631811; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UaJ23J4UgoPOsu5rXadWVlP2WMbZYezZtRUaOKH73FI=; b=SqoDkwHbfwM1MmIybGKeSgkFEPxmiqV6VVu6XqyAFM2YEuqjj9OI4B6B dQqZHfLk1nz5haEzkpviU89zPoMBciTqeweULgPCPFMZHPGPG8or9q6Mz baltZX3LNQ17tYZ7duOmzbcfWdiRpTd5ohHWbN1Ec4Qo1OLVKDFZVnuIO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGLoNFGtJV2c/2dsb2JhbABEwlCBAhZzgiEBBDo0CxIBCA4UFDERJQIEAQ0FCAyHbQMPukUNiQaMRYIXMQeCX2EDkwOBZI0zhRiDCIIn X-IronPort-AV: E=Sophos;i="4.84,781,1355097600"; d="scan'208";a="183362163" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 04 Mar 2013 18:36:50 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r24IankS007933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 18:36:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 12:36:49 -0600 From: "Joe Hildebrand (jhildebr)" To: Sadayuki Furuhashi , "apps-discuss@ietf.org" , "json@ietf.org" Thread-Topic: [Json] msgpack/binarypack (Re: [apps-discuss] JSON mailing list and BoF) Thread-Index: AQHOGK6GjXC91KM//kqvccEDh6QfLJiVzFIA Date: Mon, 4 Mar 2013 18:36:49 +0000 Message-ID: In-Reply-To: <284DE42D-B03B-450D-865B-C2914D6C0681@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.129.24.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F48893120B9364CA34A46F04F7BF3A2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] [Json] msgpack/binarypack (Re: JSON mailing list and BoF) 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, 04 Mar 2013 18:36:52 -0000 On 3/4/13 1:01 AM, "Sadayuki Furuhashi" wrote: >I'm frsyuki (Sadyuki Furuhashi). > >As the initial developer of the MessagePack specification, I am feeling >unrest >in bringing MessagePack to IETF as an Internet-Draft at this very moment. > >I don't against having a standard itself but I really have difficulty on >its downside: incompatibility. (as individual) We had a similar unrest about bringing XMPP to the IETF the first time. We wrote very strict charter language about backward compatibility, and became highly involved in the process. It turned out to be a very positive experience on the whole. We got lots of reviews from folks that had not paid attention to XMPP before, including security, internationalization, and the clarity of our documentation. The current RFCs are so much better than we would have produced on our own that I can't imagine not having done the work, now. The authors from our community got credit in the RFCs for their work; there was no lack of respect for their previous efforts. Another reason why msgpack is interesting to consider for standardization is that I for one would like to use it as the wire protocol for standards-based protocols. In order to do this today, I would would probably need to do one of: - Include whatever subset of msgpack I want to use into the new protocols. This would be awful, because then each other protocol that wanted to use msgpack would need to do the same thing, and they would all choose slightly incompatible approaches. - Refer to your existing web page as the msgpack specification. This would be difficult to use as a "stable reference", since it doesn't come from a standards body with previously-vetted intellectual property rules, and we don't know how often it will change. - Invent something new that tried to solve the same problem, perhaps using a method that avoids reusing your work. This would be the worst possible outcome for the industry, since having two completely different approaches to the same problem is a recipe for years of incompatibility. I'm sorry if the communications you've had with people that participate in the IETF have made your community feel as if we're trying to take over your idea, have made you feel disrespected, or that we want to force backward-incompatibilities on you. At least from my personal point of view, your work to date has been exemplary, and it is a measure of my respect that I would like to help enable that work to be used by even more people. --=20 Joe Hildebrand From iesg-secretary@ietf.org Mon Mar 4 12:24:32 2013 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 B21DB21F8FCC; Mon, 4 Mar 2013 12:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 d+Ely3uPtN81; Mon, 4 Mar 2013 12:24:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBABA21F8EF9; Mon, 4 Mar 2013 12:24:24 -0800 (PST) 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.41 Message-ID: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2013 12:24:24 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (WebFinger) to Proposed Standard 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, 04 Mar 2013 20:24:33 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'WebFinger' as Proposed Standard 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 2013-03-18. 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 specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Mar 4 12:24:33 2013 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 E981521F8FD3 for ; Mon, 4 Mar 2013 12:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 sqZ6gyRBWHgh; Mon, 4 Mar 2013 12:24:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3821F8F08; Mon, 4 Mar 2013 12:24:30 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.41 X-IETF-Draft-string: draft-ietf-appsawg-webfinger X-IETF-Draft-revision: 10 Message-ID: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2013 12:24:30 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (WebFinger) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@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, 04 Mar 2013 20:24:33 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'WebFinger' as Proposed Standard 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 2013-03-18. 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 specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ No IPR declarations have been submitted directly on this I-D. From sm@elandsys.com Tue Mar 5 02:36:28 2013 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 D24D311E80F2 for ; Tue, 5 Mar 2013 02:36:28 -0800 (PST) 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 DGC2epRGEang for ; Tue, 5 Mar 2013 02:36:28 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5CB11E80F0 for ; Tue, 5 Mar 2013 02:36:28 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.90]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r25AaEVc019058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Mar 2013 02:36:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362479786; bh=5OeBt3NyvsB+Q93guZBe5W8pllwQmz8CwLZ2Yq3L8gY=; h=Date:To:From:Subject; b=sC8OvD9ieD4euJ4kmiW2X4pghSrmXFnGU6oQnROry4kf+1tOXzxXF63WQM2iDk2xQ hKo4v6BXCGugi08+K3RpbS4xsC17WAmSEcCGYdRUYba8aXnePeAKs93gRLWY5+46ZB W1VL5N1tcXOV4q8NQOCu24lBzQOei95pwm5N0TaI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1362479786; i=@elandsys.com; bh=5OeBt3NyvsB+Q93guZBe5W8pllwQmz8CwLZ2Yq3L8gY=; h=Date:To:From:Subject; b=DO6NTeKjRNUBXL9OP2tUV4KQoAXS2+GFDhcdafTcMBKszm1v97hUdY5GTxGV25q/k +zeMhfCIUnGyjyxaz2nGbCnm1vOkeKDOrneEyLj5U1MLtrKSTnPe8oHAoLSsTpMFm4 jLTkLg5TSvck8wKOQ2xi0NLYtw8qbfz/LjLBOcS8= Message-Id: <6.2.5.6.2.20130305020245.0cb9cb60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Mar 2013 02:31:25 -0800 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 February 2013 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, 05 Mar 2013 10:36:28 -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. The following reviews were performed in February 2013: Reviewer I-D S. Moonesamy draft-gp-obsolete-icmp-types-iana-01 Jiankang Yao draft-shafranovich-mime-sql-03 Joseph Yee draft-ietf-mpls-tp-use-cases-and-design-06 S. Moonesamy draft-harkins-brainpool-ike-groups-04 Yoshiro Yoneya draft-ietf-mpls-tp-security-framework-08 Vijay K. Gurbani draft-ietf-mmusic-sdp-cs-17 Salvatore Loreto draft-ietf-simple-simple-08 Claudio Allocchio draft-ietf-xrblock-rtcp-xr-summary-stat-08 Peter Saint-Andre draft-leiba-urnbis-ietf-namespace-02 Murray S. Kucherawy draft-templin-ironbis-12 Xiaodong Lee stepped down from the Applications Area Directorate. I would like to thank him for sharing his expertise through the reviews he performed. The directorate needs more reviewers. The tasks of the directorate are listed on the web page at http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate There is a list of reviews which have been performed at http://trac.tools.ietf.org/area/app/trac/wiki/tracker I would like to encourage anyone reading this message to contact me if the person can contribute by performing reviews. If you have any questions feel free to ask me. Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From alexey.melnikov@isode.com Tue Mar 5 07:02:20 2013 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 10AE321F89A5 for ; Tue, 5 Mar 2013 07:02:20 -0800 (PST) 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.001, 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 bpNO4khIiAZ0 for ; Tue, 5 Mar 2013 07:02:19 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0101321F89A4 for ; Tue, 5 Mar 2013 07:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1362495738; d=isode.com; s=selector; i=@isode.com; bh=NTsq5jNYrQ4DTz3+Q/dvv/BbhowGU7oeq3IISfWUduw=; 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=qYgBs8WEaz68R6VPX6EBMScw05yYGdRgbI//iMvbsh+HtCTfph43r19zPcZFeU1vJQnBUi VNBD3iTMKz/R7o9Ti/H30to7bXWyJE/DckMOLXFzGKw/mIfyuL7fTUcqam4gyXth3BQjOx 70ZqinkLGn6UQ1b2bz1S8MHJ+sY4FFE=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 5 Mar 2013 15:02:17 +0000 Message-ID: <513608FB.8080006@isode.com> Date: Tue, 05 Mar 2013 15:02:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "apps-discuss@ietf.org" References: <513607D5.4090808@isode.com> In-Reply-To: <513607D5.4090808@isode.com> X-Forwarded-Message-Id: <513607D5.4090808@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020906040304060803070800" Subject: [apps-discuss] Fwd: Proposal for a new IMAP Working Group to revise CONDSTORE & QRESYNC 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, 05 Mar 2013 15:02:20 -0000 This is a multi-part message in MIME format. --------------020906040304060803070800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've posted a proposal for a new IMAP-related WG. If you are interested in the topic, please follow-up on imapext@ietf.org. Thank you, Alexey -------- Original Message -------- Subject: Proposal for a new IMAP Working Group to revise CONDSTORE & QRESYNC Date: Tue, 05 Mar 2013 14:57:25 +0000 From: Alexey Melnikov To: imapext@ietf.org Hi, I've noticed some surge in activity related to implementing CONDSTORE (RFC 4551)/QRESYNC (RFC 5162) in both clients and servers, so I drafted a new WG charter proposal to update/clarify these: ----------- The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for accessing email messages on a server that implements a message store from a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another. Base IMAP as described in RFC 3501 requires that in order to discover flag changes and expunged messages in a mailbox, the client has to fetch flags for all messages it knows in the mailbox and compare returned results with its own state. This can generate a significant amount of traffic for big mailboxes. The IMAP CONDSTORE extension (RFC 4551) provides a facility for IMAP clients to quickly resynchronize mailbox flag changes in a mailbox. The IMAP QRESYNC extension (RFC 5162) extended CONDSTORE to also cover expunged messages and reduced the number of round trips needed to resynchronize by extending the SELECT/EXAMINE command. Both extensions seen deployment in both clients and servers. These deployments has exposed errors and clarity issues in the specifications, which need correcting. The IMAP QRESYNC extension (imapqresync) working group has the task of updating CONDSTORE and QRESYNC extensions as Proposed Standards. The working group might produce one (combined) or two separate documents (as now) updating these extensions. The working group will review errata and update the documents as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes at this stage to a minimum. In the event that implementation experience would dictate an incompatible change to one (or both) of these extensions, the corresponding IMAP capability identifiers would be changed. No other IMAP extension work is in scope for this working group. --------- So please comment on whether you think this work is worth doing and on the proposed charter text. I've also posted a new version of RFC 5162bis (http://tools.ietf.org/html/draft-melnikov-5162bis-01), which addressed most (but not all) of existing errata on the document. If a new WG is to be formed, I propose that the document is used as one of the initial documents. Thank you, Alexey --------------020906040304060803070800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,
I've posted a proposal for a new IMAP-related WG. If you are interested in the topic, please follow-up on imapext@ietf.org.

Thank you,
Alexey

-------- Original Message --------
Subject: Proposal for a new IMAP Working Group to revise CONDSTORE & QRESYNC
Date: Tue, 05 Mar 2013 14:57:25 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: imapext@ietf.org <imapext@ietf.org> 


Hi,
I've noticed some surge in activity related to implementing CONDSTORE 
(RFC 4551)/QRESYNC (RFC 5162) in both clients and servers, so I drafted 
a new WG charter proposal to update/clarify these:

-----------
The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for accessing email messages on a server
that implements a message store from a client. It also includes
commands for manipulating the message store -- creating, deleting, and
renaming mailboxes, adding a message to a mailbox, and copying
messages from one mailbox to another.

Base IMAP as described in RFC 3501 requires that in order to discover
flag changes and expunged messages in a mailbox, the client has to
fetch flags for all messages it knows in the mailbox and compare returned
results with its own state. This can generate a significant amount of
traffic for big mailboxes.

The IMAP CONDSTORE extension (RFC 4551) provides a facility for IMAP
clients to quickly resynchronize mailbox flag changes in a mailbox.
The IMAP QRESYNC extension (RFC 5162) extended CONDSTORE to also
cover expunged messages and reduced the number of round trips needed
to resynchronize by extending the SELECT/EXAMINE command.
Both extensions seen deployment in both clients and servers.
These deployments has exposed errors and clarity issues in the
specifications, which need correcting.

The IMAP QRESYNC extension (imapqresync) working group has the task
of updating CONDSTORE and QRESYNC extensions as Proposed Standards.
The working group might produce one (combined) or two separate
documents (as now) updating these extensions. The working group will
review errata and update the documents as needed to incorporate those,
and will correct significant errors and inconsistencies, but will keep
changes at this stage to a minimum. In the event that implementation
experience would dictate an incompatible change to one (or both) of
these extensions, the corresponding IMAP capability identifiers would
be changed.

No other IMAP extension work is in scope for this working group.
---------

So please comment on whether you think this work is worth doing and on 
the proposed charter text.

I've also posted a new version of RFC 5162bis 
(http://tools.ietf.org/html/draft-melnikov-5162bis-01), which addressed 
most (but not all) of existing errata on the document. If a new WG is to 
be formed, I propose that the document is used as one of the initial 
documents.

Thank you,
Alexey



--------------020906040304060803070800-- From sm@elandsys.com Tue Mar 5 08:14:03 2013 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 84CDC21F8573 for ; Tue, 5 Mar 2013 08:14:03 -0800 (PST) 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 WOEkH3hSB0E6 for ; Tue, 5 Mar 2013 08:14:03 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5E521F8570 for ; Tue, 5 Mar 2013 08:14:02 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.90]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r25GDgr2006564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Mar 2013 08:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362500036; bh=cYnNZ1hjfZl885nRiv31IRFMdlgtYTyHHUYaocpu28g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3OmEh81rFatfBW/emTa37i2oZAFnz1zFud4GP4jDL0nT73+uSQHj9qcrYTBSoNrrD PC3oOXYdDrEW2kfR5sJ5HneL+gNBASka0a113jiKvvjR/vCyieBLTst//KKNkSEVrC tpceIK6pkmzHobu/BfDT+8ZS5e4bel7r7BSAYK4s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1362500036; i=@elandsys.com; bh=cYnNZ1hjfZl885nRiv31IRFMdlgtYTyHHUYaocpu28g=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DNc8dhMJmZyGlQOPWWI8xcDKxak3tO2wRsat9AVFoEmtHiRSFELzbdcf/38UgVrmi pNe8zj6+zw80cotSaAmaBGAYwqFX0M1Ws6tprX1Su77gklqLRPkxZRoYB+FO08Zi7H GJHSX7zTR3kIPWRZcAW0bfg/Hc8a4QL/so2OXAfk= Message-Id: <6.2.5.6.2.20130305073104.0a0e9f40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Mar 2013 07:41:34 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20130305020245.0cb9cb60@elandnews.com> References: <6.2.5.6.2.20130305020245.0cb9cb60@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Apps Area Directorate report for February 2013 (correction) 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, 05 Mar 2013 16:14:03 -0000 Hello, I forgot to list the Applications Area directorate review of draft-ietf-ospf-rfc3137bis-03 which Dave Cridland performed on February 2 and the Applications Area directorate review of draft-ietf-geopriv-dhcp-lbyr-uri-option-17 which Yves Lafon performed on February 5. I apologize for the mistake. Regards, S. Moonesamy From ithinkihaveacat@gmail.com Wed Mar 6 14:08:03 2013 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 121CD11E8142 for ; Wed, 6 Mar 2013 14:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, 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 GuC9et5RMwVz for ; Wed, 6 Mar 2013 14:08:02 -0800 (PST) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id E007B21F89D8 for ; Wed, 6 Mar 2013 14:08:00 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id w21so1561486iac.13 for ; Wed, 06 Mar 2013 14:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=Vxb0iYGad/56Q5/bXPb9PmR68Sqm7qIlD9q+tZJgN+s=; b=HZFHSwmmdAAsPre4ymLQi+T/mbLT2jA9cozV6xZCTr0UDWZE6p4cWTcXX2jIFynGx1 oztNDKjfyevXfWyq3qUAK7wiMSoqos6c0uZ4UGIbkyndws0m8ZopvHr1jqr1TuSTE0WU emexyKwN2vZwV6+BoMe+yXcYviYB61RoIEPRTqLjxuqa0METDF1e/NAkBSCIpdwbbMKP fABX+aHzgpZaDorQi02MXbtDaQ7yuOYPMtRr9GX3mwA5wOhzf95YTw2aEYwpnYJd1QwM up5rmLv6kbuP1NTD2Dh/TKupfa4egYoU4Dg/YGB1cMaiEXxxvBzr4mXE5+e57VUFysx4 mltw== MIME-Version: 1.0 X-Received: by 10.42.140.72 with SMTP id j8mr32127137icu.37.1362607676302; Wed, 06 Mar 2013 14:07:56 -0800 (PST) Sender: ithinkihaveacat@gmail.com Received: by 10.64.97.195 with HTTP; Wed, 6 Mar 2013 14:07:56 -0800 (PST) Date: Wed, 6 Mar 2013 22:07:56 +0000 X-Google-Sender-Auth: VPcORuC2XjOOU2h9aTpTWaBettI Message-ID: From: Michael Stillwell To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: mnot@mnot.net, erik.wilde@emc.com Subject: [apps-discuss] draft-nottingham-http-problem 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, 06 Mar 2013 22:09:54 -0000 Some questions/thoughts on the "Problem Details for HTTP APIs" draft: http://tools.ietf.org/html/draft-nottingham-json-home-02 The existing approach to handling problems seems to be for clients to assume that the combination of a URL (or just domain), a status code, and a media type determines the type of the body. So clients will interpret { flickr.com, 4xx, application/json } in one way, and { twitter.com, 4xx, application/json } in another. The draft seems to suggest in effect moving the domain name into the body of the document itself to form a sort of namespace (i.e. as the problemType key), so that error types can be shared between different services. But I'm wondering just how much sharing is actually possible in practice. (This question also applies to the similar vnd.error proposal https://github.com/blongden/vnd.error.) An example from the draft is an "out-of-credit" error, but thinking through the various sorts of "out-of-credit" messages I actually receive, and how I go about remedying the problem (from phone companies, hosting providers, public transport providers), I can't think of very much they share, and certainly very little that would be able to be acted upon in an automated way that did not require knowledge of the service that generated them. (I'm assuming that part of the point of the proposal is to establish better mechanisms for programmatically dealing with and reporting problems--if the problem reports were going to be interpreted by humans then you could simply return text/html with whatever body you wanted.) Section 4.1 suggests that more complicated domains would be better served by application-specific formats, and this seems reasonable, although I don't think I've ever seen such a thing. So a problem with a financial transaction might warrant a special problem format defined by some banking organisation. (Though I suppose extremely complicated domains (mortgage application?) might also return a 201 or 202 status, and put the actual "error" report somewhere else.) But there doesn't seem to be much of a meaningful gap between "complicated" domains that could do with their own problem media type, and domains where the existing { domain, status, media type } triple approach works out just fine. Cheers, Michael From dret@berkeley.edu Wed Mar 6 14:34:22 2013 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 0680521F8659 for ; Wed, 6 Mar 2013 14:34:22 -0800 (PST) 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_35=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 wQzIubwaMmpO for ; Wed, 6 Mar 2013 14:34:21 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3879A21F861F for ; Wed, 6 Mar 2013 14:34:21 -0800 (PST) Received: from mobile-166-137-186-172.mycingular.net ([166.137.186.172] helo=dretpro.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UDMug-0008Ux-5b; Wed, 06 Mar 2013 14:34:20 -0800 Message-ID: <5137C467.90805@berkeley.edu> Date: Wed, 06 Mar 2013 14:34:15 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Michael Stillwell References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mnot@mnot.net, Dmitry Limonov , erik.wilde@emc.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem 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, 06 Mar 2013 22:34:22 -0000 hello michael. On 2013-03-06 14:07 , Michael Stillwell wrote: > Some questions/thoughts on the "Problem Details for HTTP APIs" draft: > http://tools.ietf.org/html/draft-nottingham-json-home-02 > The existing approach to handling problems seems to be for clients to > assume that the combination of a URL (or just domain), a status code, > and a media type determines the type of the body. So clients will > interpret { flickr.com, 4xx, application/json } in one way, and { > twitter.com, 4xx, application/json } in another. why do you assume this is the case? HTTP status codes are defined by HTTP, and they always mean the same for all HTTP interactions, regardless of the domain or anything else. if you get a 404, then it means what http://tools.ietf.org/html/rfc2616#section-10.4.5 says it means, not less and not more. > The draft seems to suggest in effect moving the domain name into the > body of the document itself to form a sort of namespace (i.e. as the > problemType key), so that error types can be shared between different > services. But I'm wondering just how much sharing is actually > possible in practice. (This question also applies to the similar > vnd.error proposal https://github.com/blongden/vnd.error.) the idea here is that services have the opportunity to provide supplemental information *beyond* the HTTP status code. so yes, this supplemental information is now runtime information (i.e., not part of HTTP's standard status codes). whether it is *shared* is a different issue; it would also be perfectly fine if services always define their own problemType URIs, simply for the purpose of providing some information that goes beyond what they can communicate through HTTP's standard status codes. sharing of problemType URIs is optional, but it sounds like something that may make a lot of sense. for example, when some software is deployed, it may choose to always use canonical URIs when sending HTTP problem details. clients now could use those problemType URIs to respond to these specific errors in a more specific way than to just the vanilla HTTP response. > An example from the draft is an "out-of-credit" error, but thinking > through the various sorts of "out-of-credit" messages I actually > receive, and how I go about remedying the problem (from phone > companies, hosting providers, public transport providers), I can't > think of very much they share, and certainly very little that would be > able to be acted upon in an automated way that did not require > knowledge of the service that generated them. you have a point here, but you could also simply consider the case of some specific software product always using the same problemType URI for its "out-of-credit" error, and then at least all services based on that specific software product would share the same problemType URI. does this explanation sounds reasonbale to you? cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From ithinkihaveacat@gmail.com Wed Mar 6 17:06:35 2013 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 68F1521F874B for ; Wed, 6 Mar 2013 17:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FKdRG9hVI8gP for ; Wed, 6 Mar 2013 17:06:34 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 84C1821F84B8 for ; Wed, 6 Mar 2013 17:06:34 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so10420034iea.33 for ; Wed, 06 Mar 2013 17:06:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Iat5uG7YAO40wbcHW4psqvMpw7Ajj8T/FQSHz7JRuMk=; b=Zsphd7ZVzPduFYHVs+Ni+/rWqQpJgC3y2JlmVhNGjjknId7V0OaD/WA+CZtZmPeyQQ C/Uw4HytuhWlssu4soURkuRpWhtjeXU6Ioe8JWbgjK0fHnTEVdeuFEd8idakiGGbZ/wk /72dKB/0xQ4Wh/NGZPvbkjXOmG80AqE2+Angb54aHjzl5zGN30u4KuztCgH3djA+VF2b P4TYje/LJMNpf4KZs/jKuaLjrgONWITN+9YWnmnqgdweyQXv3HDc5i3nMl75mzZl5b5I Mjusl2GKzQrfpX7wgOSNTH1Ae/B58w69LZErzrbtI5IynVvU2uS2fH91blfFt0NeLr8p AxLw== MIME-Version: 1.0 X-Received: by 10.50.156.133 with SMTP id we5mr13054468igb.51.1362618394145; Wed, 06 Mar 2013 17:06:34 -0800 (PST) Sender: ithinkihaveacat@gmail.com Received: by 10.64.97.195 with HTTP; Wed, 6 Mar 2013 17:06:33 -0800 (PST) In-Reply-To: <5137C467.90805@berkeley.edu> References: <5137C467.90805@berkeley.edu> Date: Thu, 7 Mar 2013 01:06:33 +0000 X-Google-Sender-Auth: kxph4hm5eR6NeuoOlIhSS__-S8g Message-ID: From: Michael Stillwell To: Erik Wilde Content-Type: text/plain; charset=ISO-8859-1 Cc: mnot@mnot.net, Dmitry Limonov , erik.wilde@emc.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem 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, 07 Mar 2013 01:06:35 -0000 Hiya Erik, Thanks for your reply. On Wed, Mar 6, 2013 at 10:34 PM, Erik Wilde wrote: > On 2013-03-06 14:07 , Michael Stillwell wrote: >> >> Some questions/thoughts on the "Problem Details for HTTP APIs" draft: >> http://tools.ietf.org/html/draft-nottingham-http-problem-03 >> The existing approach to handling problems seems to be for clients to >> assume that the combination of a URL (or just domain), a status code, >> and a media type determines the type of the body. So clients will >> interpret { flickr.com, 4xx, application/json } in one way, and { >> twitter.com, 4xx, application/json } in another. > > why do you assume this is the case? HTTP status codes are defined by HTTP, > and they always mean the same for all HTTP interactions, regardless of the > domain or anything else. if you get a 404, then it means what > http://tools.ietf.org/html/rfc2616#section-10.4.5 says it means, not less > and not more. Ah to clarify this point, all I mean is that under existing practice, if clients get a response with a 4xx status code, and a media type of application/json, how they process that response varies according to the domain it came from. So I'm not saying that the response can redefine the 428 status code to mean "image does not contain picture of a cat"--but I think it can contain machine-readable information that explains how to satisfy the failed precondition. > the idea here is that services have the opportunity to provide supplemental > information *beyond* the HTTP status code. so yes, this supplemental > information is now runtime information (i.e., not part of HTTP's standard > status codes). whether it is *shared* is a different issue; it would also be > perfectly fine if services always define their own problemType URIs, simply > for the purpose of providing some information that goes beyond what they can > communicate through HTTP's standard status codes. > > sharing of problemType URIs is optional, but it sounds like something that > may make a lot of sense. for example, when some software is deployed, it may > choose to always use canonical URIs when sending HTTP problem details. > clients now could use those problemType URIs to respond to these specific > errors in a more specific way than to just the vanilla HTTP response. Maybe an example of the Github API can better illustrate some of the problems of both sharing and not sharing problemType URIs that I'm worrying about. Github's API docs nicely explain how to interpret a their 422 status code: http://developer.github.com/v3/#client-errors And so, under the draft, instead of returning "application/json" (I'm assuming that's what they're returning, they don't actually say), they would return "application/api-problem+json" (or switch between the two via conneg). They then need to decide whether to use their own, or a shared, problemType. If they used their own, then clients would need to be Github-specific, and so this doesn't seem to have much benefit over just returning "application/json" in the first place and having clients behave differently based on (in effect) the github.com domain name. Conversely, whilst it would be nice if Github were able to share a problemType with other services, I don't think this is easily achievable. For example if a field is marked as "invalid", you need to read the docs to figure out what's wrong (too long? not a number?)--the problem detail provides no way to programmatically suggest corrections or fix the request. It could be enhanced to provide more useful information, but it's difficult to imagine even a "create-account" or "add-to-basket" problem details being shared across services like Amazon, Google, Facebook, and eBay. Each of these services has different constraints, and will have service-specific ways of failing, and so will need different problemTypes. Non-shared problemTypes mean non-shared clients, and so we're back where we started! Cheers, Michael From mnot@mnot.net Thu Mar 7 06:45:24 2013 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 CC75621F8D87 for ; Thu, 7 Mar 2013 06:45:24 -0800 (PST) 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 QnyqEmPq4Jye for ; Thu, 7 Mar 2013 06:45:24 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6421F8D85 for ; Thu, 7 Mar 2013 06:45:23 -0800 (PST) Received: from [10.0.251.33] (unknown [195.99.168.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BBA11509B8; Thu, 7 Mar 2013 09:45:21 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Thu, 7 Mar 2013 14:45:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5137C467.90805@berkeley.edu> To: Michael Stillwell X-Mailer: Apple Mail (2.1499) Cc: Dmitry Limonov , erik.wilde@emc.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem 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, 07 Mar 2013 14:45:24 -0000 On 07/03/2013, at 1:06 AM, Michael Stillwell wrote: > Hiya Erik, >=20 > Thanks for your reply. >=20 > On Wed, Mar 6, 2013 at 10:34 PM, Erik Wilde wrote: >=20 >> On 2013-03-06 14:07 , Michael Stillwell wrote: >>>=20 >>> Some questions/thoughts on the "Problem Details for HTTP APIs" = draft: >>> http://tools.ietf.org/html/draft-nottingham-http-problem-03 >>> The existing approach to handling problems seems to be for clients = to >>> assume that the combination of a URL (or just domain), a status = code, >>> and a media type determines the type of the body. So clients will >>> interpret { flickr.com, 4xx, application/json } in one way, and { >>> twitter.com, 4xx, application/json } in another. >>=20 >> why do you assume this is the case? HTTP status codes are defined by = HTTP, >> and they always mean the same for all HTTP interactions, regardless = of the >> domain or anything else. if you get a 404, then it means what >> http://tools.ietf.org/html/rfc2616#section-10.4.5 says it means, not = less >> and not more. >=20 > Ah to clarify this point, all I mean is that under existing practice, > if clients get a response with a 4xx status code, and a media type of > application/json, how they process that response varies according to > the domain it came from. >=20 > So I'm not saying that the response can redefine the 428 status code > to mean "image does not contain picture of a cat"--but I think it can > contain machine-readable information that explains how to satisfy the > failed precondition. Right. This just provides them a way to do that, without having to = invent a new format each time. I've seen APIs that define lots of new = error media types, something that's nasty and heavyweight.=20 >=20 >> the idea here is that services have the opportunity to provide = supplemental >> information *beyond* the HTTP status code. so yes, this supplemental >> information is now runtime information (i.e., not part of HTTP's = standard >> status codes). whether it is *shared* is a different issue; it would = also be >> perfectly fine if services always define their own problemType URIs, = simply >> for the purpose of providing some information that goes beyond what = they can >> communicate through HTTP's standard status codes. >>=20 >> sharing of problemType URIs is optional, but it sounds like something = that >> may make a lot of sense. for example, when some software is deployed, = it may >> choose to always use canonical URIs when sending HTTP problem = details. >> clients now could use those problemType URIs to respond to these = specific >> errors in a more specific way than to just the vanilla HTTP response. >=20 > Maybe an example of the Github API can better illustrate some of the > problems of both sharing and not sharing problemType URIs that I'm > worrying about. >=20 > Github's API docs nicely explain how to interpret a their 422 status = code: >=20 > http://developer.github.com/v3/#client-errors >=20 > And so, under the draft, instead of returning "application/json" (I'm > assuming that's what they're returning, they don't actually say), they > would return "application/api-problem+json" (or switch between the two > via conneg). They then need to decide whether to use their own, or a > shared, problemType. >=20 > If they used their own, then clients would need to be Github-specific, > and so this doesn't seem to have much benefit over just returning > "application/json" in the first place and having clients behave > differently based on (in effect) the github.com domain name. The benefit is that they don't have to invent their own JSON structure, = get the right semantics for it, etc. etc. Is that a huge benefit? Not = really, but it helps.=20 > Conversely, whilst it would be nice if Github were able to share a > problemType with other services, I don't think this is easily > achievable. For example if a field is marked as "invalid", you need > to read the docs to figure out what's wrong (too long? not a > number?)--the problem detail provides no way to programmatically > suggest corrections or fix the request. It could be enhanced to > provide more useful information, but it's difficult to imagine even a > "create-account" or "add-to-basket" problem details being shared > across services like Amazon, Google, Facebook, and eBay. Each of > these services has different constraints, and will have > service-specific ways of failing, and so will need different > problemTypes. Non-shared problemTypes mean non-shared clients, and so > we're back where we started! Not quite, but yes, this won't end world hunger. It's a small thing, the = real focus is giving help to people who invent their own error formats = and trip up in the process (some of the things I've seen really raise = the eyebrows, and people spend a *lot* of time trying to get these = things right). Cheers, -- Mark Nottingham http://www.mnot.net/ From fgaliegue@gmail.com Fri Mar 8 07:32:02 2013 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 BD81C21F85DB for ; Fri, 8 Mar 2013 07:32:02 -0800 (PST) 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 mCaNRETYovzw for ; Fri, 8 Mar 2013 07:31:58 -0800 (PST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7285C21F85DA for ; Fri, 8 Mar 2013 07:31:58 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id h10so238366eaj.7 for ; Fri, 08 Mar 2013 07:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hOiKNsLXzmTDILviSlRMPv4e5x3w7nkb8/PX8Yi0bNs=; b=iFcLSN3rXLUkXs0CoN2A07xZHVqXjR83BHPA/bvV4n9Lvz1a1gUeX4DoHnO5ZuD1BA nc5qPLBPSPVpPznKFPeONxRGUly4FKFBjs+WOElQYizWQ02gg471BzVnbJoRoJdvhT16 8ZBqP+Nvm0qM7w8L+jVpG6SIghjvFCv6H/9dCAzwtlJtXg5n8sHZBEJYAp91dBaRNe6+ +VOKhAgMY3j2+mZH8XnNwzKsrKcwrGuUNbSVDlx33+2nuFpV8iPtNFIIOio4zXa8oZoU Se5286zeHxJYeQP0ubWjpLqXemKKJgvrRw4Nemt5nv0H1yE3FVte/UwAxnEWf7CL3EYM tEuA== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr6607405eeo.26.1362756717537; Fri, 08 Mar 2013 07:31:57 -0800 (PST) Received: by 10.14.1.7 with HTTP; Fri, 8 Mar 2013 07:31:57 -0800 (PST) Date: Fri, 8 Mar 2013 16:31:57 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 15:32:02 -0000 Hello, I am writing an implementation of JSON Patch. Reference document: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 The question is about the remove operation (section 4.2). The text says that the target location must exist for the operation to succeed, which is pretty normal. But what if the target location is the document itself? Ie, { "op": "remove", "path": "" } It really means that the resulting document is, well, nothing, not even a JSON null. Or am I missing something? Shouldn't the empty JSON Pointer be forbidden? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Fri Mar 8 08:34:50 2013 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 37FD321F8838 for ; Fri, 8 Mar 2013 08:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 c7CSxdQkhh9u for ; Fri, 8 Mar 2013 08:34:45 -0800 (PST) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5F121F882A for ; Fri, 8 Mar 2013 08:34:45 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id e49so1123547eek.5 for ; Fri, 08 Mar 2013 08:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=l5Fu5KN65Qx5vlLj9hftWBXafEBQIZ6FwIuhI6ggXKI=; b=oX5+OxidLuMdnZb07EfO2KL8xkq8dsCDTydDYN8/6pBsazDcD7aVVuJc1Vh1VxL61y YcAU9a94ggLOr4Sp0lWqldhrwFBWjncCcgsZ+B3F1VGVrd+ePaxEpeFJDwqWpqM323DB XKCGoILtWqR1Ob06S4kU0fxv3IJr/C/pVUHxhSGP0qHFZzFwJpsPgbrha/7zeMP7Wr4e Zbj2aFOnSruoI/zvfmPSRxZlIaPaMS7nPA8H79cu/OdvHrBhEsk0oLwVjWEKFWfA9Wnl 3PxfzLt2ATp6W3FGOh2wXkfAkFu1JsfwOlXvkApPm0jMPscVqZKITq7Q9ttomDRFUwiB Lt3Q== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr7174861een.37.1362760484453; Fri, 08 Mar 2013 08:34:44 -0800 (PST) Received: by 10.14.1.7 with HTTP; Fri, 8 Mar 2013 08:34:44 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Mar 2013 17:34:44 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 16:34:50 -0000 On Fri, Mar 8, 2013 at 4:31 PM, Francis Galiegue wrote: > Hello, > > I am writing an implementation of JSON Patch. Reference document: > > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 > > The question is about the remove operation (section 4.2). > Well, I have another question about, this time, the move operation. Say we have this data: [ "victim", {}, {} ] and this patch: { "op": "move", "from": "/0", "to": "/1/x" } The text says: This operation is functionally identical to a "remove" operation on the "from" location, followed immediately by an "add" operation at the target location with the value that was just removed. So, does this mean that the result of the above should be: [ {}, { "x": "victim" } ] or is it: [ { "x": "victim" }, {} ] ? If it is the first one, then it means that { "op": "move", "from": "/0", "to": "/2/x" } will fail. But on the other hand, this: { "op": "move", "from": "/0", "to": "/0/x" } while forbidden, would theoretically work... -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From fgaliegue@gmail.com Fri Mar 8 08:39:13 2013 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 9CE4D21F85B4 for ; Fri, 8 Mar 2013 08:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 apBX77XS3S-G for ; Fri, 8 Mar 2013 08:39:09 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 672A221F85A1 for ; Fri, 8 Mar 2013 08:39:09 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d41so1124120eek.36 for ; Fri, 08 Mar 2013 08:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=/JRA71Qqe0P2TpH8RTlCAzxbA/9aqmcvG6rprWHrqkk=; b=FJE0ho7cDsRQElMWzyozXeSwnaZpgHS0tJsfzla4qwcyKNVutPLk21aBbQWOtP5k9P Hhfja3iuZ9yUZ7s8Lupg7vilF8OEn0HJLFi7jozarxmG2U/m2E63GzIWILyW8MdOVL6W 9neHpeG9QebdbE5e48IXvnI/KxiJ/mOPdZwgNuxZM4DeB9wat2oJGg9Fshh0vVnhMJZO mtVGna3jX7EGyfmcKEoLFHwho6U4TPlZoCs++gzPjdO087rAOGBVanvpmy9ZMlAkoNA6 ZPH+ZAl6ubizSKnOt+28O7A7aEseTh9vkzxztrzo+x0RYW/jK0ClurfotO5wVrgnvDTJ 2Sew== MIME-Version: 1.0 X-Received: by 10.14.205.68 with SMTP id i44mr7232277eeo.25.1362760748448; Fri, 08 Mar 2013 08:39:08 -0800 (PST) Received: by 10.14.1.7 with HTTP; Fri, 8 Mar 2013 08:39:08 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Mar 2013 17:39:08 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 16:39:13 -0000 On Fri, Mar 8, 2013 at 5:34 PM, Francis Galiegue wrote: > On Fri, Mar 8, 2013 at 4:31 PM, Francis Galiegue wrote: >> Hello, >> >> I am writing an implementation of JSON Patch. Reference document: >> >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 >> >> The question is about the remove operation (section 4.2). >> > > Well, I have another question about, this time, the move operation. > [snip] Sorry for the mishaps. "to" should read "path" in all examples, of course. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From pbryan@anode.ca Fri Mar 8 09:56:17 2013 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 3343921F849A for ; Fri, 8 Mar 2013 09:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsZLQLOkY4ce for ; Fri, 8 Mar 2013 09:56:13 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADB221F86A1 for ; Fri, 8 Mar 2013 09:56:13 -0800 (PST) Received: from [10.126.22.27] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id DD4E46C81; Fri, 8 Mar 2013 17:56:11 +0000 (UTC) From: "Paul C. Bryan" To: Francis Galiegue In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-ed3O/9MTY2aBnGy4bdOF" Date: Fri, 08 Mar 2013 09:56:09 -0800 Message-ID: <1362765369.22220.9.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 17:56:17 -0000 --=-ed3O/9MTY2aBnGy4bdOF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I consider it to have no value, not even null, i.e. not exist. The intent was to make it possible to subsequently insert a value at the root level successfully, as well as to support the semantics of the "replace" operation. Paul On Fri, 2013-03-08 at 16:31 +0100, Francis Galiegue wrote: > Hello, > > I am writing an implementation of JSON Patch. Reference document: > > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 > > The question is about the remove operation (section 4.2). > > The text says that the target location must exist for the operation to > succeed, which is pretty normal. > > But what if the target location is the document itself? Ie, > > { "op": "remove", "path": "" } > > It really means that the resulting document is, well, nothing, not > even a JSON null. Or am I missing something? Shouldn't the empty JSON > Pointer be forbidden? > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema in Java: http://json-schema-validator.herokuapp.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-ed3O/9MTY2aBnGy4bdOF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I consider it to have no value, not even null, i.e. not exist. The intent was to make it possible to subsequently insert a value at the root level successfully, as well as to support the semantics of the "replace" operation.

Paul

On Fri, 2013-03-08 at 16:31 +0100, Francis Galiegue wrote: 
Hello,

I am writing an implementation of JSON Patch. Reference document:

http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10

The question is about the remove operation (section 4.2).

The text says that the target location must exist for the operation to
succeed, which is pretty normal.

But what if the target location is the document itself? Ie,

{ "op": "remove", "path": "" }

It really means that the resulting document is, well, nothing, not
even a JSON null. Or am I missing something? Shouldn't the empty JSON
Pointer be forbidden?

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-ed3O/9MTY2aBnGy4bdOF-- From fgaliegue@gmail.com Fri Mar 8 09:58:39 2013 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 CFC8621F8825 for ; Fri, 8 Mar 2013 09:58:39 -0800 (PST) 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 eXPzqIzUqbi1 for ; Fri, 8 Mar 2013 09:58:26 -0800 (PST) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5761E21F8812 for ; Fri, 8 Mar 2013 09:58:21 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id g14so314439eak.37 for ; Fri, 08 Mar 2013 09:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mELOcfbDOuL8mqDk13badBpEvRLgY7YSubFFEgp67Lw=; b=GZ6qDxWu+D0FiClz3BPMYPenU9/Yp4ZmJ9MHERIDFkNvrg3p0wNC7QuZ+oLj8L0IC2 FmuhWXPHz3SLLWo6AkOIZi18X/8BorTFRrJIyQxEfOjszlNCo6wkdUf39rzrxK1akly9 WLn5hN+YSWOW5tId51oxF46v2RYV7M7bGW8ImI8ccBWGsSMFQ49iUFUhO0+hi5N5Njy6 Br1gJaK6GHAcB72K3Ngqb79snL1qavowoQuWtykm+278QkMSs1w2siReMgz6HuQMzBr+ ncvqD340jt6CzkVumO3iKFmvLpGwWLBAQmh7O+InKoE8UJtJ7jYPhSFLPqPajw/PHA+Q gXhA== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr7936496eeo.26.1362765500372; Fri, 08 Mar 2013 09:58:20 -0800 (PST) Received: by 10.14.1.7 with HTTP; Fri, 8 Mar 2013 09:58:20 -0800 (PST) In-Reply-To: <1362765369.22220.9.camel@pbryan-wsl.internal.salesforce.com> References: <1362765369.22220.9.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 8 Mar 2013 18:58:20 +0100 Message-ID: From: Francis Galiegue To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 17:58:39 -0000 On Fri, Mar 8, 2013 at 6:56 PM, Paul C. Bryan wrote: > I consider it to have no value, not even null, i.e. not exist. The intent > was to make it possible to subsequently insert a value at the root level > successfully, as well as to support the semantics of the "replace" > operation. > > Paul > OK, but then I suppose this is an error if this is the only operation in a JSON Patch? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From pbryan@anode.ca Fri Mar 8 09:58:47 2013 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 5BD4C21F882A for ; Fri, 8 Mar 2013 09:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peGN98IPGBm6 for ; Fri, 8 Mar 2013 09:58:46 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEC721F8816 for ; Fri, 8 Mar 2013 09:58:46 -0800 (PST) Received: from [10.126.22.27] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 9DD6C6C81; Fri, 8 Mar 2013 17:58:45 +0000 (UTC) From: "Paul C. Bryan" To: Francis Galiegue In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-TvhPnwt85bjajrMZ6RBV" Date: Fri, 08 Mar 2013 09:58:44 -0800 Message-ID: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 17:58:47 -0000 --=-TvhPnwt85bjajrMZ6RBV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2013-03-08 at 17:34 +0100, Francis Galiegue wrote: > On Fri, Mar 8, 2013 at 4:31 PM, Francis Galiegue wrote: > > Hello, > > > > I am writing an implementation of JSON Patch. Reference document: > > > > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10 > > > > The question is about the remove operation (section 4.2). > > > > Well, I have another question about, this time, the move operation. > > Say we have this data: > > [ "victim", {}, {} ] > > and this patch: > > { "op": "move", "from": "/0", "to": "/1/x" } > > The text says: > > This operation is functionally identical to a "remove" operation on > the "from" location, followed immediately by an "add" operation at > the target location with the value that was just removed. > > So, does this mean that the result of the above should be: > > [ {}, { "x": "victim" } ] > > or is it: > > [ { "x": "victim" }, {} ] > > ? > > If it is the first one, then it means that > > { "op": "move", "from": "/0", "to": "/2/x" } > > will fail. But on the other hand, this: > > { "op": "move", "from": "/0", "to": "/0/x" } > > while forbidden, would theoretically work... The way it's written, if you wanted to move "victim" to the adjacent object in the array (element 1 before the move), then the last operation above would be the way to do it. Paul --=-TvhPnwt85bjajrMZ6RBV Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2013-03-08 at 17:34 +0100, Francis Galiegue wrote: 
On Fri, Mar 8, 2013 at 4:31 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
> Hello,
>
> I am writing an implementation of JSON Patch. Reference document:
>
> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-10
>
> The question is about the remove operation (section 4.2).
>

Well, I have another question about, this time, the move operation.

Say we have this data:

[ "victim", {}, {} ]

and this patch:

{ "op": "move", "from": "/0", "to": "/1/x" }

The text says:

   This operation is functionally identical to a "remove" operation on
   the "from" location, followed immediately by an "add" operation at
   the target location with the value that was just removed.

So, does this mean that the result of the above should be:

[ {}, { "x": "victim" } ]

or is it:

[ { "x": "victim" }, {} ]

?

If it is the first one, then it means that

{ "op": "move", "from": "/0", "to": "/2/x" }

will fail. But on the other hand, this:

{ "op": "move", "from": "/0", "to": "/0/x" }

while forbidden, would theoretically work...
The way it's written, if you wanted to move "victim" to the adjacent object in the array (element 1 before the move), then the last operation above would be the way to do it.

Paul --=-TvhPnwt85bjajrMZ6RBV-- From pbryan@anode.ca Fri Mar 8 10:01:22 2013 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 89BB521F8751 for ; Fri, 8 Mar 2013 10:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHeniMtfGt9G for ; Fri, 8 Mar 2013 10:01:22 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id B169C21F85DA for ; Fri, 8 Mar 2013 10:01:18 -0800 (PST) Received: from [10.126.22.27] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 29FC96C81; Fri, 8 Mar 2013 18:01:18 +0000 (UTC) From: "Paul C. Bryan" To: Francis Galiegue In-Reply-To: References: <1362765369.22220.9.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-b7xivlA5lmBhOWSgsPBT" Date: Fri, 08 Mar 2013 10:01:17 -0800 Message-ID: <1362765677.22220.14.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 18:01:22 -0000 --=-b7xivlA5lmBhOWSgsPBT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2013-03-08 at 18:58 +0100, Francis Galiegue wrote: > On Fri, Mar 8, 2013 at 6:56 PM, Paul C. Bryan wrote: > > I consider it to have no value, not even null, i.e. not exist. The intent > > was to make it possible to subsequently insert a value at the root level > > successfully, as well as to support the semantics of the "replace" > > operation. > > > > Paul > > > > OK, but then I suppose this is an error if this is the only operation > in a JSON Patch? I suppose it depends on the implementation. JavaScript has an undefined type, which seems like a valid way to represent the absence of a value. Other languages though don't have a similar capability (e.g. Java). Paul --=-b7xivlA5lmBhOWSgsPBT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2013-03-08 at 18:58 +0100, Francis Galiegue wrote: 
On Fri, Mar 8, 2013 at 6:56 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
> I consider it to have no value, not even null, i.e. not exist. The intent
> was to make it possible to subsequently insert a value at the root level
> successfully, as well as to support the semantics of the "replace"
> operation.
>
> Paul
>

OK, but then I suppose this is an error if this is the only operation
in a JSON Patch?

I suppose it depends on the implementation. JavaScript has an undefined type, which seems like a valid way to represent the absence of a value. Other languages though don't have a similar capability (e.g. Java).

Paul

--=-b7xivlA5lmBhOWSgsPBT-- From fgaliegue@gmail.com Fri Mar 8 10:19:49 2013 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 4715B21F8644 for ; Fri, 8 Mar 2013 10:19:49 -0800 (PST) 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 1odgEMp2SMom for ; Fri, 8 Mar 2013 10:19:44 -0800 (PST) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 436A321F8697 for ; Fri, 8 Mar 2013 10:19:44 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id q15so321312ead.41 for ; Fri, 08 Mar 2013 10:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5rZGwHzk9dXGV/zfx3a5SuRh+SfBmVpE7hWD/DFkMrA=; b=Ecu4UgKB2cSacjm2U3O7loViUHa/m4CY23ccpZIULtt+YsakDiFxzvMUWeNaYXYPge o4L6Y51k2/GvENGJDlJ+7/r8Mu2MonXJj8WZT6hovtZ6gtBzHGz3TW+9Qr8ayGQbLTn6 oQJIzxWyaZKCZnFlJNUtu2+DQOx37ZbHv5qFIhtvLWVZELa1PAkmZnc1v1Q0Nxl0Ye6m XNofVP8Ae84eCuxB4FNbXyLMZYkhBpqhMS5Eceb2ps40BtYxrWbz5OLh6hoqVsUcfycD EWyczIidwwea6AcbJcRza3nP34xJ+RoEs7HTaYlV40mmqes6DwHd54f40v9iuS8F2V1E 9c/Q== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr8129123een.37.1362766783318; Fri, 08 Mar 2013 10:19:43 -0800 (PST) Received: by 10.14.1.7 with HTTP; Fri, 8 Mar 2013 10:19:43 -0800 (PST) In-Reply-To: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 8 Mar 2013 19:19:43 +0100 Message-ID: From: Francis Galiegue To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 18:19:49 -0000 On Fri, Mar 8, 2013 at 6:58 PM, Paul C. Bryan wrote: The "from" location MUST NOT be a proper prefix of the "path" location; i.e., a location cannot be moved into one of its children.[...] > > The way it's written, if you wanted to move "victim" to the adjacent object > in the array (element 1 before the move), then the last operation above > would be the way to do it. > > Paul Do you mean this one? { "op": "move", "from": "/0", "to": "/0/x" } Because according to the spec, it is not legal: The "from" location MUST NOT be a proper prefix of the "path" location; i.e., a location cannot be moved into one of its children. Or is it meant to be that the prefix relationship must be evaluated _after_ the move (since in this case /0 will have changed)? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From ted.ietf@gmail.com Fri Mar 8 10:21:47 2013 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 6112721F87CB; Fri, 8 Mar 2013 10:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 cZZDnHs9vBU2; Fri, 8 Mar 2013 10:21:43 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A623D21F87C3; Fri, 8 Mar 2013 10:21:42 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so1464062wey.1 for ; Fri, 08 Mar 2013 10:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=HwpVejVllR/L2qjyQzYujBuyMmphND8ZyS0MumwjXOE=; b=KutIdWSDJbwBkeUnCMjbnOxxKHlTpW8mj0duibxgtK5b4vsvPeWqZHysLS7BMk/uRW LXZ4jxLyL66a9LVKavewpKEMKVSsW/fN3tsW6HDBAxMA+LG+t6OmQJ1ovACw51dBfZiZ VMGZgCPp38FXeEaeC1cZ5BbfohYM09W6yO0HkOw/rJwxo08cn5IJd9vnwrxqx0pJzCHN 0E9cBXn32Kpz5LatUHj+aX5bdK0UyeGaX3NcHhdgP8UdVj8cIX2i2MFH1Q3RbwSN0qrK c1AZWoaApveTQ5D7MqTYmig9mo7j9/ZMOoQ1k+qUhMRBrk0pzOnoz2T2+qs0D2yiGvmA gsbA== MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr5987327wjc.50.1362766901913; Fri, 08 Mar 2013 10:21:41 -0800 (PST) Received: by 10.227.24.7 with HTTP; Fri, 8 Mar 2013 10:21:41 -0800 (PST) Date: Fri, 8 Mar 2013 10:21:41 -0800 Message-ID: From: Ted Hardie To: apps-discuss@ietf.org, draft-ietf-idr-deprecate-dpa-etal.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: IESG Subject: [apps-discuss] Applications Area Directorate review of draft-ietf-idr-deprecate-dpa-etal-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, 08 Mar 2013 18:21:47 -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-idr-deprecate-dpa-etal Title: Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH /CLUSTER_ID Reviewer: Ted Hardie Review Date:March 8, 2013 Summary: This document is ready for publication. It is currently marked as Informational, but it could also be appropriate as a Standards action. Major Issues: RFC 4271 says that additions to the relevant IANA registry require either standards action or must follow an early allocation policy (RFC 4020). It does not specify the requirements for deprecation; if the IESG believes that standards action is also required for deprecation, then this document should be updated to standards track. From barryleiba.mailing.lists@gmail.com Fri Mar 8 10:26:35 2013 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 D093821F87AF; Fri, 8 Mar 2013 10:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 J95bYQvBznIJ; Fri, 8 Mar 2013 10:26:35 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DF28721F874C; Fri, 8 Mar 2013 10:26:34 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so1985377lab.19 for ; Fri, 08 Mar 2013 10:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z7Me0uby5VYntFDNtYSGHnceKCfOlh/QpN3IZMjqAR4=; b=mNpmblWxe++z6qpgP1VnOKTx7cuwtI/5VxHTQisRga2dEk31CzG//LLL9FLDM1KKv1 xpy20DxUgvQa+mbEeBndmCGRi95hnuHKDQvoHKK94ONzSk0oJRSR344PfT8PAMrnTSqh msj88eNdBQ8K7uk1UZtonPpicF9cVHjhsFyN/UGx3vyXNA/Atxu+6S67NT7o6PcTTQsx DUqGsUGaEvhYiWqBvOJ3c2yQUmRSP/FCkpFCCzkfJVAWOuHfLimv6ZsYoxwRZHtO6Btf 01haYbROfkLMLHL5VdSM36EMk/0dPHZrPo7jBmLtO6bx+NgfYY/VgB27GGKSBxI6uem7 EGxw== MIME-Version: 1.0 X-Received: by 10.152.104.80 with SMTP id gc16mr2802139lab.49.1362767193403; Fri, 08 Mar 2013 10:26:33 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.40.137 with HTTP; Fri, 8 Mar 2013 10:26:33 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Mar 2013 13:26:33 -0500 X-Google-Sender-Auth: _tzPp2nZ06bePYikf2FnRr4xkKs Message-ID: From: Barry Leiba To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-idr-deprecate-dpa-etal.all@tools.ietf.org, "apps-discuss@ietf.org" , IESG Subject: Re: [apps-discuss] Applications Area Directorate review of draft-ietf-idr-deprecate-dpa-etal-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, 08 Mar 2013 18:26:35 -0000 Thanks for doing the review, Ted. > RFC 4271 says that additions to the relevant IANA registry require > either standards action or must follow an early allocation policy (RFC > 4020). > It does not specify the requirements for deprecation; if the IESG > believes that standards action is also required for deprecation, then > this document should be updated to standards track. And, indeed, on 21 Feb a second last-call notice was sent out with this annotation: > This document was previously Last Called as Informational. However it > deprecates codepoints that were created by Standards Track documents. > It is therefore being re Last Called as a Proposed Standard. The > text change to PS is provided via an RFC Editor Note in the tracker. Barry, who would have rather seen it done by a management action From pbryan@anode.ca Fri Mar 8 10:45:41 2013 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 28A6D21F880F for ; Fri, 8 Mar 2013 10:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 usBSDtRHTuJ9 for ; Fri, 8 Mar 2013 10:45:40 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD0021F8809 for ; Fri, 8 Mar 2013 10:45:40 -0800 (PST) Received: from [10.126.22.27] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 1524C6C81; Fri, 8 Mar 2013 18:45:38 +0000 (UTC) From: "Paul C. Bryan" To: Francis Galiegue In-Reply-To: References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-qwlFaCTDWxy9GeGHrsqo" Date: Fri, 08 Mar 2013 10:45:34 -0800 Message-ID: <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 18:45:41 -0000 --=-qwlFaCTDWxy9GeGHrsqo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Unfortunately, these cases you're presenting are proving that the text could still stand to be improved. Prefix relationship must be evaluated after the move. Paul On Fri, 2013-03-08 at 19:19 +0100, Francis Galiegue wrote: > On Fri, Mar 8, 2013 at 6:58 PM, Paul C. Bryan wrote: > > The "from" location MUST NOT be a proper prefix of the "path" > > location; i.e., a location cannot be moved into one of its children.[...] > > > > The way it's written, if you wanted to move "victim" to the adjacent object > > in the array (element 1 before the move), then the last operation above > > would be the way to do it. > > > > Paul > > Do you mean this one? > > { "op": "move", "from": "/0", "to": "/0/x" } > > Because according to the spec, it is not legal: > > The "from" location MUST NOT be a proper prefix of the "path" > location; i.e., a location cannot be moved into one of its children. > > Or is it meant to be that the prefix relationship must be evaluated > _after_ the move (since in this case /0 will have changed)? > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema in Java: http://json-schema-validator.herokuapp.com --=-qwlFaCTDWxy9GeGHrsqo Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Unfortunately, these cases you're presenting are proving that the text could still stand to be improved. Prefix relationship must be evaluated after the move.

Paul

On Fri, 2013-03-08 at 19:19 +0100, Francis Galiegue wrote: 
On Fri, Mar 8, 2013 at 6:58 PM, Paul C. Bryan <pbryan@anode.ca> wrote:

The "from" location MUST NOT be a proper prefix of the "path"

   location; i.e., a location cannot be moved into one of its children.[...]
>
> The way it's written, if you wanted to move "victim" to the adjacent object
> in the array (element 1 before the move), then the last operation above
> would be the way to do it.
>
> Paul

Do you mean this one?

{ "op": "move", "from": "/0", "to": "/0/x" }

Because according to the spec, it is not legal:

   The "from" location MUST NOT be a proper prefix of the "path"
   location; i.e., a location cannot be moved into one of its children.

Or is it meant to be that the prefix relationship must be evaluated
_after_ the move (since in this case /0 will have changed)?

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

--=-qwlFaCTDWxy9GeGHrsqo-- From ted.ietf@gmail.com Fri Mar 8 10:50:45 2013 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 9536021F8838; Fri, 8 Mar 2013 10:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 JMEKt6K-f-N6; Fri, 8 Mar 2013 10:50:45 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CE1A921F8831; Fri, 8 Mar 2013 10:50:43 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u54so1449224wey.30 for ; Fri, 08 Mar 2013 10:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rQS99Ga54cdI1wDXdzzZ6EYZxk9Hg/Alba6IUbBu1R0=; b=DoGjyw6nSEWp2xkwxJc1Hz51S5Qx34hZ0N5Xh8VXnsZnIL89+bZKCnOBSxF6tZIfHU BoifG2bF0XK+HyFaKDzmkt+Ng3mHD00dSeIQWI+CV5V+bEcyO9DFoRgC78//uYxI+L5m Cw0k719nw9B7uFnUC1oyPDas0TQu+9oZSqf8DnlH6Qg/jH9eu3C6xbK1vQA8ElbZvGuf YeZ1zydx4Fte7w/Z7XbjIYsmP+/IqUeuY3BaF9wz04nYo0Ct1V/JGLfOdf6gPPvRyqzR YdgU71UDR80pdoIybCsZC1y4O0FZMfRsv3PD2z5fzkjLTJt8Zec4pnoQynV0sTdMXC1f d4QQ== MIME-Version: 1.0 X-Received: by 10.194.158.161 with SMTP id wv1mr6178102wjb.38.1362768643028; Fri, 08 Mar 2013 10:50:43 -0800 (PST) Received: by 10.227.24.7 with HTTP; Fri, 8 Mar 2013 10:50:42 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Mar 2013 10:50:42 -0800 Message-ID: From: Ted Hardie To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-idr-deprecate-dpa-etal.all@tools.ietf.org, "apps-discuss@ietf.org" , IESG Subject: Re: [apps-discuss] Applications Area Directorate review of draft-ietf-idr-deprecate-dpa-etal-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, 08 Mar 2013 18:50:45 -0000 On Fri, Mar 8, 2013 at 10:26 AM, Barry Leiba wrote: > Thanks for doing the review, Ted. > >> RFC 4271 says that additions to the relevant IANA registry require >> either standards action or must follow an early allocation policy (RFC >> 4020). >> It does not specify the requirements for deprecation; if the IESG >> believes that standards action is also required for deprecation, then >> this document should be updated to standards track. > > And, indeed, on 21 Feb a second last-call notice was sent out with > this annotation: > >> This document was previously Last Called as Informational. However it >> deprecates codepoints that were created by Standards Track documents. >> It is therefore being re Last Called as a Proposed Standard. The >> text change to PS is provided via an RFC Editor Note in the tracker. > > Barry, who would have rather seen it done by a management action Great, thanks for the note; I had missed the second last call. Ted From fgaliegue@gmail.com Fri Mar 8 11:44:24 2013 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 ECC1921F85BD for ; Fri, 8 Mar 2013 11:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 K-qg0Jc0wwkp for ; Fri, 8 Mar 2013 11:44:20 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5681721F85BC for ; Fri, 8 Mar 2013 11:44:20 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d41so1219106eek.36 for ; Fri, 08 Mar 2013 11:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9mXzPwJlSt4hc2BpwVIPYDo+1GkkfFoF5LgRDCOWwow=; b=ic2Cizpww2vQ0URVNdIaVCtmdJVkYRyrLoTFJ6KPvQhE1w2E87sEqn1mzbOIS1bOG7 RBfud0a4/O0is/YP+Z0IQtMaYnwjUkK8wYD3dzLK5Jt3MNdlSgaOvslSeiy079uVZFpG mdYefBQrZJB7vRgOguHkHcQoihZgKXN9FiY9+wt0JRD53ZOHxMUDCqgViqtGt4dE6BYQ PnSDfWIMByvLrEe3W7JEJj+lzeGrLt4LX3KOPq4P9N21mVLVLRW/Z2iOJcmfLaXGXHch be2Z55xMQIZ0wpmCY2zcRZwb9LYDtwcJy2fj2CLHN4R9/o2IHtWY5NRv9Sl0iLjSX35+ OSJA== MIME-Version: 1.0 X-Received: by 10.14.183.67 with SMTP id p43mr8927886eem.10.1362771859456; Fri, 08 Mar 2013 11:44:19 -0800 (PST) Received: by 10.14.1.7 with HTTP; Fri, 8 Mar 2013 11:44:19 -0800 (PST) In-Reply-To: <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 8 Mar 2013 20:44:19 +0100 Message-ID: From: Francis Galiegue To: "Paul C. Bryan" Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 19:44:25 -0000 On Fri, Mar 8, 2013 at 7:45 PM, Paul C. Bryan wrote: > Unfortunately, these cases you're presenting are proving that the text could > still stand to be improved. Prefix relationship must be evaluated after the > move. > What about: * for the removing of "": Note that it is possible to remove the empty path ""; in effect, this means removing the entire document. The representation of such a missing document is left up to implementations. * for moving to a child: If the "from" location resolves to an object member, then it MUST NOT be a proper prefix of the "path" location; ie, an object member cannot be moved to one of its children. The latter is because if you choose to move an array index, given that this is functionally equivalent to a remove then an add, then the structure of the array will have changed before the add. Whereas if you choose to move an object member to a child of itself, the target location will not exist anymore. Comments? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From pbryan@anode.ca Fri Mar 8 11:51:56 2013 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 CB21721F8923 for ; Fri, 8 Mar 2013 11:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRvQxuVZFgfQ for ; Fri, 8 Mar 2013 11:51:56 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3C221F8984 for ; Fri, 8 Mar 2013 11:51:55 -0800 (PST) Received: from [10.126.22.27] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 6917C6487; Fri, 8 Mar 2013 19:51:49 +0000 (UTC) From: "Paul C. Bryan" To: Francis Galiegue In-Reply-To: References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-3V1fsNQI3G8CZmT13qK7" Date: Fri, 08 Mar 2013 11:51:47 -0800 Message-ID: <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 19:51:56 -0000 --=-3V1fsNQI3G8CZmT13qK7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Final call has already been reached; it's in the RFC submission queue. So, the train has left the station, so to speak. An errata that clarifies some of these edge cases would seem to be in order though. Paul On Fri, 2013-03-08 at 20:44 +0100, Francis Galiegue wrote: > On Fri, Mar 8, 2013 at 7:45 PM, Paul C. Bryan wrote: > > Unfortunately, these cases you're presenting are proving that the text could > > still stand to be improved. Prefix relationship must be evaluated after the > > move. > > > > What about: > > * for the removing of "": > > Note that it is possible to remove the empty path ""; in effect, this > means removing the entire document. The representation of such a > missing document is left up to implementations. > > * for moving to a child: > > If the "from" location resolves to an object member, then it MUST NOT > be a proper prefix of the "path" location; ie, an object member cannot > be moved to one of its children. > > The latter is because if you choose to move an array index, given that > this is functionally equivalent to a remove then an add, then the > structure of the array will have changed before the add. Whereas if > you choose to move an object member to a child of itself, the target > location will not exist anymore. > > Comments? > --=-3V1fsNQI3G8CZmT13qK7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Final call has already been reached; it's in the RFC submission queue. So, the train has left the station, so to speak.

An errata that clarifies some of these edge cases would seem to be in order though.

Paul

On Fri, 2013-03-08 at 20:44 +0100, Francis Galiegue wrote: 
On Fri, Mar 8, 2013 at 7:45 PM, Paul C. Bryan <pbryan@anode.ca> wrote:
> Unfortunately, these cases you're presenting are proving that the text could
> still stand to be improved. Prefix relationship must be evaluated after the
> move.
>

What about:

* for the removing of "":

Note that it is possible to remove the empty path ""; in effect, this
means removing the entire document. The representation of such a
missing document is left up to implementations.

* for moving to a child:

If the "from" location resolves to an object member, then it MUST NOT
be a proper prefix of the "path" location; ie, an object member cannot
be moved to one of its children.

The latter is because if you choose to move an array index, given that
this is functionally equivalent to a remove then an add, then the
structure of the array will have changed before the add. Whereas if
you choose to move an object member to a child of itself, the target
location will not exist anymore.

Comments?

--=-3V1fsNQI3G8CZmT13qK7-- From barryleiba.mailing.lists@gmail.com Fri Mar 8 11:55:08 2013 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 B109B21F8780 for ; Fri, 8 Mar 2013 11:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.904 X-Spam-Level: X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=0.073, 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 WZBobfaAtGpa for ; Fri, 8 Mar 2013 11:55:08 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81521F8745 for ; Fri, 8 Mar 2013 11:55:08 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id m18so1106142vcm.36 for ; Fri, 08 Mar 2013 11:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8Jbp64nGkv0vETz/2OUfIF6G4Ba2vDp7EYTbcXzDdk4=; b=SqHSY3lQl5erfLHnv2Gm0QUwMnYydSLceiPWKxHewQxJplXRBNrpTWy13vN4Zmrk6U wLzDdF8yfPr5JN/qI/XAV9Tla58TxXdrL48cLPmd9VmXjfAKTUjrSDWFR23ipT7/bY38 3nRFdpYmxgXewKmtlMQADYm/mqBkgcxUosTBMwEsYjilwzPfx3BFcd6ezvptXdHbCnwb apiJ/PXxKb25FtmWr9Rc5STC2CN2qadONfIu2hQngGPaEjL5AL2CgtthZzbGh9hwHGa/ /kNj4xSY+LT7MFNVHsY76+zg1BTbNcMIajRlSrneKglWJNWUzNaar7bTX0oirHzRjMDf GYmA== MIME-Version: 1.0 X-Received: by 10.58.106.161 with SMTP id gv1mr1471127veb.35.1362772507575; Fri, 08 Mar 2013 11:55:07 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 8 Mar 2013 11:55:07 -0800 (PST) In-Reply-To: <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 8 Mar 2013 14:55:07 -0500 X-Google-Sender-Auth: -Jc4yZA02b_4YDiGF9A_k77F7ko Message-ID: From: Barry Leiba To: "Paul C. Bryan" Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 19:55:08 -0000 > Final call has already been reached; it's in the RFC submission queue. So, > the train has left the station, so to speak. > > An errata that clarifies some of these edge cases would seem to be in order > though. If the changes are minor and clarifying, we can make them in AUTH48, before the RFC is published. If it's more significant, we can pull it back from the RFC Editor queue for fixes. Barry, Applications AD From paul.hoffman@vpnc.org Fri Mar 8 13:19:03 2013 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 E18AC21F8450 for ; Fri, 8 Mar 2013 13:19:03 -0800 (PST) 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 E9vGdP82ttMK for ; Fri, 8 Mar 2013 13:19:03 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8441121F85BF for ; Fri, 8 Mar 2013 13:18:51 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r28LIhgF093565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Mar 2013 14:18:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Fri, 8 Mar 2013 13:18:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 21:19:04 -0000 On Mar 8, 2013, at 11:55 AM, Barry Leiba = wrote: >> Final call has already been reached; it's in the RFC submission = queue. So, >> the train has left the station, so to speak. >>=20 >> An errata that clarifies some of these edge cases would seem to be in = order >> though. >=20 > If the changes are minor and clarifying, we can make them in AUTH48, > before the RFC is published. If it's more significant, we can pull it > back from the RFC Editor queue for fixes. The current discussion seems to be more than clarifying, because no one = seems to have thought of them before Francis did. But it is far from = clear that what Francis has found is the last of where the document will = need to be clarified. Proposal: do this as an errata *and* start a bis document. Let the = latter bake for about six months. --Paul Hoffman= From superuser@gmail.com Fri Mar 8 13:22:18 2013 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 69E4621F85A1 for ; Fri, 8 Mar 2013 13:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 m0WxmX2dvLw6 for ; Fri, 8 Mar 2013 13:22:17 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id AA30021F85C6 for ; Fri, 8 Mar 2013 13:22:14 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so2934104wgl.18 for ; Fri, 08 Mar 2013 13:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jT52nd55G4PxL5BIv/zJRiQOUgzf2vvi1gP7c/u038w=; b=RgXGscRWmnsmrY3u6TyFD5IYTBf+VEa3nXGA+DrUCY8hsiBgIH0zq1TT+6hGSnslZA O68X678IF2bpFLDkC0k+NXJeZ7A9p+chP7hceaM8E6lqxHJirqYy0REMYWwH7UydqWEF 9p8GIb/e5zc9j8LEupSPU+mNG/FeM4xJmcJNSWMFTqkamuOS7Fo3T9DHAC/jXdtAEfy7 dWWCt/ltLBNDgHstRM7ljrRJxceq+BqsbXh/XGHyfGja8oNZVKszvi9u33jOXQRRbde2 CohtsYYVch4S8qG9y9rTFKz7TWAiI4b0KZ2U/hV50oeSx2Y2swENH9s7WiPUqMZ1ldRg Q0aA== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr6796249wjc.35.1362777733956; Fri, 08 Mar 2013 13:22:13 -0800 (PST) Received: by 10.180.189.6 with HTTP; Fri, 8 Mar 2013 13:22:13 -0800 (PST) In-Reply-To: References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 8 Mar 2013 13:22:13 -0800 Message-ID: From: "Murray S. Kucherawy" To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e013d1da8bd8d5a04d7706af9 Cc: Barry Leiba , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 21:22:18 -0000 --089e013d1da8bd8d5a04d7706af9 Content-Type: text/plain; charset=ISO-8859-1 I'd rather hold off on starting the bis document right away, but otherwise this plan seems fine to me. On Fri, Mar 8, 2013 at 1:18 PM, Paul Hoffman wrote: > On Mar 8, 2013, at 11:55 AM, Barry Leiba wrote: > > >> Final call has already been reached; it's in the RFC submission queue. > So, > >> the train has left the station, so to speak. > >> > >> An errata that clarifies some of these edge cases would seem to be in > order > >> though. > > > > If the changes are minor and clarifying, we can make them in AUTH48, > > before the RFC is published. If it's more significant, we can pull it > > back from the RFC Editor queue for fixes. > > The current discussion seems to be more than clarifying, because no one > seems to have thought of them before Francis did. But it is far from clear > that what Francis has found is the last of where the document will need to > be clarified. > > Proposal: do this as an errata *and* start a bis document. Let the latter > bake for about six months. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013d1da8bd8d5a04d7706af9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd rather hold off on starting the bis document right= away, but otherwise this plan seems fine to me.


On Fri, Mar 8, 2013 at 1:18 PM= , Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Mar 8, 2013, at 11:55 A= M, Barry Leiba <barryleiba@co= mputer.org> wrote:

>> Final call has already been reached; it's in the RFC submissio= n queue. So,
>> the train has left the station, so to speak.
>>
>> An errata that clarifies some of these edge cases would seem to be= in order
>> though.
>
> If the changes are minor and clarifying, we can make them in AUTH48, > before the RFC is published. =A0If it's more significant, we can p= ull it
> back from the RFC Editor queue for fixes.

The current discussion seems to be more than clarifying, because no o= ne seems to have thought of them before Francis did. But it is far from cle= ar that what Francis has found is the last of where the document will need = to be clarified.

Proposal: do this as an errata *and* start a bis document. Let the latter b= ake for about six months.

--Paul Hoffman
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e013d1da8bd8d5a04d7706af9-- From fgaliegue@gmail.com Fri Mar 8 13:32:51 2013 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 3951921F869B for ; Fri, 8 Mar 2013 13:32:51 -0800 (PST) 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=0.125, 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 tJkHHOI5Cfaz for ; Fri, 8 Mar 2013 13:32:50 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 510AD21F8698 for ; Fri, 8 Mar 2013 13:32:50 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so1305595eek.40 for ; Fri, 08 Mar 2013 13:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q4CmJabkmHB0ccFHCjk5FWrEzZ6P3fJLRwK2UzKfEZ8=; b=gZYKrqOpR3H9g0np6shi5oVICKZ/XOgFMaiJjv+/rcLJdJN5VQBYOprIceDIVJQCTG FkozfPLC06ASxWka2XKRPm+5mAVZGWuRK1LE6dpnkujIfyJAn+KddZVIZV2P+hQyvkxW 3JxU1oGS46CmhtFlkJ/huqIWkiIOaQknlxww3Mz+IBAexSswTPwv2IN84fDNsALYZ9Zh HXREVRmCBIb1FnJkfwl7J5C5lN31juHy4RhlzjZWaN+jrd/tTV/pw/NfA2TsJIvJbE0V WqGXxJ+P9gX9fbBif1VQLvjF4wMJP2w5z7TE+QAo3cw9aAQTL6AQKekNHE5tgNarNe66 NiKw== MIME-Version: 1.0 X-Received: by 10.14.193.134 with SMTP id k6mr9786839een.37.1362778369375; Fri, 08 Mar 2013 13:32:49 -0800 (PST) Received: by 10.14.1.7 with HTTP; Fri, 8 Mar 2013 13:32:48 -0800 (PST) In-Reply-To: References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 8 Mar 2013 22:32:48 +0100 Message-ID: From: Francis Galiegue To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: Barry Leiba , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 21:32:51 -0000 On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman wrote: [...] > > The current discussion seems to be more than clarifying, because no one seems to have thought of them before Francis did. But it is far from clear that what Francis has found is the last of where the document will need to be clarified. > Sorry for that... And all the more sorry that I have just found another one. This time with replace. It is said that: This operation is functionally identical to a "remove" operation for a value, followed immediately by an "add" operation at the same location with the replacement value. But this is not quite true. Consider: { "op": "replace", "path": "/0", "value": 1 } against: [ true ] The remove leads to: [] and add will fail, since /0 does not exist anymore. It would have to be an add to "/-" to work... Rather than sending mail after mail, what is the correct way to report this kind of findings? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From superuser@gmail.com Fri Mar 8 13:57:29 2013 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 4BC4E21F85E2 for ; Fri, 8 Mar 2013 13:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 CW1XEC8F9R26 for ; Fri, 8 Mar 2013 13:57:28 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 238FE21F85D9 for ; Fri, 8 Mar 2013 13:57:27 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so2969643wgb.0 for ; Fri, 08 Mar 2013 13:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bQVippp3R/neg1DwisIYMcTFxmBH1fzU0KUQNXlyXA0=; b=X8VUV+W2N1WxbyJycjUy3kx6KwoS2fSCIFFhP2C0gNa6v1Q4LClHI26HdJ6t+qehyu /7eNzTDi9GsRRqmaFSRbvCzfF9x73v4vP2lHRn7Szbj9/gmI2Z7nYOtbMKD10/WWhwzR iwdPiw7E47PvAbOdMWPEnAB4JzcJHjB5ju8qZSo0d6LsmRsgQGpn5J7+fj6gkZ9FZlzC 51Rr4zPRvW7SsW/ZArRPR4ltoE8bs0sdflFlUuYW9WTjKfmYzqJltQEFWXrantQU8Q33 LyM9RcMwGKLWJ91jv3GnW11FTe2KhjZ+2P1XUM0RxgxfhxIWdlrLJYi4DfvyVGwojS2y X+Kw== MIME-Version: 1.0 X-Received: by 10.194.59.100 with SMTP id y4mr6891101wjq.51.1362779847351; Fri, 08 Mar 2013 13:57:27 -0800 (PST) Received: by 10.180.189.6 with HTTP; Fri, 8 Mar 2013 13:57:27 -0800 (PST) In-Reply-To: References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> Date: Fri, 8 Mar 2013 13:57:27 -0800 Message-ID: From: "Murray S. Kucherawy" To: Francis Galiegue Content-Type: multipart/alternative; boundary=047d7b86cea4b5645004d770e8dc Cc: Barry Leiba , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 21:57:29 -0000 --047d7b86cea4b5645004d770e8dc Content-Type: text/plain; charset=ISO-8859-1 Others may disagree, but I think it's fine to send an email first to get a couple of people to agree that the issue is real, and then open an erratum if so. On Fri, Mar 8, 2013 at 1:32 PM, Francis Galiegue wrote: > On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman > wrote: > [...] > > > > The current discussion seems to be more than clarifying, because no one > seems to have thought of them before Francis did. But it is far from clear > that what Francis has found is the last of where the document will need to > be clarified. > > > > Sorry for that... And all the more sorry that I have just found > another one. This time with replace. It is said that: > > This operation is functionally identical to a "remove" operation for > a value, followed immediately by an "add" operation at the same > location with the replacement value. > > But this is not quite true. Consider: > > { "op": "replace", "path": "/0", "value": 1 } > > against: > > [ true ] > > The remove leads to: > > [] > > and add will fail, since /0 does not exist anymore. It would have to > be an add to "/-" to work... > > Rather than sending mail after mail, what is the correct way to report > this kind of findings? > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema in Java: http://json-schema-validator.herokuapp.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b86cea4b5645004d770e8dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Others may disagree, but I think it's fine to send an = email first to get a couple of people to agree that the issue is real, and = then open an erratum if so.


On Fri, Mar 8, 2013 at 1:32 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
[...]
>
> The current discussion seems to be more than clarifying, because no on= e seems to have thought of them before Francis did. But it is far from clea= r that what Francis has found is the last of where the document will need t= o be clarified.
>

Sorry for that... And all the more sorry that I have just found
another one. This time with replace. It is said that:

=A0 =A0This operation is functionally identical to a "remove" ope= ration for
=A0 =A0a value, followed immediately by an "add" operation at the= same
=A0 =A0location with the replacement value.

But this is not quite true. Consider:

{ "op": "replace", "path": "/0", &q= uot;value": 1 }

against:

[ true ]

The remove leads to:

[]

and add will fail, since /0 does not exist anymore. It would have to
be an add to "/-" to work...

Rather than sending mail after mail, what is the correct way to report
this kind of findings?

--
Francis Galiegue, fgaliegue@gmail.co= m
JSON Schema in Java: http://json-schema-validator.herokuapp.com
_____________________________= __________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--047d7b86cea4b5645004d770e8dc-- From pbryan@anode.ca Fri Mar 8 14:23:49 2013 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 12D2421F8605 for ; Fri, 8 Mar 2013 14:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHr0PHQ8RY9a for ; Fri, 8 Mar 2013 14:23:48 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE7F21F85CC for ; Fri, 8 Mar 2013 14:23:48 -0800 (PST) Received: from [10.126.22.27] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id E2B266487; Fri, 8 Mar 2013 22:23:46 +0000 (UTC) From: "Paul C. Bryan" To: "Murray S. Kucherawy" In-Reply-To: References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> <1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> Content-Type: multipart/alternative; boundary="=-bD805qhIeN5Vp89U0ghY" Date: Fri, 08 Mar 2013 14:23:45 -0800 Message-ID: <1362781425.22220.28.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Barry Leiba , Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 08 Mar 2013 22:23:49 -0000 --=-bD805qhIeN5Vp89U0ghY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I agree the issue is real. Paul On Fri, 2013-03-08 at 13:57 -0800, Murray S. Kucherawy wrote: > Others may disagree, but I think it's fine to send an email first to > get a couple of people to agree that the issue is real, and then open > an erratum if so. > > > > > On Fri, Mar 8, 2013 at 1:32 PM, Francis Galiegue > wrote: > > On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman > wrote: > [...] > > > > > The current discussion seems to be more than clarifying, > because no one seems to have thought of them before Francis > did. But it is far from clear that what Francis has found is > the last of where the document will need to be clarified. > > > > > > Sorry for that... And all the more sorry that I have just > found > another one. This time with replace. It is said that: > > This operation is functionally identical to a "remove" > operation for > a value, followed immediately by an "add" operation at the > same > location with the replacement value. > > But this is not quite true. Consider: > > { "op": "replace", "path": "/0", "value": 1 } > > against: > > [ true ] > > The remove leads to: > > [] > > and add will fail, since /0 does not exist anymore. It would > have to > be an add to "/-" to work... > > Rather than sending mail after mail, what is the correct way > to report > this kind of findings? > > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema in Java: > http://json-schema-validator.herokuapp.com > > _______________________________________________ > 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 --=-bD805qhIeN5Vp89U0ghY Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I agree the issue is real.

Paul

On Fri, 2013-03-08 at 13:57 -0800, Murray S. Kucherawy wrote:
Others may disagree, but I think it's fine to send an email first to get a couple of people to agree that the issue is real, and then open an erratum if so.



On Fri, Mar 8, 2013 at 1:32 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
[...]
>
> The current discussion seems to be more than clarifying, because no one seems to have thought of them before Francis did. But it is far from clear that what Francis has found is the last of where the document will need to be clarified.
>


Sorry for that... And all the more sorry that I have just found
another one. This time with replace. It is said that:

   This operation is functionally identical to a "remove" operation for
   a value, followed immediately by an "add" operation at the same
   location with the replacement value.

But this is not quite true. Consider:

{ "op": "replace", "path": "/0", "value": 1 }

against:

[ true ]

The remove leads to:

[]

and add will fail, since /0 does not exist anymore. It would have to
be an add to "/-" to work...

Rather than sending mail after mail, what is the correct way to report
this kind of findings?

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

_______________________________________________
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

--=-bD805qhIeN5Vp89U0ghY-- From ray.polk@oracle.com Fri Mar 8 14:28:21 2013 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 B5A9421F8630 for ; Fri, 8 Mar 2013 14:28:21 -0800 (PST) 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 FB3fWK+Ev0y6 for ; Fri, 8 Mar 2013 14:28:21 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7F021F85C9 for ; Fri, 8 Mar 2013 14:28:21 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r28MSKGa000410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Mar 2013 22:28:20 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r28MSJV5012914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Mar 2013 22:28:19 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r28MSIHf016873 for ; Fri, 8 Mar 2013 16:28:18 -0600 MIME-Version: 1.0 Message-ID: Date: Fri, 8 Mar 2013 14:28:18 -0800 (PST) From: Ray Polk To: X-Mailer: Zimbra on Oracle Beehive Content-Type: multipart/alternative; boundary="__1362781698624218589abhmt115.oracle.com" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [apps-discuss] draft-nottingham-http-problem 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, 08 Mar 2013 22:28:21 -0000 --__1362781698624218589abhmt115.oracle.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think http-problem is a good idea, and we're looking at adopting it.=C2= =A0 A few questions:=20 Has the notion of errorF ield or problemP ath been considered?=C2=A0 G iven= a problem, say 422 , it might be useful to point out the associative array= entry / attribute / field that was problematic.=C2=A0 The value could be t= he field name or jsonPath to the erroneous field.=20 Other than adding additional info to "more", is there any consideration for= multiple problems in one response?=C2=A0 For instance, there may be more t= han one problematic field in a request.=C2=A0 It would be advantageous to r= eport them all at once instead of piecemeal.=C2=A0 Perhaps a subP roblem fi= eld or array that contains additional problems?=20 Has anyone written a bit of client code for this yet?=20 Regards,=20 Ray --__1362781698624218589abhmt115.oracle.com Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <= div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>

I thin= k http-problem is a good idea, and we're looking at adopting it.  A fe= w questions:

 

Has the notion of errorField or problemPath been considered?  Given= a problem, say 422, it might be useful to point out the associative array = entry / attribute / field that was problematic.  The value could be th= e field name or jsonPath to the erroneous field.

 

Other than adding additional info to "more", is there any consideration = for multiple problems in one response?  For instance, there may be mor= e than one problematic field in a request.  It would be advantageous t= o report them all at once instead of piecemeal.  Perhaps a subProblem = field or array that contains additional problems?

 

Has anyone written a bit of client code for this yet?

Regards,

Ray

--__1362781698624218589abhmt115.oracle.com-- From dret@berkeley.edu Fri Mar 8 16:45:46 2013 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 A784721F85B4 for ; Fri, 8 Mar 2013 16:45:46 -0800 (PST) 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 vXnsAlMOXems for ; Fri, 8 Mar 2013 16:45:45 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9763A21F85E7 for ; Fri, 8 Mar 2013 16:45:45 -0800 (PST) Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UE7uw-0000eG-Db; Fri, 08 Mar 2013 16:45:45 -0800 Message-ID: <513A8633.4010306@berkeley.edu> Date: Fri, 08 Mar 2013 16:45:39 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ray Polk References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem 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, 09 Mar 2013 00:45:46 -0000 hello ray. thanks for the feedback. On 2013-03-08 14:28 , Ray Polk wrote: > I think http-problem is a good idea, and we're looking at adopting it. > A few questions: > Has the notion of errorField or problemPath been considered? Given a > problem, say 422, it might be useful to point out the associative array > entry / attribute / field that was problematic. The value could be the > field name or jsonPath to the erroneous field. this sounds mostly like a validation approach, where you are validating the request and then have a specific point where validation failed. while this is something that can happen, the question is whether this is general enough to warrant a specific field. problems can occur for many reasons, and validation is just one part of that. if such a field was added, the best way to do it might be a fragment identifier, because the media type of the request could be anything, and maybe the most general way to point to something might be a fragment identifier. > Other than adding additional info to "more", is there any consideration > for multiple problems in one response? For instance, there may be more > than one problematic field in a request. It would be advantageous to > report them all at once instead of piecemeal. Perhaps a subProblem > field or array that contains additional problems? again, that sounds a lot like being very validation-oriented. the idea is to report HTTP-level problems, not so much validation messages about specific fragments where the requests caused validation problems. if this kind of validation and reporting resulting errors is what you want to do, the "more" is probably the way to go. > Has anyone written a bit of client code for this yet? nothing generic that i am aware of, but we're using it in specific client code. and maybe it's a bit early for broader adoption because the format is still evolving. mark probably can chime in here. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From ajs@anvilwalrusden.com Sat Mar 9 20:23:15 2013 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 29F6A21F87E0 for ; Sat, 9 Mar 2013 20:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 saNTMWlgff4a for ; Sat, 9 Mar 2013 20:23:14 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8717E21F87D3 for ; Sat, 9 Mar 2013 20:23:14 -0800 (PST) Received: from mx1.yitter.info (dhcp-46aa.meeting.ietf.org [130.129.70.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 312728A031 for ; Sun, 10 Mar 2013 04:23:14 +0000 (UTC) Date: Sat, 9 Mar 2013 23:22:50 -0500 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130310042250.GE33497@mx1.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] "finding registered domains" 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, 10 Mar 2013 04:23:15 -0000 Dear colleagues, In the APPSAWG meeting on Monday, the chairs have asked me to take five minutes on the subject: topic. I thought I'd better send a note in preparation. ICANN is in the process of awarding a little under 2000 new TLDs. Inspired, I believe, partly by that fact, Phill Hallam-Baker suggested a new DNS RRTYPE that would identify a name as a public suffix. Unfortunately, he fell ill and didn't have a chance to submit a draft on this. I'm opposed to that particular idea, however, because I think I have proposed a more generic mechanism that would still work just as well for that use case, and also allow future refinements. I've outlined that mechanism in http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02. I won't have any slides on Monday; I really just want to learn the following: 1. Do people think this is work that needs to be done? 2. Do either of the above proposals seem like a good starting point? 3. If so, who is willing to do work on this (by reviewing and so on). (3) is especially important to me, because I received rather too little feedback on the draft I offered to think that anyone else is interested in pursuing it. If people are interested in that draft, I'm certainly prepared to continue working on it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From paf@frobbit.se Sun Mar 10 00:09:24 2013 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 645EE21F8618 for ; Sun, 10 Mar 2013 00:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ZtApkCON79Ok for ; Sun, 10 Mar 2013 00:09:23 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id B5BB321F8266 for ; Sun, 10 Mar 2013 00:09:23 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id 322081FE1E; Sun, 10 Mar 2013 09:09:22 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20130310042250.GE33497@mx1.yitter.info> Date: Sun, 10 Mar 2013 09:09:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se> References: <20130310042250.GE33497@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 10 Mar 2013 08:09:24 -0000 On 10 mar 2013, at 05:22, Andrew Sullivan = wrote: > In the APPSAWG meeting on Monday, the chairs have asked me to take > five minutes on the subject: topic. I thought I'd better send a note > in preparation. >=20 > ICANN is in the process of awarding a little under 2000 new TLDs. > Inspired, I believe, partly by that fact, Phill Hallam-Baker suggested > a new DNS RRTYPE that would identify a name as a public suffix. > Unfortunately, he fell ill and didn't have a chance to submit a draft > on this. >=20 > I'm opposed to that particular idea, however, because I think I have > proposed a more generic mechanism that would still work just as well > for that use case, and also allow future refinements. I've outlined > that mechanism in > http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02. I must be tired or have not had enough coffee yet this sunday morning, = but I can not really follow the text in your I-D. Not a complaint on the = I-D, or the idea... I feel two things are included in the proposal: 1. Whether for example cookies should be set on the domain name 2. Whether two (or more) domain names are within the same policy domain I think the first is the most important issue. Similar ideas have been = discussed around the "delegation only" discussions, but this is of = course slightly different. Early in the text I see: > The idea is to foil the attempts of attackers in (for > example) attackersite.co.tld from setting cookies for everyone in > co.tld. I feel that can be solved by having a resource record like this: co.tld. IN SOPA 255 ...where the value 255 implies no cookies, certificates or whatever is = to be set for the owner co.tld. Other values than 255 can be allocated = for other meanings. This will be managed by either the owner of tld if there is no zone cut, = or co.tld if there is a zone cut. Maybe I am naive, but that I feel could be useful. For the 2nd idea, to say whether two records belong to the same policy = domain, hmm..., I must get more examples I think of what that is to be = used for by third parties. Maybe only the first problem should be solved (first)? And of course, if I am completely off, just disregard this message. Patrik From ithinkihaveacat@gmail.com Sun Mar 10 06:33:41 2013 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 7724721F86AF for ; Sun, 10 Mar 2013 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uBiO47TutVYK for ; Sun, 10 Mar 2013 06:33:41 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id CF4EB21F868E for ; Sun, 10 Mar 2013 06:33:40 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id k14so3739559iea.13 for ; Sun, 10 Mar 2013 06:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JBLhLd+akAlnDqN1nCmA39O4mNRuZWz4xfWjRRrgpXk=; b=yrY6zVRJZwGFJdY8Xdx89XLO+g1STzsxD8d4Y//jQmzg2HFKLEV50QOUhOKbvYyEGP MOMqy29wPBTz144r3SPfQjaUcXsOj4ATbgKtZRPA6RiS8zLO764juTCxBJh4DKo7pveN AN3EH06/OLDGGaczn7iDoyeYbFJuOXTF/ouv305Ay63/Txnv6KIhRu+wIX57oDwi/Fty 8nzUdgwiirjsRSCjtKt/D99Mb3QN1bz8e/QrB4/FDWbiKwIV0bItvdYByuyuVhm3FCX3 wSBtaR3M5y/YNDqlawVE1HobjvZjeln2tea6lqZYiTGHTw7Fhx9qNcJbkROA69bVU1ov Wpyw== MIME-Version: 1.0 X-Received: by 10.42.64.135 with SMTP id g7mr4990193ici.37.1362922420461; Sun, 10 Mar 2013 06:33:40 -0700 (PDT) Sender: ithinkihaveacat@gmail.com Received: by 10.64.97.195 with HTTP; Sun, 10 Mar 2013 06:33:40 -0700 (PDT) In-Reply-To: References: <5137C467.90805@berkeley.edu> Date: Sun, 10 Mar 2013 13:33:40 +0000 X-Google-Sender-Auth: dgKUyCiTSR_m89JQ96cc5CUpdjg Message-ID: From: Michael Stillwell To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dmitry Limonov , erik.wilde@emc.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem 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, 10 Mar 2013 13:33:41 -0000 On Thu, Mar 7, 2013 at 2:45 PM, Mark Nottingham wrote: > Not quite, but yes, this won't end world hunger. It's a small thing, the = real focus is giving help to people who invent their own error formats and = trip up in the process (some of the things I've seen really raise the eyebr= ows, and people spend a *lot* of time trying to get these things right). So if I have this right, the following (fairly minimal) steps are sufficient for Github to achieve complete compliance with the JSON version of problem detail: 1. Do conneg on the Accept header. If the client prefers application/api-problem+json to application/json, then switch to "problem detail" mode. (Hopefully existing clients are already sending application/json, but if not, servers need to default to application/json to avoid breaking existing clients.) 2. Add a "problemType" member to the existing response. At a minimum, "problemType" could equal "http://developer.github.com/v3/#client-errors", though a more specific URI would be preferable. (Perhaps this can be mechanically generated from the URI of the request.) 3. Add a "title" member to the existing response. Would duplicating the HTTP status be sufficient? And for GitHub clients to support "problem detail", they only need to start sending an accept header of application/api-problem+json, and treat the response as they would application/json. For some services, wrapping the original application/json response in something like: { "problemType": "...", "title": "...", "error": [original_JSON_error] } might be preferable/easier for both client and server. It's good that not minimal work is required by servers or clients to support application/api-problem+{json,xml} however in the absence of shared problemTypes the benefits seem correspondingly minimal. (A URI to follow seems like it would be useful[1], but Googling the service and the error is usually good enough.) And my guess is that shared problemTypes are unlikely to emerge for the reason that error responses (unlike successes) are usually unique to the service. (c.f. the Anna Karenina principle: happy families are all alike; unhappy families are unhappy in their own way.) Cheers, Michael [1] On the other hand, the fact that few (any?) services currently provide this, though there are no obstacles to doing so, suggests that there is limited demand for this feature. From ullner@gmail.com Sat Mar 9 10:20:21 2013 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 EC81B21F8457; Sat, 9 Mar 2013 10:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Vl3xlJ8anPLV; Sat, 9 Mar 2013 10:20:20 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 63F9121F8454; Sat, 9 Mar 2013 10:20:20 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so3311833iea.10 for ; Sat, 09 Mar 2013 10:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cCtkTa2PVw8IZRjgVOH4JHk0PRPc1q3eL0d/rp4UNz4=; b=yUTtWDQOjsm+vtNunKep7M1oYFKcXsF7/cOlQIGzOWIEnNOVZ5xV60dmNP025hDjgM u4kV8wOtapzff5BnkerXTA0GqQzq9v+8HXaoVrThdPl31KNRSk4WI0LQiN6h8qZWKbN6 7Wb6w1fCd32rk6GdUHKnJYQXxsAqhvipfZS5dOGeGVNfz1O3ehqPxrt8Hg5by9Dhm1K3 Gh0QNP/EkbR5cg5NoWKsS3tiLhvF9VfxzhljCq4thQxNlxTFCPCxt06714RPWgsCe/M9 v7nIzZdsPJU/TObGgRWnBmgvrnmbJYrzWoYQYJLClEFX+ltAe76MJDT6P7Hvcz5inuSt IeKg== MIME-Version: 1.0 X-Received: by 10.50.196.169 with SMTP id in9mr2062951igc.47.1362853220022; Sat, 09 Mar 2013 10:20:20 -0800 (PST) Received: by 10.42.78.131 with HTTP; Sat, 9 Mar 2013 10:20:19 -0800 (PST) In-Reply-To: <51278B10.10200@ninebynine.org> References: <512663B2.20809@tibco.com> <51278B10.10200@ninebynine.org> Date: Sat, 9 Mar 2013 19:20:19 +0100 Message-ID: From: Fredrik Ullner To: Graham Klyne Content-Type: multipart/alternative; boundary=14dae934070d0f83b004d781fe09 X-Mailman-Approved-At: Sun, 10 Mar 2013 08:27:41 -0700 Cc: uri-review@ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub 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, 09 Mar 2013 18:20:22 -0000 --14dae934070d0f83b004d781fe09 Content-Type: text/plain; charset=ISO-8859-1 Hi, A new version of the NMDC document is now available at < http://nmdc.sourceforge.net/Versions/NMDC-1.3.html>. Note that the versioning is the document's version, not the protocol, of which hasn't changed in quite some time. There is also a new version of the URI scheme available at . The new URI scheme document; * All sections are updated to be more explicit and each section should be more focused compared to before. * The security concerns are addressed. Note that the NMDC document addresses some security items that are general for the protocol, hence the reference. * The document should use more references to other RFCs (notably 3986) and use phrasing such as "SHOULD" and "MUST" to follow the 'RFC text standard'. * The document should address many items that have been noted (see e.g. Eric's mail). * References to what some implementations support. * Added a 'nmdcs' part to the document; I don't know if this is appropriate for the document, though. (nmdcs is the TLS equivalent of the dchub URI.) There's relatively low implementation support for it, but it can easily be removed if it's deemed not widespread enough. I am sure you all can understand that we want to push for a permanent URI scheme. :) If anything, it improves our own documentation and forces us to consider things that may be obvious for the active development community but not for an 'outsider'. On Fri, Feb 22, 2013 at 4:13 PM, Graham Klyne wrote: > I took a quick look. It appears to be a vibrant developer community > there, but I got a bit lost looking, e.g., for possible clues about > interoperability of different implementations. > I can understand the concern for interoperability (see the new URI for some). I don't currently have information on "x implementation support y command" etc, but I'm sure we could compile such a list. I am unsure where this information should be stored, but that's probably more of a concern for me than you. On Fri, Feb 22, 2013 at 4:13 PM, Graham Klyne wrote: > > The adcs: reference wasn't useful to me, as my browser doesn't know what > to do with it - this is a perennial problem with new URI schemes, and is > one reason why there is some reluctance to allow new permanent schemes - > it's extremely difficult and expensive to get new schemes widely deployed. > Ah, yeah, that's why I hinted at downloading the most widely used clients. (The client is Windows only, but there's e.g. Jucy that is Java so it should work if you're on a different OS.) I should note that there's not necessarily more implementation support for dchub than for adcs, there's just more links for the former. It's also why I asked about a potential IRC channel, since I know it's may be more widely known. Note that our estimates show that there's many thousands of users daily on DC, all of which has a client capable of. See < http://dcpp.wordpress.com/2012/07/11/statistics-for-dc/> for some rudimentary stats for the client DC++ (note the post's comment). (By the way, I apologize for not responding sooner. We've had discussions and I didn't want to post anything until we had something more substantial.) -- Fredrik Ullner --14dae934070d0f83b004d781fe09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

A new version of the NMDC document is now available = at <http:= //nmdc.sourceforge.net/Versions/NMDC-1.3.html>. Note that the versio= ning is the document's version, not the protocol, of which hasn't c= hanged in quite some time. There is also a new version of the URI scheme av= ailable at <= http://nmdc.sourceforge.net/nmdc-uri-scheme.txt>.

The new URI scheme document;
* All sections a= re updated to be more explicit and each section should be more focused comp= ared to before.
* The security concerns are addressed. Note that = the NMDC document addresses some security items that are general for the pr= otocol, hence the reference.
* The document should use more references to other RFCs (notably 3986)= and use phrasing such as "SHOULD" and "MUST" to follow= the 'RFC text standard'.
* The document should address m= any items that have been noted (see e.g. Eric's mail).
* References to what some implementations support.
* Added a= 'nmdcs' part to the document; I don't know if this is appropri= ate for the document, though. (nmdcs is the TLS equivalent of the dchub URI= .) There's relatively low implementation support for it, but it can eas= ily be removed if it's deemed not widespread enough.

I am sure you all can understand that we want to push f= or a permanent URI scheme. :) =A0If anything, it improves our own documenta= tion and forces us to consider things that may be obvious for the active de= velopment community but not for an 'outsider'.

On Fri, Feb 22, 2013 at 4:13 PM, Graham Klyne=A0<GK@ni= nebynine.org>=A0wrote:
I took a quick look. =A0It appears to be a vibrant develo= per community there, but I got a bit lost looking, e.g., for possible clues= about interoperability of different implementations.
I can understand the concern for interoperability (see the new URI for some= ). I don't currently have information on "x implementation support= y command" etc, but I'm sure we could compile such a list. I am u= nsure where this information should be stored, but that's probably more= of a concern for me than you.
=A0
On Fri, Feb 22, 2013 at 4:13 PM, Graham Klyne=A0<GK@nin= ebynine.org>=A0wrote:
The adcs: reference wasn't useful to me, as my browser doesn't know= what to do with it - this is a perennial problem with new URI schemes, and= is one reason why there is some reluctance to allow new permanent schemes = - it's extremely difficult and expensive to get new schemes widely depl= oyed.
Ah, yeah, that's why I hinted at downloading the most= widely used clients. (The client is Windows only, but there's e.g. Juc= y <http://jucy.eu/> that is Java so i= t should work if you're on a different OS.) I should note that there= 9;s not necessarily more implementation support for dchub than for adcs, th= ere's just more links for the former. It's also why I asked about a= potential IRC channel, since I know it's may be more widely known.=A0<= /div>

Note that our estimates show that there's many thou= sands of users daily on DC, all of which has a client capable of. See <<= a href=3D"http://dcpp.wordpress.com/2012/07/11/statistics-for-dc/">http://d= cpp.wordpress.com/2012/07/11/statistics-for-dc/> for some rudimentar= y stats for the client DC++ (note the post's comment).


(By the way, I apologize for= not responding sooner. We've had discussions and I didn't want to = post anything until we had something more substantial.)

--
Fredrik Ullner
--14dae934070d0f83b004d781fe09-- From GK@ninebynine.org Sun Mar 10 09:03:05 2013 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 9B81321F8615; Sun, 10 Mar 2013 09:03:05 -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 9Io-+4AHNU5r; Sun, 10 Mar 2013 09:03:05 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id EAD4C21F85F5; Sun, 10 Mar 2013 09:03:04 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1UEiiF-0005vG-bc; Sun, 10 Mar 2013 16:03:03 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1UEiiF-0008J1-0z; Sun, 10 Mar 2013 16:03:03 +0000 Message-ID: <513CAD82.409@ninebynine.org> Date: Sun, 10 Mar 2013 15:57:54 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Fredrik Ullner References: <512663B2.20809@tibco.com> <51278B10.10200@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: uri-review@ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub 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, 10 Mar 2013 16:03:05 -0000 I took a quick scan through the URI registration, and two points occurred to me. On 09/03/2013 18:20, Fredrik Ullner wrote: > A new version of the NMDC document is now available at < > http://nmdc.sourceforge.net/Versions/NMDC-1.3.html>. Note that the > versioning is the document's version, not the protocol, of which hasn't > changed in quite some time. There is also a new version of the URI scheme > available at. 1. (nit): nmdcs is not immediately recognizable as something like "secure dchub". Is there any reason to use this name rather than, say, 'dchubs'. (Deployed systems would be a good reason.) 2. "Userinfo, queries, fragments (and more), as specified by RFC 3986, is discouraged and SHOULD NOT be used." With regard to fragment identifiers, I think it's not for the URI spec to require non-use. When a URI used by a client (e.g. dereferenced), the fragment is stripped off and not sent to the server. The client may then interpret the fragment in light of what media type is returned from the server. SO, if the dchub protocol is used to retrieve an HTML document, the fragment identifier may be used to control the disposition opf thgat document in the same way that it would be used for a HTML document retrieved using HTTP. Here, I think non-use of userinfo and queries is covered by the syntax given, so this statement could be dropped. If you choose to keep this sentence, I think the bit that says that fragments SHOULD NOT be used should be removed. ... Also, an observation. There's a lot of normative language in this template, some of which is really about the protocol, which is not common to see in URI scheme registrations (for example, under scheme semantics and interoperability considerations). While it's not formally incorrect, I'd be inclined to put some of this discussion in the protocol spec, or other specification document, and refer to it from the registration template. The usual role of a URI registration template is to provide an overview and key information about a URI scheme, supported by references to separate documentation. Your approach makes this an unusually long and complicated URI registration form. I'm not saying here that it necessarily needs to be changed, but trying to give you a sense of how many specifications approach URI registrations. #g -- From paul.hoffman@vpnc.org Sun Mar 10 10:22:36 2013 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 08AC921F869C for ; Sun, 10 Mar 2013 10:22: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 6m8V4u+F5CTm for ; Sun, 10 Mar 2013 10:22:35 -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 6E41021F868B for ; Sun, 10 Mar 2013 10:22:31 -0700 (PDT) Received: from [172.19.131.148] ([12.130.118.40]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2AHLvYM085864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Mar 2013 10:22:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20130310042250.GE33497@mx1.yitter.info> Date: Sun, 10 Mar 2013 10:21:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> References: <20130310042250.GE33497@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 10 Mar 2013 17:22:36 -0000 > 1. Do people think this is work that needs to be done? Yes. The idea keeps coming up in various venues, and people default to = the Public Suffix List because there is nothing else, even thought that = list is often out-of-date. > 2. Do either of the above proposals seem like a good starting > point? draft-sullivan-domain-origin-assert seems like a good starting point. > 3. If so, who is willing to do work on this (by reviewing and so > on). =20 I am willing to review and contribute text and examples. --Paul Hoffman= From ajs@anvilwalrusden.com Sun Mar 10 11:30:01 2013 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 B6CDE21F84C9 for ; Sun, 10 Mar 2013 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 P0tJyoOaSK-Y for ; Sun, 10 Mar 2013 11:30:01 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4B17F21F84E8 for ; Sun, 10 Mar 2013 11:30:01 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 52F5B8A031 for ; Sun, 10 Mar 2013 18:30:00 +0000 (UTC) Date: Sun, 10 Mar 2013 14:29:28 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130310182928.GE37514@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 10 Mar 2013 18:30:01 -0000 On Sun, Mar 10, 2013 at 09:09:21AM +0100, Patrik Fältström wrote: > > I feel two things are included in the proposal: > > 1. Whether for example cookies should be set on the domain name > 2. Whether two (or more) domain names are within the same policy domain I claim that (1) is actually just an instance of (2), and it just so happens to be the worst irritant of these cases so it's the one people talk about. > This will be managed by either the owner of tld if there is no zone cut, or co.tld if there is a zone cut. A significant point of this proposal is to get this away from trying to use the zone cut as in any way meaningful in this context. It's the illusion that a zone cut tells you anything here that we need to combat. That was a category mistake that people made early on. Moreover, when I initially thought about this, I thought that maybe we could link the SOPA record to zone cuts; but I quickly realized that the zone cut is really an orthoganal issue, and we shouldn't nail this problem to that one. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paf@frobbit.se Sun Mar 10 12:03:21 2013 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 E542F11E80DC for ; Sun, 10 Mar 2013 12:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 2E-ccQrmwshm for ; Sun, 10 Mar 2013 12:03:21 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2EB11E80D2 for ; Sun, 10 Mar 2013 12:03:21 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) by mail.frobbit.se (Postfix) with ESMTPSA id A49D8217C4; Sun, 10 Mar 2013 20:03:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20130310182928.GE37514@mx1.yitter.info> Date: Sun, 10 Mar 2013 20:03:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EB68C60-4146-4072-A005-DA8DD9AF7993@frobbit.se> References: <20130310042250.GE33497@mx1.yitter.info> <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se> <20130310182928.GE37514@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 10 Mar 2013 19:03:22 -0000 On 10 mar 2013, at 19:29, Andrew Sullivan = wrote: > A significant point of this proposal is to get this away from trying > to use the zone cut as in any way meaningful in this context. It's > the illusion that a zone cut tells you anything here that we need to > combat. That was a category mistake that people made early on. Yes, I remember that, agree with this try to get out of that trap, but I = fell into it :-( > Moreover, when I initially thought about this, I thought that maybe we > could link the SOPA record to zone cuts; but I quickly realized that > the zone cut is really an orthoganal issue, and we shouldn't nail this > problem to that one. Sorry for using that term. My fault. Let me express it differently, "should a cookie (etc) be possible to set = for this domain name?".. paf From hallam@gmail.com Sun Mar 10 12:12:32 2013 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 781CB21F866F for ; Sun, 10 Mar 2013 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Rqbhs8iuVG4g for ; Sun, 10 Mar 2013 12:12:32 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C559B21F8629 for ; Sun, 10 Mar 2013 12:12:31 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id ds1so1388079wgb.0 for ; Sun, 10 Mar 2013 12:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1Ec7Z+dLH/fJ8dlZZv08Nd190rDiL1B6UhtxzrsSa/o=; b=EfpcG7qY7zRWhEFOG4quruFWiIfhzc/nrG4ml0yle4CYeBPj1Dsc02Dx+CsZyGIvq8 lS5v5Ljk4aTDcefSzUT73/bm7+vUOwLJDb8CDJF7As48jvGtmeLEuCAFAqzqZgzuCPOY +6apXveds6aSuzf+yJ1t17ewlHGEjsVAY08wUA3wfYiX7+SMye9YQvKvsp7qoKBUB9Av Grf4dJ9MEBZ+cPSL8WrYgCppXdTt7+cgIgUkqicU+yKo1VgOYSBXoDljpdu7DxPHDyKg 5K5tgBi8YPKAz+KRcTkXOxmxm9uhQn9PMCgcMJTdMSCNsvh+Up1niosrq+xv7Ytyc1cb zmzw== MIME-Version: 1.0 X-Received: by 10.194.63.240 with SMTP id j16mr14866306wjs.45.1362942751022; Sun, 10 Mar 2013 12:12:31 -0700 (PDT) Received: by 10.194.11.71 with HTTP; Sun, 10 Mar 2013 12:12:30 -0700 (PDT) In-Reply-To: <2EB68C60-4146-4072-A005-DA8DD9AF7993@frobbit.se> References: <20130310042250.GE33497@mx1.yitter.info> <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se> <20130310182928.GE37514@mx1.yitter.info> <2EB68C60-4146-4072-A005-DA8DD9AF7993@frobbit.se> Date: Sun, 10 Mar 2013 15:12:30 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 10 Mar 2013 19:12:32 -0000 I think that there are two separate sets of security requirements here and there is therefore a need to be able to state either * This domain is a public delegation point * This domain is NOT a public delegation point. Andrew's proposal seems to be limited to the security issues of cookies. I think there is a much better way to solve the security problems of cookies, one that is guaranteed to be 100% reliable, albeit not one that is likely to be acceptable... The reason I want both types of assertion is that we use the public suffix list in a different way when we are issuing a certificate and the security concerns are rather different as a result. In particular CAs are only ever going to consider information retrieved from the DNS as 'evidence'. It is never going to be considered to be 'proof' and never relied on to the exclusion of any other information. From internet-drafts@ietf.org Sun Mar 10 20:18:11 2013 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 A6E5E21F8970; Sun, 10 Mar 2013 20:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-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 KyHuTbI9ym95; Sun, 10 Mar 2013 20:18:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9E421F898A; Sun, 10 Mar 2013 20:18:09 -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.42 Message-ID: <20130311031809.1719.63660.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2013 20:18:09 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-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: Mon, 11 Mar 2013 03:18:11 -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 Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-11.txt Pages : 22 Date : 2013-03-10 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gsalguei@cisco.com Sun Mar 10 21:39:28 2013 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 D70C621F826B for ; Sun, 10 Mar 2013 21:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 kSwIDdXL4z8v for ; Sun, 10 Mar 2013 21:38:58 -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 0822221F8999 for ; Sun, 10 Mar 2013 21:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7950; q=dns/txt; s=iport; t=1362976730; x=1364186330; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dlt/GQw0GEGevJfYl0inZiCL73SgUokTj64hRVOLgSU=; b=IKQ1QELv/QPw55rPmAyYDdHg7fxdyB/OBLwCfKJwWeHSy2FxGMKP7dXb MF4fL75lwbKVcbr/pYXDwOfFPs0RUZ8NzN4QQ+VBzjupRouMC+WvEa9mt AeAUSsf9PGRIjGtKV5dvvpRXwH1N3NhL/S+0bcsQ+LoYYYFLmjFmwsggE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAIFePVGtJV2a/2dsb2JhbABDhUe/BoFRFnSCJAEBAQQBAQFrCwwEAgEZAwECFggKBycLFAcCCAIEDgUJiAoHBbwFjU2BHxEGBwQGAQYEglVhA5ZVgR6KQYUWgwqBcw X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208,217";a="185938568" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 11 Mar 2013 04:38:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2B4cnxw023355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 04:38:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 23:38:49 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: General discussion of application-layer protocols Thread-Topic: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-11.txt Thread-Index: AQHOHgeRqxS4MMaUckCvASkhqrNoCJif6JZU Date: Mon, 11 Mar 2013 04:38:48 +0000 Message-ID: <88296BD0-978C-4745-8666-9FDDB80ED9F1@cisco.com> References: <20130311031809.1719.63660.idtracker@ietfa.amsl.com>, <513D4DCA.3070308@packetizer.com> In-Reply-To: <513D4DCA.3070308@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_88296BD0978C474586669FDDB80ED9F1ciscocom_" MIME-Version: 1.0 Cc: Barry Leiba Subject: [apps-discuss] Fwd: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-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: Mon, 11 Mar 2013 04:39:29 -0000 --_000_88296BD0978C474586669FDDB80ED9F1ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI Begin forwarded message: From: "Paul E. Jones" > Date: March 10, 2013, 11:21:46 PM EDT To: >, "webfinger@googlegroup= s.com" > Subject: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinger-11.txt FYI. New draft is posted that should include all of the changes Barry reco= mmended. Paul -------- Original Message -------- Subject: I-D Action: draft-ietf-appsawg-webfinger-11.txt Date: Sun, 10 Mar 2013 20:18:09 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: apps-discuss@ietf.org 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 Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-11.txt Pages : 22 Date : 2013-03-10 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger --_000_88296BD0978C474586669FDDB80ED9F1ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI

Begin forwarded message:

From: "Paul E. Jones" <paulej@packetizer.com>
Date: March 10, 2013, 11:21:46 PM EDT
To: <webfinger@ietf.org= >, "webfinger@googleg= roups.com" <webfi= nger@googlegroups.com>
Subject: [webfinger] Fwd: I-D Action: draft-ietf-appsawg-webfinge= r-11.txt

FYI.  New draft is posted that should include all of the changes = Barry recommended.

Paul

-------- Original Message --------
Subject: I-D Action: draft-ietf-appsawg-webfinger-11.txt
Date: Sun, 10 Mar 2013 20:18:09 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: apps-discuss@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
 This draft is a work item of the Applications Area Working Group Working G=
roup of the IETF.

	Title           : WebFinger
	Author(s)       : Paul E. Jones
                          Gonzalo Salgueiro
                          Joseph Smarr
	Filename        : draft-ietf-appsawg-webfinger-11.txt
	Pages           : 22
	Date            : 2013-03-10

Abstract:
   This specification defines the WebFinger protocol, which can be used
   to discover information about people or other entities on the
   Internet using standard HTTP methods.  WebFinger discovers
   information for a URI that might not be usable as a locator
   otherwise, such as account or email URIs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-=
appsawg-webfinger

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-w=
ebfinger-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraf=
t-ietf-appsawg-webfinger-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______________________________________________
webfinger mailing list
webfinger@ietf.org https://w= ww.ietf.org/mailman/listinfo/webfinger
--_000_88296BD0978C474586669FDDB80ED9F1ciscocom_-- From hallam@gmail.com Mon Mar 11 04:42:17 2013 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 C0CA121F8750 for ; Mon, 11 Mar 2013 04:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 IgGtTXz3L1KY for ; Mon, 11 Mar 2013 04:42:16 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0A48521F8A35 for ; Mon, 11 Mar 2013 04:42:04 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id 12so4903337wgh.7 for ; Mon, 11 Mar 2013 04:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Vc6aa9JLRoeJ+fyoNMdJwgTx0WK+kI+rGwgg5l/Hyn4=; b=bkBnrMwZCGkBvzfH08MhcUTwIOBJtT7fm56Ub43voQ8HwY6rKM8him5IU3N2/F/wKR V9lZyOhdDKXH2dSWMFsXhxtBg8fVrU0LDmgCkxANCmZUkUQDu9r7vyYRH+5AgjcBy3R8 89ITwd9twWuqvlMcFD/L2BTfAO6dRu8zuhKlT3bOc+eKOngTBbyEm+iPKgb41ulL7/Mf IC+oeL48hMCrzKWrnET6g65n4hlKpbOYhNZrHq0oPYSla0jW8x8exqpc3LT2FP2XhxDw 37Uu8iHRarzuxPoXA7M4HhMEQT1DI7pN8K18+HcbOMGADCgo7TMOMaYSUTWodeZoCHj9 tXCQ== MIME-Version: 1.0 X-Received: by 10.180.97.132 with SMTP id ea4mr11768502wib.23.1363002124182; Mon, 11 Mar 2013 04:42:04 -0700 (PDT) Received: by 10.194.11.71 with HTTP; Mon, 11 Mar 2013 04:42:04 -0700 (PDT) In-Reply-To: References: <20130310042250.GE33497@mx1.yitter.info> <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se> <20130310182928.GE37514@mx1.yitter.info> <2EB68C60-4146-4072-A005-DA8DD9AF7993@frobbit.se> Date: Mon, 11 Mar 2013 07:42:04 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 11 Mar 2013 11:42:17 -0000 Looks like my plane is not getting in till 10:15, probably won't make apps area wg. My main concern is that anyone with useful information be able to share it through the DNS rather than perpetuate a host of external registries and folklore. The new TLD operators are positioned to provide information and that would be useful. Switching the cookie protocol so that it is less insane seems like a good thing to do but takes longer. On Sun, Mar 10, 2013 at 3:12 PM, Phillip Hallam-Baker wrote: > I think that there are two separate sets of security requirements here > and there is therefore a need to be able to state either > > * This domain is a public delegation point > * This domain is NOT a public delegation point. > > Andrew's proposal seems to be limited to the security issues of > cookies. I think there is a much better way to solve the security > problems of cookies, one that is guaranteed to be 100% reliable, > albeit not one that is likely to be acceptable... > > The reason I want both types of assertion is that we use the public > suffix list in a different way when we are issuing a certificate and > the security concerns are rather different as a result. In particular > CAs are only ever going to consider information retrieved from the DNS > as 'evidence'. It is never going to be considered to be 'proof' and > never relied on to the exclusion of any other information. -- Website: http://hallambaker.com/ From ajs@anvilwalrusden.com Mon Mar 11 05:23:00 2013 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 A276421F8794 for ; Mon, 11 Mar 2013 05:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 3S3Gcmi3hCOd for ; Mon, 11 Mar 2013 05:23:00 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7B921F86AF for ; Mon, 11 Mar 2013 05:23:00 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A1D998A031 for ; Mon, 11 Mar 2013 12:22:49 +0000 (UTC) Date: Mon, 11 Mar 2013 08:22:33 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130311122232.GJ37925@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <75239F19-93AF-40EF-A367-0E289A6D1269@frobbit.se> <20130310182928.GE37514@mx1.yitter.info> <2EB68C60-4146-4072-A005-DA8DD9AF7993@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 11 Mar 2013 12:23:00 -0000 On Sun, Mar 10, 2013 at 03:12:30PM -0400, Phillip Hallam-Baker wrote: > I think that there are two separate sets of security requirements here > and there is therefore a need to be able to state either > > * This domain is a public delegation point > * This domain is NOT a public delegation point. > > Andrew's proposal seems to be limited to the security issues of > cookies. I don't see why. In fact, quite the opposite. I think the "public delegation point/not public point" dichotomy is too narrow. In general, we can say that for administrative purposes, there are possible close administrative relationships between names. One such relationship is "none". If such a name also has any names beneath it, then for the purposes of cookies (or CAs, or anything else) it is a public "delegation" point. (Note the scare quotes. Delegation is strictly speaking a matter of adding apex records at that point in the DNS graph. But that's not relevant here: think of "web hotel" kind of cases, which needn't delegate and yet are clearly cases where the different names are not in the same administrative realm.) If you don't treat the "is this a public delegation point?" as an empirical matter (are there names beneath me?), then you are subject to assertions by people that they do not do public delegation, when in fact they do. I'm sure there's some genius in some new TLD applicant company who would like to turn that into a "feature". > the security concerns are rather different as a result. In particular > CAs are only ever going to consider information retrieved from the DNS > as 'evidence'. It is never going to be considered to be 'proof' and > never relied on to the exclusion of any other information. Of course. It's the DNS, not the Lord's Promise Protocol :) A -- Andrew Sullivan ajs@anvilwalrusden.com From mnot@mnot.net Mon Mar 11 06:44:34 2013 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 A612F21F8522 for ; Mon, 11 Mar 2013 06:44:34 -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 FJGh85VyCMTe for ; Mon, 11 Mar 2013 06:44:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFA021F8480 for ; Mon, 11 Mar 2013 06:44:23 -0700 (PDT) Received: from [172.30.21.201] (unknown [72.246.0.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CF5D222E259; Mon, 11 Mar 2013 09:44:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <397B382EC2E6D9479F9A5D6D050FB70747A8663E@WO-SFOEXCH-02.wideorbit.com> Date: Mon, 11 Mar 2013 09:44:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <84ADC755-04EC-43B6-8F1E-417FC297BE1E@mnot.net> References: <397B382EC2E6D9479F9A5D6D050FB70747A8663E@WO-SFOEXCH-02.wideorbit.com> To: Steffen Yount X-Mailer: Apple Mail (2.1499) Cc: Kris Zyp , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Ultimate and penultimate array references with json-pointers? 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, 11 Mar 2013 13:44:34 -0000 Hi Steffen, JSON Pointer is already in the RFC Editor queue, so it's too late to = make this sort of change. Cheers, On 10/03/2013, at 4:52 AM, Steffen Yount wrote: > Hi Paul, Kris, & Mark, >=20 > I'm working on a json-hyper-schema integration that relies on = json-pointers where I want a single json-pointer value that can = reference the last or possibly second to last item in a variable length = JSON array. >=20 > Unfortunately, the json-pointer definition as-is has no built-in = mechanism to support this kind of tail-offset array reference. >=20 > Would it be possible to modify the "draft-ietf-appsawg-json-pointer" = I-D to support negative values as array-indexes where a value (-x) would = be semantically equivalent to the positive index value (array.length - = x)? >=20 > Example references for the last and second to last elements could look = like: > "/foo/-1" "baz" > "/foo/-2" "bar" > #/foo/-1 "baz" > #/foo/-2 "bar" >=20 >=20 > The new wording for the JSON Array evaluation section could look like: >=20 >=20 > o If the currently referenced value is a JSON array, the reference > token MUST contain either: >=20 > * characters representing a positive base-10 integer value (see=20= > ABNF below; note that leading zeros are not allowed), making=20= > the new referenced value the array element identified by the=20= > zero-based index value in the token, or >=20 > * characters representing a negative base-10 integer value,=20 > making the new referenced value the array element identified=20= > by the zero-based index value found by adding the negative > token value to the count of elements in the array, or >=20 > * exactly the single character "-", making the new referenced > value the (non-existent) member after the last array element. >=20 > The ABNF syntax for array indices is: >=20 > array-index =3D %x30 / ( *(%x2D) %x31-39 *(%x30-39) ) / %x2D > ; "0", a signed integer without a leading "0", or "-" >=20 >=20 >=20 > Yes? No? Your thoughts? >=20 > Thanks for your consideration, > -Steffen -- Mark Nottingham http://www.mnot.net/ From Jeff.Hodges@KingsMountain.com Mon Mar 11 07:00:08 2013 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 8578621F85B3 for ; Mon, 11 Mar 2013 07:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 ueM5gQP5gnta for ; Mon, 11 Mar 2013 07:00:07 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 6A0D021F8700 for ; Mon, 11 Mar 2013 07:00:06 -0700 (PDT) Received: (qmail 23694 invoked by uid 0); 11 Mar 2013 13:59:43 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 11 Mar 2013 13:59:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=UufqIJlXiWDEcFZU0hFLPGiSbMpsBh8TuE/R0ypSFxs=; b=5Y2qVHxY9Yp0LINHnqrbdpJoclrmTFWVMn2hDL/cbRvLoVwwDgZhnUFDXsPANfqLI8eeXVW8qCf12uFWWkCaUNHrcyKyFet+c1+Crikc3PP0gC/RzCGIamc3/rTrG4na; Received: from [130.129.80.110] (port=38591) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UF3GR-0001MQ-Nb for apps-discuss@ietf.org; Mon, 11 Mar 2013 07:59:43 -0600 Message-ID: <513DE34E.9000504@KingsMountain.com> Date: Mon, 11 Mar 2013 06:59:42 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.80.110 authed with jeff.hodges+kingsmountain.com} Subject: Re: [apps-discuss] "finding registered domains" 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, 11 Mar 2013 14:00:08 -0000 Paul Hoffman wrote: > >> 1. Do people think this is work that needs to be done? > > Yes. The idea keeps coming up in various venues, and people default to the Public Suffix List because there is nothing else, even thought that list is often out-of-date. > >> 2. Do either of the above proposals seem like a good starting >> point? > > draft-sullivan-domain-origin-assert seems like a good starting point. > >> 3. If so, who is willing to do work on this (by reviewing and so >> on). > > I am willing to review and contribute text and examples. +1 =JeffH From dave@cridland.net Mon Mar 11 08:23:22 2013 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 37F8D11E8108 for ; Mon, 11 Mar 2013 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 F5VMBNhU0xjQ for ; Mon, 11 Mar 2013 08:23:21 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id E059821F8A89 for ; Mon, 11 Mar 2013 08:23:20 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id i10so4678273oag.0 for ; Mon, 11 Mar 2013 08:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=V89eZ/V8MC2kquAhi/AUvifxKgJyL6Z5aSehH07F26s=; b=MiKIxTecbIVxymYFv9Ozww+pWK9I0dGLQGEvlH2R0bG3fkpGWnhaISeLYsBVuZJrUf auC6ajvir+QBzIwR/crIBaT7eyqWBliOM6lv/7mQMeX5Wv5ugo6RKVcTpK6zXuVcRwrC fDDhfB3W5jAb9togDxA1pjLVu9KkyH2gCcIfo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=V89eZ/V8MC2kquAhi/AUvifxKgJyL6Z5aSehH07F26s=; b=Bs7eJxB492rnNyDVozPRk4s0mE9kI2G4CYhiUILi42QvC0dtFpUeUeElpl+bM22kFw m/7I1/W5XXw9Ei1sr9FIRjZcJDEuciEb7g2HsIWNDBlsD8KxMjGGdg4EkTKCF7ELrog+ /Cq3whMZFKE22NNNaKQZ47IDoehMjoNbbLWO/aFp5JN98jbvhBuywPR6LXu7jwYR67E6 NxW4qMs9gMbPJ8BXuhrvQVRaA/wgxyqzoSmfr6c8nMXV8TMh0LLLd9GlxHw5wj9mLFfH 938Pt+WBwpryv306ZcgQQP7rDBFlH22/8mlDAMdcs002zQgHTTGM/hgww3pCGthzI+ag YrVg== MIME-Version: 1.0 X-Received: by 10.182.156.103 with SMTP id wd7mr8912046obb.33.1363015400451; Mon, 11 Mar 2013 08:23:20 -0700 (PDT) Received: by 10.60.19.40 with HTTP; Mon, 11 Mar 2013 08:23:20 -0700 (PDT) Date: Mon, 11 Mar 2013 15:23:20 +0000 Message-ID: From: Dave Cridland To: "apps-discuss@ietf.org" , draft-ietf-appsawg-webfinger.all@tools.ietf.org, iesg@ietf.org Content-Type: multipart/alternative; boundary=f46d0444e835c4a47f04d7a7c054 X-Gm-Message-State: ALoCoQnqgbQzWBRb4uOSgUqAuuRJp6N0EXpz455+k6VhyUrouh84nbC7cpaLsIzomnwY1H00Yz/V Subject: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 11 Mar 2013 15:23:22 -0000 --f46d0444e835c4a47f04d7a7c054 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=20 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-appsawg-webfinger-11 Title: Webfinger Reviewer: Dave Cridland Review Date: 2013/03/11 IESG Telechat Date: 2013/03/28 Summary: Close to ready for publication as standards track; some comments which suggest a new version may be required and/or technical discussion needed. Minor Comments: 1) There's some suggestions that webfinger could be used for email autoconfig; I suspect this is at best going to cause confusion especially when there's a BOF tomorrow on the subject. This feels like text that doesn't need to be present. Also, it's a cursed subject anyway; see ACAP. :-) Major Comments: 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines and repeats RFC 5988's =A74; I think this should be deferred explicitly to RFC 5988 in entirety, rather than specifically only for registered link relation types. The good news is that this should simplify the text rather a lot: """ The value of the "rel" member is a string containing a link relation type (see RFC 5988 [4]). Both registered and extended relation types are permitted. """ 2) The use of webfinger with arbitrary URIs is something I had not previously realised. This raises some concerns for me, as it's not clear whether this is either genuinely desirable or whether it introduces considerations (security and otherwise) beyond those discussed within the document. I would in general rather the mechanism were restricted to acct, http, https, and perhaps mailto. 3) There is no use of SRV here; I would prefer an SRV resolution step for at least acct and mailto scheme URIs, and possibly http/https as well. My concern is that a corporate webserver is typically unlikely to be capable of providing webfinger services (being often externally hosted), and while this could be solved by handling redirects, or by reverse proxying, SRV feels like a more stable solution here. I'd be curious as to whether this has been discussed. 4) It would make =A78 more readable if it were split into subsections. I think the first three paragraphs form a discussion about the transport security, the middle paragraphs discuss privacy, and the final paragraph discusses information reliability. I suspect there is one more case to be concerned about, which is that it may be possible for an attacker to use webfinger resources to test the existence of a hypothetical user; that is, one might use webfinger as a harvesting mechanism. Dave. --f46d0444e835c4a47f04d7a7c054 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have been selected as the Applications Area Directo= rate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora= te ).

Please resolve these comments along with any othe= r Last Call comments you may receive. Please wait for direction from your d= ocument shepherd or AD before posting a new version of the draft.
Document:=A0draft-ietf-appsawg-webfinger-11
Title: Webfinger=
Reviewer: Dave Cridland
Review Date: 2013/03/11
<= div>IESG Telechat Date: 2013/03/28
Summary: Close to ready fo= r publication as standards track; some comments which suggest a new version= may be required and/or technical discussion needed.

Minor Comments:

1) There's some suggestions that webfinger could be used for email = autoconfig; I suspect this is at best going to cause confusion especially w= hen there's a BOF tomorrow on the subject. This feels like text that do= esn't need to be present.

Also, it's a cursed subject anyway; see= ACAP. :-)

Major Comments:

1) I note that =A74.4.4.1 describes a 'rel= 9; such that it redefines and repeats RFC 5988's =A74; I think this sho= uld be deferred explicitly to RFC 5988 in entirety, rather than specificall= y only for registered link relation types.

The good news is that this should simplify = the text rather a lot:

""&qu= ot;
The value of the "rel" member is a string con= taining a link relation type (see RFC 5988 [4]). Both registered and extend= ed relation types are permitted.
"""

2) The u= se of webfinger with arbitrary URIs is something I had not previously reali= sed. This raises some concerns for me, as it's not clear whether this i= s either genuinely desirable or whether it introduces considerations (secur= ity and otherwise) beyond those discussed within the document.

I would in general rather the mechanism wer= e restricted to acct, http, https, and perhaps mailto.

=
3) There is no use of SRV here; I would prefer an SRV reso= lution step for at least acct and mailto scheme URIs, and possibly http/htt= ps as well. My concern is that a corporate webserver is typically unlikely = to be capable of providing webfinger services (being often externally hoste= d), and while this could be solved by handling redirects, or by reverse pro= xying, SRV feels like a more stable solution here.

I'd be curious as to whether this has b= een discussed.

4) It would make =A78 m= ore readable if it were split into subsections. I think the first three par= agraphs form a discussion about the transport security, the middle paragrap= hs discuss privacy, and the final paragraph discusses information reliabili= ty.

I suspect there is one more case to be conc= erned about, which is that it may be possible for an attacker to use webfin= ger resources to test the existence of a hypothetical user; that is, one mi= ght use webfinger as a harvesting mechanism.

Dave.
--f46d0444e835c4a47f04d7a7c054-- From jtrentadams@gmail.com Mon Mar 11 11:07:30 2013 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 5B26E11E81A7 for ; Mon, 11 Mar 2013 11:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 Y-Kh1vQY3s3K for ; Mon, 11 Mar 2013 11:07:29 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3923A11E81C3 for ; Mon, 11 Mar 2013 11:07:29 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so5135431iea.26 for ; Mon, 11 Mar 2013 11:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=YBlE7ItANeCDt26l0/r4GWgl+FlA0bBjJT4LwnC/xOk=; b=YOObezghPr3FHaJVgLPacq0EqrM951cQp91MaYeEo+vhBe5eFgK77OTmJ3yX8BVj/B CqFtyotypADjV35K3AovR6eeoMyBoO0p7MQyeQtSI83LgvhMVkLL79QQn4zr34ypHONJ qYY6Q930ELoPN/T+B9M7YTS089SJ8RyhHkhrX4zzC200J2nF3BKbxCkcGcN1/2usT/ly H5zD4RBnTILd9EtpzqkxLrZ9e0VEJ4C4Zq+yxu+Ahgix1e5OXeUVLBph6je4twHp8cJ6 3W9iwo+cn/VEZcfUrJ2uDbIWY/5IRiAJPwaQ5BQG7yUaWCQOhrpqPAofIMkyoEcYlZI/ 66ug== X-Received: by 10.50.173.102 with SMTP id bj6mr8282806igc.16.1363025248843; Mon, 11 Mar 2013 11:07:28 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPS id ip2sm14148719igc.5.2013.03.11.11.07.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 11:07:27 -0700 (PDT) Message-ID: <513E1D5F.8080806@gmail.com> Date: Mon, 11 Mar 2013 12:07:27 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130310042250.GE33497@mx1.yitter.info> In-Reply-To: <20130310042250.GE33497@mx1.yitter.info> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] "finding registered domains" 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, 11 Mar 2013 18:07:30 -0000 1. Do people think this is work that needs to be done? Coming up with a workable solution for identifying administrative boundaries within domains is clearly important for many known use cases, plus a sufficiently general solution would service many more uses that are currently unknown. We undoubtedly need to ween ourselves from the public suffix list, especially as the longer the issue is left unaddressed the more hacks or non-scalable work-arounds that will proliferate. As a case in point, the emerging DMARC work would benefit from this type of solution. 2. Do either of the above proposals seem like a good starting point? Having read http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02 pretty closely, and discussed it with my colleagues, I believe that this is a perfectly reasonable starting point. I don't believe it's the perfect solution in its current state (and I personally prefer the name-only variant), but believe we can easily use it as a solid aggregation point around which to build the right solution. 3. If so, who is willing to do work on this (by reviewing and so on). Yes, I can commit to spending time on this work. Thanks, Trent On 3/9/13 9:22 PM, Andrew Sullivan wrote: > Dear colleagues, > > In the APPSAWG meeting on Monday, the chairs have asked me to take > five minutes on the subject: topic. I thought I'd better send a note > in preparation. > > ICANN is in the process of awarding a little under 2000 new TLDs. > Inspired, I believe, partly by that fact, Phill Hallam-Baker suggested > a new DNS RRTYPE that would identify a name as a public suffix. > Unfortunately, he fell ill and didn't have a chance to submit a draft > on this. > > I'm opposed to that particular idea, however, because I think I have > proposed a more generic mechanism that would still work just as well > for that use case, and also allow future refinements. I've outlined > that mechanism in > http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02. > > I won't have any slides on Monday; I really just want to learn the > following: > > 1. Do people think this is work that needs to be done? > > 2. Do either of the above proposals seem like a good starting > point? > > 3. If so, who is willing to do work on this (by reviewing and so > on). > > (3) is especially important to me, because I received rather too > little feedback on the draft I offered to think that anyone else is > interested in pursuing it. If people are interested in that draft, > I'm certainly prepared to continue working on it. > > Best regards, > > A > -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From superuser@gmail.com Mon Mar 11 11:14:10 2013 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 F18A811E81FD for ; Mon, 11 Mar 2013 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 w6GfeVmRfqFO for ; Mon, 11 Mar 2013 11:14:09 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 06C3711E81EB for ; Mon, 11 Mar 2013 11:14:08 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id k14so3747624wer.25 for ; Mon, 11 Mar 2013 11:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Mz8u9TRrSYvxJBDalpFtlweyt4Q2kFuwB24utYmZCpI=; b=Gl9KX5O1YEAxLqLu6upzDOhv3WdyYpz8mGlF3mXSO++S0jZbBm2oMf8bh3HrZ8UDTx TLRnvYAKzsXGAQl4YFximy2gfsmTRMIKcTUnXO5RslG6KWeVxIwWL+8DZccXaHQiPqiM 4/VAEdBBI2tOCMB/BNHX9veNAu57JVgU7qUlKPUPFkMPO9U3Q+Ls0btk9QRbx/jY0jip VlxOOcRCodm2rBNslviX53rJJWS6Li7wmPxGwdBs7s0nnrKaJb4bykV5wbiJlmFSLXz7 6TVnetSm02FY1GR2Q5KS1Rz6/fKofrJWzC4xm7sYqrpdC10SDee1q2I+2sLjRnojJ3nQ eswA== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr14629648wiy.5.1363025648140; Mon, 11 Mar 2013 11:14:08 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Mon, 11 Mar 2013 11:14:08 -0700 (PDT) In-Reply-To: <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> Date: Mon, 11 Mar 2013 14:14:08 -0400 Message-ID: From: "Murray S. Kucherawy" To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d04428eb693c79e04d7aa2386 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] "finding registered domains" 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, 11 Mar 2013 18:14:10 -0000 --f46d04428eb693c79e04d7aa2386 Content-Type: text/plain; charset=ISO-8859-1 +1 to all of Paul's answers. -MSK, participatizing On Sun, Mar 10, 2013 at 1:21 PM, Paul Hoffman wrote: > > 1. Do people think this is work that needs to be done? > > Yes. The idea keeps coming up in various venues, and people default to the > Public Suffix List because there is nothing else, even thought that list is > often out-of-date. > > > 2. Do either of the above proposals seem like a good starting > > point? > > draft-sullivan-domain-origin-assert seems like a good starting point. > > > 3. If so, who is willing to do work on this (by reviewing and so > > on). > > I am willing to review and contribute text and examples. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04428eb693c79e04d7aa2386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 to all of Paul's answers.

-MSK, participatiz= ing


= On Sun, Mar 10, 2013 at 1:21 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> =A0 =A01. =A0Do peopl= e think this is work that needs to be done?

Yes. The idea keeps coming up in various venues, and people default t= o the Public Suffix List because there is nothing else, even thought that l= ist is often out-of-date.

> =A0 =A02. =A0Do either of the above proposals seem like a good startin= g
> =A0 =A0point?

draft-sullivan-domain-origin-assert seems like a good starting point.=

> =A0 =A03. =A0If so, who is willing to do work on this (by reviewing an= d so
> =A0 =A0on).

I am willing to review and contribute text and examples.

--Paul Hoffman
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04428eb693c79e04d7aa2386-- From superuser@gmail.com Mon Mar 11 13:23:27 2013 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 9DEDD21F8FFA for ; Mon, 11 Mar 2013 13:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.568 X-Spam-Level: ** X-Spam-Status: No, score=2.568 tagged_above=-999 required=5 tests=[AWL=-4.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, URIBL_WS_SURBL=10] 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 AMBqlzBEo3bl for ; Mon, 11 Mar 2013 13:23:26 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF3C21F8FD3 for ; Mon, 11 Mar 2013 13:23:26 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id r6so3933754wey.33 for ; Mon, 11 Mar 2013 13:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EIK3vedxVVSO8AGtTq1x6bQrquMwRfwT4yF7WchQZXc=; b=kKB5i3vI1xWgMV/OXiMTdB1mdUDv0rmYBkOlwpcjGxtri4qj7buAfXyO/gqY6qk6t4 G15JzWqwtemRMg9EuHgiyCBX06PfRNrUDczFeFiBP04hpPBiPqq5ae1dPsGo/JKL6rRU lalAr26/BN9JTkJTsOrKb8ajkHiadeeIUIWuaplOzwDgtMZ44bspydfAeV0rlsLmNOzj CfOCa3n2uvj6qMZiVhvINz9pm+Z8NziWUy6o7ncxwYNZ51AzN271WGDZMTeMykDCA99y nJPopJbG2kT4tsKHklk5pJbl2iQqC42d+aGirkOdC3JYXDnpvCEdbE/4jvWsGxVZM4JL fKdg== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr21909634wjc.35.1363033405628; Mon, 11 Mar 2013 13:23:25 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Mon, 11 Mar 2013 13:23:25 -0700 (PDT) In-Reply-To: References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> Date: Mon, 11 Mar 2013 16:23:25 -0400 Message-ID: From: "Murray S. Kucherawy" To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e013d1da8f5a7cf04d7abf1c9 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] "finding registered domains" 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, 11 Mar 2013 20:23:27 -0000 --089e013d1da8f5a7cf04d7abf1c9 Content-Type: text/plain; charset=ISO-8859-1 For the sake of taking some hallway track conversation and writing it down somewhere: The origin for this work from my perspective is the need for being able to make policy statements about a registered domain and all of its subdomains. For example, given a.b.c.d.example.com, I'd like to be able to discover somehow that a domain-level policy record could be found at example.com, where example.com is the domain name that has been assigned by a registry. This would allow for example.co.uk to be similarly discovered, i.e., the solution accommodates the idea that delegations don't happen at the first label. Today I learned that there's also a need for a solution to this or a similar problem related to the use of cookies. I'd like to understand how these are related, or instead how they are actually totally different problem spaces. I think this is important to figuring out a path forward. This has nothing to do with Andrew's proposal directly. I'm just trying to establish what the audience(s) might be, rather than focusing on my specific use case. -MSK --089e013d1da8f5a7cf04d7abf1c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the sake of taking some hallway track conver= sation and writing it down somewhere:

The origin for this work from = my perspective is the need for being able to make policy statements about a= registered domain and all of its subdomains.=A0 For example, given a.b.c.d.example.com, I'd like to be= able to discover somehow that a domain-level policy record could be found = at example.com, where example.com is the domain name that has been assigned by a= registry.=A0 This would allow for example= .co.uk to be similarly discovered, i.e., the solution accommodates the = idea that delegations don't happen at the first label.

Today I learned that there's also a need for a solution to th= is or a similar problem related to the use of cookies.

I'd like to understand how these are related, or instead how t= hey are actually totally different problem spaces.=A0 I think this is impor= tant to figuring out a path forward.

This has nothing to do with Andrew's proposal directly.=A0 I'm = just trying to establish what the audience(s) might be, rather than focusin= g on my specific use case.

-MSK
--089e013d1da8f5a7cf04d7abf1c9-- From ajs@anvilwalrusden.com Mon Mar 11 14:09:43 2013 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 64EE621F8E63 for ; Mon, 11 Mar 2013 14:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.813 X-Spam-Level: X-Spam-Status: No, score=-0.813 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 VDFW7exfjFOY for ; Mon, 11 Mar 2013 14:09:42 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8A21F8E17 for ; Mon, 11 Mar 2013 14:09:29 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D26578A031 for ; Mon, 11 Mar 2013 21:09:28 +0000 (UTC) Date: Mon, 11 Mar 2013 17:08:57 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130311210857.GG38441@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 11 Mar 2013 21:09:43 -0000 On Mon, Mar 11, 2013 at 04:23:25PM -0400, Murray S. Kucherawy wrote: > > I'd like to understand how these are related, or instead how they are > actually totally different problem spaces. I think this is important to > figuring out a path forward. In my opinion, these are in fact the very same problem, just with different expressions. At bottom, the issue is always that there is an attempt to read from the hierarchical delegation space of the DNS some sort of administrative commonality that just doesn't exist. In general, domain names just represent the labels of every node down the DNS tree from the root zone. So, the name label1.label2.label3.example.com. names several levels of the DNS tree. And labelA.labelB.labelC.example.com. also names several levels of the DNS tree. What we _cannot_ tell from any of that is who is in control of which parts. This is true regardless of whether there are any delegations (SOA records) in the tree anywhere along that FQDN. You can tell that example.com in both FQDNs are under the same control (because they're the same node), but you can't tell whether example.com is controlled by the same people who control .com (compare this with the co.uk/.uk case). Similarly, you cannot tell whether labelA.labelB.labelC.example.com. is controlled by the people who control example.com (compare this to web hotels, for instance, which have of course mostly fallen out of fashion for this reason). There are some historically good pretty good rules of thumb, but that's all they are. The "cookies problem" is just a special case: the cookies spec had peculiar rules about TLDs, and now has some special handling of sibling and children relationships, but it's still both too broad and too narrow. Does this help? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Tue Mar 12 05:37:15 2013 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 12D0121F89E2 for ; Tue, 12 Mar 2013 05:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TQKfYCsDpILd for ; Tue, 12 Mar 2013 05:37:14 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B0D3121F8713 for ; Tue, 12 Mar 2013 05:37:13 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x51so4617677wey.18 for ; Tue, 12 Mar 2013 05:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UZ8XbBupl/pp6ZVbXnkyALhQ0emkfmCrjf+GYVRyiPM=; b=wQyDm5fNVMzBsXSl+buLMmPXkJzlHph4nE6jkCfYUo4Sjnpyxv+uz9H5BKJrJxOKI6 mOVaW9XGuvP/OyF+5fhXuiVGCrAsiJxymXYdV5twKuVUAnucrLGxVy2Kd4jps51tmmye RgcZByXu5735qTw+c+1E+C7LZJZS1pkQRo60gewRYCQus6doTca0kS7vmONO30BCTOWx M4lcf3PnFxRx65uSY6g+o3hRzdnmbsuAFR8FllirQoHkaSnZsDCztzT7AMptHxMMDEBa brvUJoIvMFvTuTlTak+V4CLe+yx7CuG4w86WiSDB5urgFJb3Xqh0A9CxMe1c0yXCkQFR QnxA== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr26198037wjc.35.1363091832734; Tue, 12 Mar 2013 05:37:12 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 05:37:12 -0700 (PDT) In-Reply-To: <20130311210857.GG38441@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> Date: Tue, 12 Mar 2013 08:37:12 -0400 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=089e013d1da87c8bbb04d7b98cfa Cc: IETF Apps Discuss Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 12:37:15 -0000 --089e013d1da87c8bbb04d7b98cfa Content-Type: text/plain; charset=ISO-8859-1 It's very helpful, thanks. So for the sake of looking through all of our options, could you (or anyone) comment on why we might not want to do a downward tree walk looking for a first administrative boundary record? It seems like those walks are limited to only a couple of queries at most and could be cached for a very long time. It's also been suggested that maybe the solution for this should come from WEIRDS. The reason that might be is that we're trying to impose onto the DNS some structure that isn't there (I hope I'm paraphrasing my DNS colleagues properly there), so maybe the answer to this question should also come from outside the DNS. Is that something that deserves serious consideration, or is it off the mark? -MSK On Mon, Mar 11, 2013 at 5:08 PM, Andrew Sullivan wrote: > On Mon, Mar 11, 2013 at 04:23:25PM -0400, Murray S. Kucherawy wrote: > > > > I'd like to understand how these are related, or instead how they are > > actually totally different problem spaces. I think this is important to > > figuring out a path forward. > > In my opinion, these are in fact the very same problem, just with > different expressions. > > At bottom, the issue is always that there is an attempt to read from > the hierarchical delegation space of the DNS some sort of > administrative commonality that just doesn't exist. > > In general, domain names just represent the labels of every node down > the DNS tree from the root zone. So, the name > label1.label2.label3.example.com. names several levels of the DNS > tree. And labelA.labelB.labelC.example.com. also names several levels > of the DNS tree. > > What we _cannot_ tell from any of that is who is in control of which > parts. This is true regardless of whether there are any delegations > (SOA records) in the tree anywhere along that FQDN. You can tell that > example.com in both FQDNs are under the same control (because they're > the same node), but you can't tell whether example.com is controlled > by the same people who control .com (compare this with the co.uk/.uk > case). Similarly, you cannot tell whether > labelA.labelB.labelC.example.com. is controlled by the people who > control example.com (compare this to web hotels, for instance, which > have of course mostly fallen out of fashion for this reason). There > are some historically good pretty good rules of thumb, but that's all > they are. > > The "cookies problem" is just a special case: the cookies spec had > peculiar rules about TLDs, and now has some special handling of > sibling and children relationships, but it's still both too broad and > too narrow. > > Does this help? > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013d1da87c8bbb04d7b98cfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It's very helpful, thanks.

So f= or the sake of looking through all of our options, could you (or anyone) co= mment on why we might not want to do a downward tree walk looking for a fir= st administrative boundary record?=A0 It seems like those walks are limited= to only a couple of queries at most and could be cached for a very long ti= me.

It's also been suggested that maybe the solution for this should co= me from WEIRDS.=A0 The reason that might be is that we're trying to imp= ose onto the DNS some structure that isn't there (I hope I'm paraph= rasing my DNS colleagues properly there), so maybe the answer to this quest= ion should also come from outside the DNS.=A0 Is that something that deserv= es serious consideration, or is it off the mark?

-MSK



On Mon, Mar 11, 2013 at 5:08 PM, Andre= w Sullivan <ajs@anvilwalrusden.com> wrote:
On Mon, Mar 11, 2013 at 04= :23:25PM -0400, Murray S. Kucherawy wrote:
>
> I'd like to understand how these are related, or instead how they = are
> actually totally different problem spaces. =A0I think this is importan= t to
> figuring out a path forward.

In my opinion, these are in fact the very same problem, just with
different expressions.

At bottom, the issue is always that there is an attempt to read from
the hierarchical delegation space of the DNS some sort of
administrative commonality that just doesn't exist.

In general, domain names just represent the labels of every node down
the DNS tree from the root zone. =A0So, the name
label= 1.label2.label3.example.com. names several levels of the DNS
tree. =A0And labelA.labelB.labelC.example.com. also names several levels
of the DNS tree.

What we _cannot_ tell from any of that is who is in control of which
parts. =A0This is true regardless of whether there are any delegations
(SOA records) in the tree anywhere along that FQDN. =A0You can tell that example.com in both FQ= DNs are under the same control (because they're
the same node), but you can't tell whether example.com is controlled
by the same people who control .com (compare this with the co.uk/.uk
case). =A0Similarly, you cannot tell whether
label= A.labelB.labelC.example.com. is controlled by the people who
control example.com (c= ompare this to web hotels, for instance, which
have of course mostly fallen out of fashion for this reason). =A0There
are some historically good pretty good rules of thumb, but that's all they are.

The "cookies problem" is just a special case: the cookies spec ha= d
peculiar rules about TLDs, and now has some special handling of
sibling and children relationships, but it's still both too broad and too narrow.

Does this help?

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________________= __________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e013d1da87c8bbb04d7b98cfa-- From bhill@paypal-inc.com Tue Mar 12 07:23:20 2013 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 B370D21F899E for ; Tue, 12 Mar 2013 07:23:20 -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=[AWL=0.000, 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 W56DiT9tfbFo for ; Tue, 12 Mar 2013 07:23:19 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 69FC221F8B4C for ; Tue, 12 Mar 2013 07:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1363098199; x=1394634199; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GfcJxUJOVvIb3LlPfT2vPqV/oRbhlOkjyU7VH011Lzo=; b=qWzrXAgrptP00FIK6ojXf5SSc3+ZFT0FtbZchXGYEXadmvDifouinKXH FHmSyepKA7M8KsIIFeQrAeHdxQaQeGYPwvbYZ+It/Zf5TMfzA9BANDkSz I+L86B8pF3XuzfTb6ILMPL6VunVDnpZy/8vFJuTV5GBRW+At4fjDYg8S+ U=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.84,830,1355126400"; d="scan'208";a="13986721" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 12 Mar 2013 07:23:19 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-001.corp.ebay.com ([fe80::345e:2420:7d3d:208d%13]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 08:23:18 -0600 From: "Hill, Brad" To: Andrew Sullivan , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] "finding registered domains" Thread-Index: AQHOHUb/R4SnLKDS10yVBt4lLf5fTZiiFg1Q Date: Tue, 12 Mar 2013 14:23:18 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com> References: <20130310042250.GE33497@mx1.yitter.info> In-Reply-To: <20130310042250.GE33497@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 14:23:21 -0000 Andrew, Thank you for this important draft. A few comments: 1) I support the idea that we need something more maintainable than the pu= blic suffix list for several purposes, and I think this is a good starting = place. 2) I prefer the names-only version. I think the protocol / port issue is = an unnecessary complication. 3) I think if this is going to live in the DNS, it should respect the stru= cture of, and say things about, the DNS, rather than describing a distinct = and arbitrary overlay topology of administrative trust relationships. In = particular, I think the ability to make statements like "example.com and ex= ample.net should be able to share cookies" is a very bad idea. It is a f= eature that web developers have wanted forever, and one I'm glad they have = never gotten. Rather than be an edge-case, I think you would find a few t= hings here: a) "cousin domains" like this are actually quite common b) certain large entities would be able to exert considerable market pow= er to demand that organizations create these kinds of linkages in the DNS t= o enable cookie sharing for extremely common scenarios like tracking and an= alytics, advertising or single-sign on These two things would lead to: i) highly dynamic data that downstream consumers of a cached data set (we= b browsers) are not prepared to handle ii) a very large amount of data that downstream consumers of a cached dat= a set are not prepared to handle iii) this would make the web more brittle and insecure. The need to do e= xplicit and loosely-coupled linkages across these boundaries today, rather = than simply relying on promiscuous cookie sharing, is a very good thing for= the web, IMHO. The current restrictions on moving up/down the hierarchy only have been wor= kable thus far - there is little pressing need to change this, and I think = we do so at great peril. (and with a high likelihood that browsers would si= mply refuse to honor any such notations) 4) I am also concerned with mixing the state of siblings as to whether they= share an administrative relationship with the parent or not. Whether the = depth in the DNS hierarchy is a "real" thing or not, it has been treated as= such and been a part of the web security model for almost 20 years. The "= walk towards the root until you find a boundary, and all siblings are equal= " procedures apply not just for setting cookies, but to core JavaScript and= therefore the Same Origin Policy through a feature known as "domain loweri= ng". Domain lowering is the property that a web application is able to "lo= wer" its effective domain. (e.g. from x.y.z.example.com to y.z.example.com,= z.example.com, or example.com) While this may sound kooky, it's actually = the basis of some widely used patterns. (http://blogs.msdn.com/b/dthorpe/ar= chive/2007/09/27/cross-domain-communication-using-domain-lowering.aspx) I = think that you will find a very uphill battle to try to change this model -= many sites depend on it. And again, it has worked pretty well, despite it= s warts or whatever lack of respect for the true semantics of the DNS it sh= owed in its original design. tl;dr: remove most of the complexity and use this mechanism only to identif= y the depth(s) at which a delegation occurs, with no scheme/port, no cross-= linkages, and all siblings equal cheers, Brad Hill > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > On Behalf Of Andrew Sullivan > Sent: Saturday, March 09, 2013 11:23 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] "finding registered domains" >=20 > Dear colleagues, >=20 > In the APPSAWG meeting on Monday, the chairs have asked me to take five > minutes on the subject: topic. I thought I'd better send a note in prepa= ration. >=20 > ICANN is in the process of awarding a little under 2000 new TLDs. > Inspired, I believe, partly by that fact, Phill Hallam-Baker suggested a = new DNS > RRTYPE that would identify a name as a public suffix. > Unfortunately, he fell ill and didn't have a chance to submit a draft on = this. >=20 > I'm opposed to that particular idea, however, because I think I have prop= osed a > more generic mechanism that would still work just as well for that use ca= se, > and also allow future refinements. I've outlined that mechanism in > http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02. >=20 > I won't have any slides on Monday; I really just want to learn the > following: >=20 > 1. Do people think this is work that needs to be done? >=20 > 2. Do either of the above proposals seem like a good starting > point? >=20 > 3. If so, who is willing to do work on this (by reviewing and so > on). >=20 > (3) is especially important to me, because I received rather too little f= eedback > on the draft I offered to think that anyone else is interested in pursuin= g it. If > people are interested in that draft, I'm certainly prepared to continue w= orking > on it. >=20 > Best regards, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ietfc@btconnect.com Tue Mar 12 07:53:33 2013 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 4B26B21F8B33 for ; Tue, 12 Mar 2013 07:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 rS3RMlWhy1R2 for ; Tue, 12 Mar 2013 07:53:32 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6387021F86E3 for ; Tue, 12 Mar 2013 07:53:32 -0700 (PDT) Received: from mail87-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Mar 2013 14:53:31 +0000 Received: from mail87-ch1 (localhost [127.0.0.1]) by mail87-ch1-R.bigfish.com (Postfix) with ESMTP id 7598E48017F; Tue, 12 Mar 2013 14:53:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371I542I1432I1418Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh1954cbhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h) Received: from mail87-ch1 (localhost.localdomain [127.0.0.1]) by mail87-ch1 (MessageSwitch) id 1363100009588757_18994; Tue, 12 Mar 2013 14:53:29 +0000 (UTC) Received: from CH1EHSMHS038.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail87-ch1.bigfish.com (Postfix) with ESMTP id 82D8C60052; Tue, 12 Mar 2013 14:53:29 +0000 (UTC) Received: from DBXPRD0711HT002.eurprd07.prod.outlook.com (157.56.254.181) by CH1EHSMHS038.bigfish.com (10.43.69.247) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Mar 2013 14:53:28 +0000 Received: from DBXPRD0210HT004.eurprd02.prod.outlook.com (157.56.253.181) by pod51017.outlook.com (10.255.178.35) with Microsoft SMTP Server (TLS) id 14.16.263.1; Tue, 12 Mar 2013 14:53:28 +0000 Message-ID: <016801ce1f30$d26be260$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , Francis Galiegue References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com><1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com><1362772307.22220.22.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 12 Mar 2013 14:49:26 +0000 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.253.181] X-FOPE-CRA-SourceIpAddress: 157.56.254.181 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: apps-discuss@ietf.org X-FOPE-BFA-RECEIVER: fgaliegue@gmail.com X-FOPE-BFA-RECEIVER: superuser@gmail.com X-OriginatorOrg: btconnect.com Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 12 Mar 2013 14:53:33 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "Francis Galiegue" Cc: "Barry Leiba" ; "Paul Hoffman" ; Sent: Friday, March 08, 2013 9:57 PM Subject: Re: [apps-discuss] JSON Patch question about the remove operation > Others may disagree, but I think it's fine to send an email first to get a > couple of people to agree that the issue is real, and then open an erratum > if so. I would go further and say it is categorically not fine to post the erratum without sounding it out on e-mail first. e-mail is lightweight, costs very little to explore, to get feedback on while an erratum is heavier, costs more even when it is not accepted. Of course, if everyone agreed on what is and is not a suitable topic for an erratum, there would be no difference but I think that, increasingly, errata are being used to report things that do not warrant reporting, such as missing commas, and once the erratum is posted, there is a cost to squashing it, whereas with an e-mail, you can gently suggest - off-list - that this not really what the process is intended to be used for. The technical topics on this thread seem an excellent use of the facilities, the only regret being that they did not surface at an earlier time. Tom Petch > > On Fri, Mar 8, 2013 at 1:32 PM, Francis Galiegue wrote: > > > On Fri, Mar 8, 2013 at 10:18 PM, Paul Hoffman > > wrote: > > [...] > > > > > > The current discussion seems to be more than clarifying, because no one > > seems to have thought of them before Francis did. But it is far from clear > > that what Francis has found is the last of where the document will need to > > be clarified. > > > > > > > Sorry for that... And all the more sorry that I have just found > > another one. This time with replace. It is said that: > > > > This operation is functionally identical to a "remove" operation for > > a value, followed immediately by an "add" operation at the same > > location with the replacement value. > > > > But this is not quite true. Consider: > > > > { "op": "replace", "path": "/0", "value": 1 } > > > > against: > > > > [ true ] > > > > The remove leads to: > > > > [] > > > > and add will fail, since /0 does not exist anymore. It would have to > > be an add to "/-" to work... > > > > Rather than sending mail after mail, what is the correct way to report > > this kind of findings? > > > > -- > > Francis Galiegue, fgaliegue@gmail.com > > JSON Schema in Java: http://json-schema-validator.herokuapp.com From mnot@mnot.net Tue Mar 12 07:56:13 2013 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 E213911E80A2 for ; Tue, 12 Mar 2013 07:56:13 -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 o-ffjSkW0wJK for ; Tue, 12 Mar 2013 07:56:13 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 23AE311E80A5 for ; Tue, 12 Mar 2013 07:56:13 -0700 (PDT) Received: from [172.30.21.201] (unknown [72.246.0.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9347422E256; Tue, 12 Mar 2013 10:56:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> Date: Tue, 12 Mar 2013 10:56:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4388A03B-B9A8-43A1-9A90-1D16C1C3F789@mnot.net> References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> To: Paul C. Bryan X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 12 Mar 2013 14:56:14 -0000 Test cases are still more than welcome: https://github.com/json-patch/json-patch-tests Cheers, On 08/03/2013, at 1:45 PM, Paul C. Bryan wrote: > Unfortunately, these cases you're presenting are proving that the text = could still stand to be improved. Prefix relationship must be evaluated = after the move. >=20 > Paul >=20 > On Fri, 2013-03-08 at 19:19 +0100, Francis Galiegue wrote: >> On Fri, Mar 8, 2013 at 6:58 PM, Paul C. Bryan > > wrote: >>=20 >> The "from" location MUST NOT be a proper prefix of the "path" >>=20 >> location; i.e., a location cannot be moved into one of its = children.[...] >> > >> > The way it's written, if you wanted to move "victim" to the = adjacent object >> > in the array (element 1 before the move), then the last operation = above >> > would be the way to do it. >> > >> > Paul >>=20 >> Do you mean this one? >>=20 >> { "op": "move", "from": "/0", "to": "/0/x" } >>=20 >> Because according to the spec, it is not legal: >>=20 >> The "from" location MUST NOT be a proper prefix of the "path" >> location; i.e., a location cannot be moved into one of its = children. >>=20 >> Or is it meant to be that the prefix relationship must be evaluated >> _after_ the move (since in this case /0 will have changed)? >>=20 >> -- >> Francis Galiegue,=20 >> fgaliegue@gmail.com >>=20 >> JSON Schema in Java:=20 >> http://json-schema-validator.herokuapp.com >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From eric@tibco.com Mon Mar 11 11:48:19 2013 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 3B5FD21F8EA0; Mon, 11 Mar 2013 11:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxSuWSPfTSlz; Mon, 11 Mar 2013 11:48:18 -0700 (PDT) Received: from mx2-app.tibco.com (mx2-app.tibco.com [63.100.100.143]) by ietfa.amsl.com (Postfix) with ESMTP id B19C221F8EAB; Mon, 11 Mar 2013 11:48:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,825,1355126400"; d="scan'208";a="57648801" Received: from tibco-5.tibco.com (HELO PA-CASHUB01.na.tibco.com) ([63.100.100.5]) by mx2-app.tibco.com with ESMTP; 11 Mar 2013 11:48:18 -0700 Received: from Eric-Johnsons-MacBook-Pro.local (10.105.164.24) by PA-CASHUB01.na.tibco.com (10.106.137.46) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 11 Mar 2013 11:48:17 -0700 Message-ID: <513E26F5.9080207@tibco.com> Date: Mon, 11 Mar 2013 11:48:21 -0700 From: Eric Johnson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Graham Klyne References: <512663B2.20809@tibco.com> <51278B10.10200@ninebynine.org> <513CAD82.409@ninebynine.org> In-Reply-To: <513CAD82.409@ninebynine.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.105.164.24] X-Mailman-Approved-At: Tue, 12 Mar 2013 08:15:43 -0700 Cc: uri-review@ietf.org, "apps-discuss@ietf.org" , Fredrik Ullner Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub 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, 11 Mar 2013 18:48:19 -0000 On 3/10/13 8:57 AM, Graham Klyne wrote: > > Also, an observation. There's a lot of normative language in this > template, some of which is really about the protocol, which is not > common to see in URI scheme registrations (for example, under scheme > semantics and interoperability considerations). While it's not > formally incorrect, I'd be inclined to put some of this discussion in > the protocol spec, or other specification document, and refer to it > from the registration template. The usual role of a URI registration > template is to provide an overview and key information about a URI > scheme, supported by references to separate documentation. Your > approach makes this an unusually long and complicated URI registration > form. Realizing that a number of these items you probably added to respond to my comment, I think Graham makes a critical point. My question was about defining how one maps the URI to the protocol, not about repeating the definition of the protocol. For example, this line: " The client SHOULD request a TCP connection to the specified user via the commands $CTM (ConnectToMe) or $RCM (ReverseConnectToMe) (or an equivalent command)." ... I would write differently. The normative statements in this document ought to be about the URI and its use, rather than being normative statements about the protocol. There are lots of ways to use URIs that have nothing to do with the actual protocol (path computations, display on web pages, entries in a caching table). So the above statement, if it appears anywhere, should be in the protocol document. For the URI document, you could write something like this instead: "With this form of URI, the client wishing to retrieve a file ought to request a TCP connection to the specified user via the commands $CTM (ConnectToMe) or $RCM (ReverseConnectToMe)." I appreciate that you added the text, because it clarifies the use. It is just the normative part that triggers concern, because URIs have many uses.... One other thought. For a permanent registration, I interpret the need for a permanent URL to the document implying more permanence than the URL for this draft shows. For example, rather than updating the document in place, each new revision should have a new URL. Eric. From fgaliegue@gmail.com Tue Mar 12 08:44:18 2013 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 1597721F8CBB for ; Tue, 12 Mar 2013 08:44:18 -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 WAlyl80i4RMR for ; Tue, 12 Mar 2013 08:44:17 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3411821F8ABA for ; Tue, 12 Mar 2013 08:44:17 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id q15so1845717ead.41 for ; Tue, 12 Mar 2013 08:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1PYcZkjX0/RmpqJQ7JtkyeksR3f5Ql8ymU29nhH1XHU=; b=PvSNqZVU1kBOzfeGhi8LUMU0iFUCUiOS8YtZKI27mCCk5T+vsv7qSpoqGi8WhPgOgy Fjc2Sm/uaE5ATDW+J/Giv4HSM//aLaUx2zXnZvDV/tKndroeFD3alZjfJgjlSC/zDaQi y7f0k81R2DLh153moeQXqkWa2HMtPJ9dAcd1NKQ4e4YvIsxPh8DlRMALRi6PQZXynbZB wPLjof9GO7YLKis+1GBfkfPjomD25j+N+rmIlh8mwii4qViuQqRMAsBAz9X8hSydd+RJ Cc0oo6GsbktHvcM5Y/UucTsCjVo4EipHNFMCXhQ5NG5gH9vfL8ODlZS9f05zvLyVZBWq 3Fjw== MIME-Version: 1.0 X-Received: by 10.14.175.129 with SMTP id z1mr5958645eel.7.1363103056139; Tue, 12 Mar 2013 08:44:16 -0700 (PDT) Received: by 10.14.1.7 with HTTP; Tue, 12 Mar 2013 08:44:16 -0700 (PDT) In-Reply-To: <4388A03B-B9A8-43A1-9A90-1D16C1C3F789@mnot.net> References: <1362765524.22220.11.camel@pbryan-wsl.internal.salesforce.com> <1362768334.22220.17.camel@pbryan-wsl.internal.salesforce.com> <4388A03B-B9A8-43A1-9A90-1D16C1C3F789@mnot.net> Date: Tue, 12 Mar 2013 16:44:16 +0100 Message-ID: From: Francis Galiegue To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] JSON Patch question about the remove operation 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, 12 Mar 2013 15:44:18 -0000 On Tue, Mar 12, 2013 at 3:56 PM, Mark Nottingham wrote: > Test cases are still more than welcome: > https://github.com/json-patch/json-patch-tests > Interesting! I have written a set of test cases for my own implementation (in Java), I'll try and adapt these -- and why not send more tests from the ones I have written. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From ajs@anvilwalrusden.com Tue Mar 12 11:41:11 2013 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 AF97021F87BB for ; Tue, 12 Mar 2013 11:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 AWgkAbgYKOhH for ; Tue, 12 Mar 2013 11:41:11 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 279F521F86AE for ; Tue, 12 Mar 2013 11:41:07 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B2BBB8A031 for ; Tue, 12 Mar 2013 18:41:06 +0000 (UTC) Date: Tue, 12 Mar 2013 14:40:51 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130312184051.GE39324@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 18:41:11 -0000 On Tue, Mar 12, 2013 at 08:37:12AM -0400, Murray S. Kucherawy wrote: > colleagues properly there), so maybe the answer to this question should > also come from outside the DNS. Is that something that deserves serious > consideration, or is it off the mark? I actually originally thought that would be way better. The problem I ran into is that anyone who is running a domain name already has, by definition, a DNS server. An overwhelming number of them don't have a WEIRDS service, and probably don't want to run one. That's what makes me reluctant to go in that direction. A -- Andrew Sullivan ajs@anvilwalrusden.com From hallam@gmail.com Tue Mar 12 12:51:25 2013 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 3E30411E80F2 for ; Tue, 12 Mar 2013 12:51:25 -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 Lq7nJfLyB-qp for ; Tue, 12 Mar 2013 12:51:24 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2094911E8118 for ; Tue, 12 Mar 2013 12:51:23 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t57so239514wey.41 for ; Tue, 12 Mar 2013 12:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E0VF1MDKtuvbzUAmL98Ogi79ciSHeItWvJyFR6I31Xo=; b=JuJ8dZrJnBBgABsL8TwcuCq1ChmuqmvnUg6pEbCtXto6mc8IwTYYKZrISwtv6QWyQg ibsD5lv7nNzuMZeJa0y8Q4BvLY0BFE7hSY5py5QIYDT3MAr5hhC2m0AIT/C8ZpX5AIrY W41pKhDXnjUOsevX60klVVUWq9UfY4CIfTC7Y5R7olRAW+dPSRrsgX4cOtSL61hFe9nt pl47cEaCkixN8+HEXnN3aP6bn2ILqW0gOjo5oBZqHVys1Wpd9dyq9n3HD9wfAB38KWh+ SMu1vP9S1QaQjvblzDXMqK9D8T5oAmJVjaj98uZVB+Jaa+eWOsqUuzR1iOhyNAPILcG1 kd/Q== MIME-Version: 1.0 X-Received: by 10.194.93.97 with SMTP id ct1mr29359461wjb.48.1363117883290; Tue, 12 Mar 2013 12:51:23 -0700 (PDT) Received: by 10.194.11.71 with HTTP; Tue, 12 Mar 2013 12:51:23 -0700 (PDT) In-Reply-To: <20130312184051.GE39324@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> Date: Tue, 12 Mar 2013 15:51:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 19:51:25 -0000 I was not there for John's comments but from what I gather of them second hand I completely disagree. It does not matter what the DNS was designed to do twenty years ago. That is a debate for historians. What the DNS was intended to be has never been the same as what people used it for or found value in. The fact that people use the DNS in ways that were not anticipated by the designers is not a bug, not something to be corrected. How the users of the Internet use the DNS is all that matters now. Telling people that they don't want to do what they are trying to do is silly and insulting. There is an implicit administrative hierarchy in DNS. There is a real world distinction between DNS delegations that are private and those that are public. The applications layer of the Internet has built on those assumptions for the past twenty years What would be a mistake is to propose the use of any infrastructure that is not DNS to publish authoritative statements about DNS names. That would be a violation of the Internet architecture. Please, no more talk about WEIRDS or whatever other protocol someone might see a chance to find a use case for. I do not need the full capabilities expressed in Andrew's draft. In fact I only need two statements, both of which could be specified in a new DNS RR or if we don't want to add new RRs we could even use the existing CAA record and express them as properties. The properties I need to be able to express in a domain are: PUBLIC - This domain is a public delegation point PRIVATE - This domain is not a public delegation point EXCLUDED - This domain is excluded from the enclosing private space. So taking the example of ai.mit.edu we would have: edu PUBLIC mit.edu PRIVATE ai.mit.edu EXCLUDED edu is a public delegation point. Anyone with a school can get a domain. mit.edu has domains registered below it but it is not a public delegation point. You have to be affiliated to MIT to get a domain. There is an accountability infrastructure in place. ai.mit.edu was a sub domain but one that always had a separate network administration which might mean that it was appropriate for it to be declared as being separate from the rest of the *.mit.edu space so that cross site issues were avoided in both directions. Note that all the above information are simple statements of fact that the administrators of the domain might make. Interpretation of those statements is a completely different matter. The mere fact that a domain has an assertion in the DNS at issue time does not mean that I am automatically going to rely on it when issuing certificates. We crawl the web constantly. If the information being published now is inconsistent with the information published consistently for the past 4 years, that may require a closer look. I would expect that the information proposed would be used to inform the compilation of 'public prefix lists' but those are going to remain a curated resource. Publication in DNS is not ideal but a lot better than an open access wiki (see error 81). We have in the next 12 months an opportunity to tell ICANN that we would like the winners of the new TLDs to publish records declaring the public delegation points. This has essentially zero cost to ICANN but allows the maintenance of public prefix lists to scale in the wake of the TLD expansion. All that is necessary to make that happen is to provide a clear and simple specification for those TLD operators to deploy. If we miss that window it will be a lot harder. When I started this note I was thinking that re-use of CAA was a bit of a hack. But considering the fact that the division between public and private was one of the main design issues we ended up having problems with, it actually looks like a pretty clean fit to me right now. From superuser@gmail.com Tue Mar 12 12:52:23 2013 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 938DB11E818C for ; Tue, 12 Mar 2013 12:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, 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 oDSV4rvJBHsA for ; Tue, 12 Mar 2013 12:52:22 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id A81E111E817F for ; Tue, 12 Mar 2013 12:52:21 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id t44so241382wey.40 for ; Tue, 12 Mar 2013 12:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1nH5PEyeaMEz6aMwewcewpiFeTI5iZ1UZDPa4VRIay4=; b=ca1ir5ZNAGHW+Th0NKkUNdw25w8Jc6T+KUgBjUNTeKyGJIrASvf/JiRKzgVmgzl4a9 emNje1Z7un43wGugx0F7B98VfJeGACRToVo/0DjN9H1Q1p2g6jgMLCg2yZso2lHh8RDb mVVKrNA4na8QVRuEhFSpwD4B88CfdSa1Aym7P/v+mgxHfmbfqyl7OqdzslwcNxnKZTpZ zH/+ydaFTSQes6DAfaabx4vM4xkLcc2/ma4x6VKydgOMFKUa4N9j5GhTq9CxyKpiJiWB 96B93ltSB7WkzcVZmboZgAZatj3x+KWl8/ZzGbc9mPLvxvqg6RG79Gx1a7GLOiyMGv25 r/2A== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr22179386wic.33.1363117940777; Tue, 12 Mar 2013 12:52:20 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 12:52:20 -0700 (PDT) In-Reply-To: <20130312184051.GE39324@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> Date: Tue, 12 Mar 2013 15:52:20 -0400 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c22574a5aa2604d7bfa056 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 19:52:23 -0000 --001a11c22574a5aa2604d7bfa056 Content-Type: text/plain; charset=ISO-8859-1 I mean a WEIRDS client, not a server. WEIRDS clients include anything that can do an HTTP query. If for example I decide I need to evaluate foo.bar.example.com, I would issue a WEIRDS query for that string, and presumably get back example.comas that's the registered domain. (This is a particular point for the WEIRDS community to confirm.) This introduces a rather dire need for caching, but that's another matter. On Tue, Mar 12, 2013 at 2:40 PM, Andrew Sullivan wrote: > On Tue, Mar 12, 2013 at 08:37:12AM -0400, Murray S. Kucherawy wrote: > > colleagues properly there), so maybe the answer to this question should > > also come from outside the DNS. Is that something that deserves serious > > consideration, or is it off the mark? > > I actually originally thought that would be way better. The problem I > ran into is that anyone who is running a domain name already has, by > definition, a DNS server. An overwhelming number of them don't have a > WEIRDS service, and probably don't want to run one. That's what makes > me reluctant to go in that direction. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c22574a5aa2604d7bfa056 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I mean a WEIRDS client, not a server.=A0 WEIRDS clien= ts include anything that can do an HTTP query.

If for example = I decide I need to evaluate foo.bar.= example.com, I would issue a WEIRDS query for that string, and presumab= ly get back example.com as that's th= e registered domain.=A0 (This is a particular point for the WEIRDS communit= y to confirm.)

This introduces a rather dire need for caching, but that's another = matter.


On Tue, Mar 12, 2013 at 2:40 PM, Andrew Sullivan <= ajs@anvilwalrus= den.com> wrote:
On Tue, Mar 12, 2013 at 08= :37:12AM -0400, Murray S. Kucherawy wrote:
> colleagues properly there), so maybe the answer to this question shoul= d
> also come from outside the DNS. =A0Is that something that deserves ser= ious
> consideration, or is it off the mark?

I actually originally thought that would be way better. =A0The proble= m I
ran into is that anyone who is running a domain name already has, by
definition, a DNS server. =A0An overwhelming number of them don't have = a
WEIRDS service, and probably don't want to run one. =A0That's what = makes
me reluctant to go in that direction.

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001a11c22574a5aa2604d7bfa056-- From fgaliegue@gmail.com Tue Mar 12 13:03:43 2013 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 C2FCA11E8136 for ; Tue, 12 Mar 2013 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 wOp5MS6Jlyq2 for ; Tue, 12 Mar 2013 13:03:38 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1B08A11E80E2 for ; Tue, 12 Mar 2013 13:03:34 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id b15so115168eek.11 for ; Tue, 12 Mar 2013 13:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=YfkazRpCgznSXG1+07vBrHpL/w6a/JQ64Zrj1xerokY=; b=j9N2ys6wY0vj0/ATJ6fxTs5OJVN/Dobpxrq19vYFuD+ClCcCXHQBzMg/41ffXB+/wu 6MDoL24dpQ0GrdGBNFf8D1dRoAgGJaNKW13TfIZ1TuVv+To15U3fs6QXEZmPiGrQpxte 6ZFXJDGHEZm7O727wCsgctmqUPQmAQKyUusa9BrIqaS/1FG3zdFwAjkJGeN4YSHbevxQ M8hItiRkBl+8FTdEIUqzrHsHTR53zkg0wx65EmVAtlmnOODn3FifSnPi4aPetxFzuoDW kaGDlvTBxhLhcsf6T2yBrH0Hg3QwgQ6Ftf+5TD4lR9/rebMZLB9101+Rdo74iV8pQ5Au rUEg== MIME-Version: 1.0 X-Received: by 10.14.110.68 with SMTP id t44mr1309181eeg.25.1363118610765; Tue, 12 Mar 2013 13:03:30 -0700 (PDT) Received: by 10.14.1.7 with HTTP; Tue, 12 Mar 2013 13:03:30 -0700 (PDT) Date: Tue, 12 Mar 2013 21:03:30 +0100 Message-ID: From: Francis Galiegue To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Should this patch succeed? 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, 12 Mar 2013 20:03:44 -0000 On Tue, Mar 12, 2013 at 4:44 PM, Francis Galiegue wrote: > On Tue, Mar 12, 2013 at 3:56 PM, Mark Nottingham wrote: >> Test cases are still more than welcome: >> https://github.com/json-patch/json-patch-tests >> One test reads something akin to this: [ { "op": "add", "path": "/0", "value": 1 } ] With input [], it is expected to give output [ 1 ]. However the spec says: [... ]The specified index MUST NOT be greater than the number of elements in the array. If the "-" character is used to index the end of the array (see [JSON-Pointer]), this has the effect of appending the value to the array. Strictly speaking, here the 0 in "/0" is not strictly greater than the number of elements but it is an element which does not exist. And it would seem that "/-" is the recommended approach here. So, should this patch succeed? Was it the real intent of the text, or was is meant to be "the specified index MUST refer to an existing index in the array. If the character is" etc etc? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From pbryan@anode.ca Tue Mar 12 13:05:57 2013 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 1C7A811E8149 for ; Tue, 12 Mar 2013 13:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3C4QWItZv-H for ; Tue, 12 Mar 2013 13:05:55 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3BC11E8122 for ; Tue, 12 Mar 2013 13:05:53 -0700 (PDT) Received: from [10.126.22.27] (nat-204-14-239-210-sfo.net.salesforce.com [204.14.239.210]) by maple.anode.ca (Postfix) with ESMTPSA id 98D7DEA021; Tue, 12 Mar 2013 20:05:51 +0000 (UTC) From: "Paul C. Bryan" To: Francis Galiegue In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-z3r2P9nDduOhInYvm0Zq" Date: Tue, 12 Mar 2013 13:05:46 -0700 Message-ID: <1363118746.358.3.camel@pbryan-wsl.internal.salesforce.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: Mark Nottingham , apps-discuss@ietf.org Subject: Re: [apps-discuss] Should this patch succeed? 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, 12 Mar 2013 20:05:57 -0000 --=-z3r2P9nDduOhInYvm0Zq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Yes, it should succeed. Before .../- came along, the way to add to end of the array was to specify an index equal to the number of elements in the array. This is why it was phrased as such. Paul On Tue, 2013-03-12 at 21:03 +0100, Francis Galiegue wrote: > On Tue, Mar 12, 2013 at 4:44 PM, Francis Galiegue wrote: > > On Tue, Mar 12, 2013 at 3:56 PM, Mark Nottingham wrote: > >> Test cases are still more than welcome: > >> https://github.com/json-patch/json-patch-tests > >> > > One test reads something akin to this: > > [ { "op": "add", "path": "/0", "value": 1 } ] > > With input [], it is expected to give output [ 1 ]. > > However the spec says: > > [... ]The specified index MUST NOT be greater than the > number of elements in the array. If the "-" character is used to > index the end of the array (see [JSON-Pointer]), this has the > effect of appending the value to the array. > > Strictly speaking, here the 0 in "/0" is not strictly greater than the > number of elements but it is an element which does not exist. And it > would seem that "/-" is the recommended approach here. > > So, should this patch succeed? Was it the real intent of the text, or > was is meant to be "the specified index MUST refer to an existing > index in the array. If the character is" etc etc? > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema in Java: http://json-schema-validator.herokuapp.com --=-z3r2P9nDduOhInYvm0Zq Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Yes, it should succeed.

Before .../- came along, the way to add to end of the array was to specify an index equal to the number of elements in the array. This is why it was phrased as such.

Paul

On Tue, 2013-03-12 at 21:03 +0100, Francis Galiegue wrote: 
On Tue, Mar 12, 2013 at 4:44 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
> On Tue, Mar 12, 2013 at 3:56 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> Test cases are still more than welcome:
>>   https://github.com/json-patch/json-patch-tests
>>

One test reads something akin to this:

[ { "op": "add", "path": "/0", "value": 1 } ]

With input [], it is expected to give output [ 1 ].

However the spec says:

      [... ]The specified index MUST NOT be greater than the
      number of elements in the array.  If the "-" character is used to
      index the end of the array (see [JSON-Pointer]), this has the
      effect of appending the value to the array.

Strictly speaking, here the 0 in "/0" is not strictly greater than the
number of elements but it is an element which does not exist. And it
would seem that "/-" is the recommended approach here.

So, should this patch succeed? Was it the real intent of the text, or
was is meant to be "the specified index MUST refer to an existing
index in the array. If the character is" etc etc?

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

--=-z3r2P9nDduOhInYvm0Zq-- From johnl@iecc.com Tue Mar 12 13:07:31 2013 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 CA5B421F8712 for ; Tue, 12 Mar 2013 13:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.768 X-Spam-Level: X-Spam-Status: No, score=-110.768 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 so-HqGTMp-Hd for ; Tue, 12 Mar 2013 13:07:30 -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 9FEEF21F867B for ; Tue, 12 Mar 2013 13:07:29 -0700 (PDT) Received: (qmail 73239 invoked from network); 12 Mar 2013 20:07:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Mar 2013 20:07:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=513f8b00.xn--9vv.k1303; i=johnl@user.iecc.com; bh=Pti298PlETvdtWqS6CLVIDznVNSSzafbD3LHKUch32E=; b=uimj3A8XNs2p4/vCfpvgjc58j+AoZGz1I6s64t56NPYmcP1D/j22LLf3BpKxawIQCzGmac7UJXlgr45ooDvscpmLRtlYLKdmH77gIo/GGZnOCqRqUYxCISFQVbOvz94SfBjWxwSDB5hTNhiAo7pR0Eq60iTOhXMUlId8l9olkqA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=513f8b00.xn--9vv.k1303; olt=johnl@user.iecc.com; bh=Pti298PlETvdtWqS6CLVIDznVNSSzafbD3LHKUch32E=; b=CbC9ZfdckMCxlOR1oXzxdAxcl3sue/06+oy2WhTWLTGEMwzRs2JlRC6ZeSCC6/XFn8kf1g5b8uhPt7eUAAbXRcuCVYFRXK8yG8X1SZ95PEyC158qZgBwwrupugljAN2gvjBM2DCBktSPNdUy15nclikc1Yo7gHN4N6ZnanzxyU4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Mar 2013 20:07:06 -0000 Message-ID: <20130312200706.18010.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 20:07:31 -0000 > b) certain large entities would be able to exert considerable market power to >demand that organizations create these kinds of linkages in the DNS to enable >cookie sharing for extremely common scenarios like tracking and analytics, >advertising or single-sign on Now that you mention it, ewwww. This would basically allow ad networks to assert that third party cookies are first party cookies. From ajs@anvilwalrusden.com Tue Mar 12 13:19:38 2013 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 8DD7E11E80F3 for ; Tue, 12 Mar 2013 13:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.518 X-Spam-Level: X-Spam-Status: No, score=-0.518 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_38=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 asi5qPieB3fx for ; Tue, 12 Mar 2013 13:19:37 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B967B11E80E3 for ; Tue, 12 Mar 2013 13:19:37 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 354788A031 for ; Tue, 12 Mar 2013 20:19:37 +0000 (UTC) Date: Tue, 12 Mar 2013 16:19:15 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130312201915.GD41728@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 20:19:38 -0000 Brad, Thanks for your comments. Some more questions inline below. On Tue, Mar 12, 2013 at 02:23:18PM +0000, Hill, Brad wrote: > 2) I prefer the names-only version. I think the protocol / port issue is an unnecessary complication. Everyone seems to think that, and I'm relieved, so if there's another draft I'll remove that. > 3) I think if this is going to live in the DNS, it should respect > the structure of, and say things about, the DNS, rather than > describing a distinct and arbitrary overlay topology of > administrative trust relationships. Just to be careful here, no matter _what_ we do, we are describing an arbitrary overlay topology of administrative trust relationships. That is necessarily true, because the relationships that currently exist in the DNS are DNS-topological only. People are _used_ to the idea that names are related to one another in particular ways, and as a cultural fact that is mostly true; but in the not very distant past, it wasn't, and there's reason to suppose it might not obtain in the near future. > i) highly dynamic data that downstream consumers of a cached data set (web browsers) are not prepared to handle > ii) a very large amount of data that downstream consumers of a cached data set are not prepared to handle This issue had, I have to confess, never even occurred to me. You're quite right, however, that the design of the mechanism tends to encourage a default position of "don't trust, no need to look up," but the design of the cross-tree declaration will tend to encourage a large number of queries that are not broadly applicable and that will therefore not be very good cache candidates. For practical purposes, therefore, I'd be tempted to say that, in any SOPA record, the owner name must be related to the name in the RDATA as either an ancestor or a descendent (with the root label still being the special case of "not here"; of course, every name is related to the root label). > 4) I am also concerned with mixing the state of siblings as to > whether they share an administrative relationship with the parent or > not. Whether the depth in the DNS hierarchy is a "real" thing or > not, it has been treated as such and been a part of the web security > model for almost 20 years. The "walk towards the root until you > find a boundary, and all siblings are equal" procedures apply not > just for setting cookies, but to core JavaScript and therefore the > Same Origin Policy through a feature known as "domain lowering". I take very seriously the argument that there is an existing and widely-deployed model. I note, however, that the widely-deployed model is about to be thrown out anyway, regardless of how we feel about it. For a significant number of the new TLDs are so-called ".brand" TLDs, and I'm pretty sure that the operators of .megacorp are going to want to be able to set shared cookies in www.megacorp and product1.megacorp and so on. It seems to me, however, that we might need a way to make this sort of behaviour the default. The wildcard trick was intended to make that easy, but I'm not perfectly sure it will. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Mar 12 13:24:50 2013 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 9111E11E818C for ; Tue, 12 Mar 2013 13:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_75=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 rVXCX6rjx5qQ for ; Tue, 12 Mar 2013 13:24:49 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E899E11E8187 for ; Tue, 12 Mar 2013 13:24:48 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4F3148A031 for ; Tue, 12 Mar 2013 20:24:48 +0000 (UTC) Date: Tue, 12 Mar 2013 16:24:42 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130312202442.GE41728@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 20:24:50 -0000 On Tue, Mar 12, 2013 at 03:52:20PM -0400, Murray S. Kucherawy wrote: > If for example I decide I need to evaluate foo.bar.example.com, I would > issue a WEIRDS query for that string, and presumably get back > example.comas that's the registered domain. (This is a particular > point for the > WEIRDS community to confirm.) Why would the correct answer not be from foo.bar.example.com or bar.example.com (or, actually, both)? A large amount of the assumed background is the deployed convention of label.example.com. The "registered domain" here is example.com. And while that is the most common case, it doesnt cover everything. Indeed, if that convention _were_ reliable, we wouldn't need the public suffix list at all. Moreover, if my parent can assert things about me, then unless I run a WEIRDS server I wouldn't have a way of disagreeing with that parent. A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Tue Mar 12 13:30:46 2013 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 B985421F8C85 for ; Tue, 12 Mar 2013 13:30: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 Hfn0y-KJsnnp for ; Tue, 12 Mar 2013 13:30:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D506821F8B98 for ; Tue, 12 Mar 2013 13:30:45 -0700 (PDT) Received: from [130.129.84.195] (unknown [130.129.84.195]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D8ACF40725; Tue, 12 Mar 2013 14:39:18 -0600 (MDT) Message-ID: <513F9076.4000707@stpeter.im> Date: Tue, 12 Mar 2013 16:30:46 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andrew Sullivan References: <20130310042250.GE33497@mx1.yitter.info> In-Reply-To: <20130310042250.GE33497@mx1.yitter.info> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 20:30:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/9/13 11:22 PM, Andrew Sullivan wrote: > 1. Do people think this is work that needs to be done? Yes. The public suffix list must die. > 2. Do either of the above proposals seem like a good starting > point? I'll need time to read your draft in more detail before forming an opinion. What is the other proposal? > 3. If so, who is willing to do work on this (by reviewing and so > on). I am willing to review and provide feedback. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRP5B1AAoJEOoGpJErxa2pF6AQAIZH4EZKdJlFKycGp8t30iIm Y5dku+S/k6zCTV2FNz26gI6/vlE+N2UL+4zaqaekGsR4EtOsjUox7+PkAbEo/RXP pWrAYaCYNrVktANMWgxE1ngVCyW6RQ4FKmc4dm1CaEoltHJvUwgbtUtOh3uvrde0 /sm4ojAc+l29CAmmlajY3uwZZwyUBWlb6KRz5PckorzwOk75EJTV0OATy2AT1PGi uK+nXrqKLvoyxMQ09FrLfeWmMPBHn0E9nXIg0toVG0aY1jxLbT/1qAUnqKMhIOuX i9Eqz4VFH6iOZm+tlJo5seFBnwcvE3tMGgkPqeRnUdr8XDEvZDKxzzPwNK/9wTjX r5QPFUTw79SGsNZMLHTt6KIFaHVX7wnOalzScIv/BMK0YB0Dvpokkdnu6zfkhw+T +vYrfemNn5qeQT6DRq7GCVbVQ10G9fNMnVlW623kjd6y6FWfbvBJ/5v4rB+AyepZ 3T6Xm/5HUmRX/5hs+jkQfhFcOSXCnJyTBfYFhfAY29TwQLLDt7IoLFJ+oj2vHhdj 5LmfFKvDppPH5pCBxKUFtqQJNR0TuN9jgVWccyF5Z424CFJYKIYmvR5btbWs/evh mB1Z0p7OpGts5UhrPDbGM1fOKThZivPNVtJPsZdNbMveJj4n3JVOP/582UURVS5w ft1ukmmdbgbaczZVyI09 =vRUR -----END PGP SIGNATURE----- From superuser@gmail.com Tue Mar 12 13:37:12 2013 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 00C0E1F0C74 for ; Tue, 12 Mar 2013 13:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, 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 00CWT1uWAb6P for ; Tue, 12 Mar 2013 13:37:11 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4331F0C36 for ; Tue, 12 Mar 2013 13:37:10 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so2216019wib.0 for ; Tue, 12 Mar 2013 13:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Vp6T4KAYso2aGonBVNJ6+o6V60AkVVzMlSs+G1bzn3M=; b=DZ8XK1uZdAGW9vQAis8OzaUH7xRUWJNPL+uFrV2qDpbH9f+W7OB0/IBiVvH4GgJxsp 9lGL1Ii2KKstl7LU3TXDAnRcFW30xe+S2TJinjzoufV4zBpvPBilu0GQcKu6IUUnBIbd 0kJ7KRXqyNAdJ0yQbUIWg4GgAatH/NV5C40n9DdGSkYYrNxRAHYVm/Wl7G1dXeIr8DYF EQuSd9VtgRConQ81tqnysKZQrkW1R+08VCmIZAXWaaCFqYNmoYGoNRoU4V4WoCql/8Cx Xr1eVCoaf36mF+1xaKM2QkErr8S8Jw+yTx4NpqY0wnPtOY/7UAcxYJdN+sUTZut3H+Am 99oA== MIME-Version: 1.0 X-Received: by 10.180.189.169 with SMTP id gj9mr8805901wic.5.1363120630254; Tue, 12 Mar 2013 13:37:10 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 13:37:10 -0700 (PDT) In-Reply-To: <20130312202442.GE41728@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> Date: Tue, 12 Mar 2013 16:37:10 -0400 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c34a62f3d2dd04d7c040ec Cc: IETF Apps Discuss Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 20:37:12 -0000 --001a11c34a62f3d2dd04d7c040ec Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 12, 2013 at 4:24 PM, Andrew Sullivan wrote: > On Tue, Mar 12, 2013 at 03:52:20PM -0400, Murray S. Kucherawy wrote: > > If for example I decide I need to evaluate foo.bar.example.com, I would > > issue a WEIRDS query for that string, and presumably get back > > example.comas that's the registered domain. (This is a particular > > point for the > > WEIRDS community to confirm.) > > Why would the correct answer not be from foo.bar.example.com or > bar.example.com (or, actually, both)? > I am probably making some assumptions here, about which I should be careful given the weird hat that's around here somewhere. It's based on a property of WHOIS that exists now, at least with numbers: if I ask for 1.2.3.4, then I will get back the registration for the tightest containing subnet registration, and possibly all of them upwards. If a WEIRDS server did the same with names (or could if asked), then example.com would be the returned result for foo.bar.example.com. > > Moreover, if my parent can assert things about me, then unless I run a > WEIRDS server I wouldn't have a way of disagreeing with that parent. > > The particular use case I'm working on here applies an algorithm like: a) ask about the domain name I have b) if I don't get an answer, figure out the registered domain (currently using public suffix) and ask there So you (at (a) in that list) can override what the parent says if you need to. -MSK --001a11c34a62f3d2dd04d7c040ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 12, 2013 at 4:24 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
On Tue, Mar 12, 2013 at 03= :52:20PM -0400, Murray S. Kucherawy wrote:
> If for example I decide I need to evaluate foo.bar.example.com, I would
> issue a WEIRDS query for that string, and presumably get back
> example.comas that's the registered domain. =A0(This is a pa= rticular
> point for the
> WEIRDS community to confirm.)

Why would the correct answer not be from foo.bar.example.com or
bar.example.com (o= r, actually, both)?

I am probably makin= g some assumptions here, about which I should be careful given the weird ha= t that's around here somewhere.=A0 It's based on a property of WHOI= S that exists now, at least with numbers: if I ask for 1.2.3.4, then I will= get back the registration for the tightest containing subnet registration,= and possibly all of them upwards.=A0 If a WEIRDS server did the same with = names (or could if asked), then example.com<= /a> would be the returned result for foo.bar.example.com.
=A0

Moreover, if my parent can assert things about me, then unless I run a
WEIRDS server I wouldn't have a way of disagreeing with that parent.

<= br>
The particular use case I'm working on here applies an al= gorithm like:

a) ask about the domain name I have
b) if I don'= ;t get an answer, figure out the registered domain (currently using public = suffix) and ask there

So you (at (a) in that list) can override what the parent sa= ys if you need to.

-MSK
--001a11c34a62f3d2dd04d7c040ec-- From ajs@anvilwalrusden.com Tue Mar 12 13:47:39 2013 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 0CDDB21F8CD6 for ; Tue, 12 Mar 2013 13:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 ELwoRgyKURtx for ; Tue, 12 Mar 2013 13:47:38 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8768421F8CC9 for ; Tue, 12 Mar 2013 13:47:38 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C94DF8A031 for ; Tue, 12 Mar 2013 20:47:22 +0000 (UTC) Date: Tue, 12 Mar 2013 16:46:53 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130312204653.GH41728@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <513F9076.4000707@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <513F9076.4000707@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 20:47:39 -0000 On Tue, Mar 12, 2013 at 04:30:46PM -0400, Peter Saint-Andre wrote: > > 2. Do either of the above proposals seem like a good starting > > point? > > I'll need time to read your draft in more detail before forming an > opinion. What is the other proposal? The other proposal is an undrafted one, but it's basically what Phill posted to the list earlier today: a way of indicating that you do delegate or do not delegate to other organizations, and another way of asserting that no matter what others say, they so are not inside your policy authority boundary. I suppose it requires writing up. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Mar 12 13:50:18 2013 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 4806E11E80E3 for ; Tue, 12 Mar 2013 13:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 BFKHdXyjSO1l for ; Tue, 12 Mar 2013 13:50:17 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id CF89011E80D2 for ; Tue, 12 Mar 2013 13:50:17 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D63EA8A031 for ; Tue, 12 Mar 2013 20:50:16 +0000 (UTC) Date: Tue, 12 Mar 2013 16:50:07 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130312205006.GI41728@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 20:50:18 -0000 On Tue, Mar 12, 2013 at 04:37:10PM -0400, Murray S. Kucherawy wrote: > I am probably making some assumptions here, about which I should be careful > given the weird hat that's around here somewhere. It's based on a property > of WHOIS that exists now, at least with numbers: if I ask for 1.2.3.4, then > I will get back the registration for the tightest containing subnet > registration, and possibly all of them upwards. If a WEIRDS server did the > same with names (or could if asked), then example.com would be the returned > result for foo.bar.example.com. But why should you believe what example.com says about foo.bar.example.com? If we could believe that, we wouldn't need a new mechanism. A -- Andrew Sullivan ajs@anvilwalrusden.com From jtrentadams@gmail.com Tue Mar 12 14:06:44 2013 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 01FDF11E810A for ; Tue, 12 Mar 2013 14:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 87-95vPY0d4V for ; Tue, 12 Mar 2013 14:06:43 -0700 (PDT) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3D42611E810E for ; Tue, 12 Mar 2013 14:06:43 -0700 (PDT) Received: by mail-ia0-f180.google.com with SMTP id f27so296461iae.11 for ; Tue, 12 Mar 2013 14:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=eUkc6sMyMlLTQ/FGeYZoSNn1Qt79G2dPsdKsxeu/AOE=; b=iEqutGHXHskZAuVtmcYF5wK4+QcSUB8VGxeiXfahop7wdauZQKbz0kTrQWCN8lWNwF pH1O/vQEUTohDeDbKLOdZdxnRDKvMLNiSmDL9rF2mB/X3TdGYnonWMmyduurb7MErAGM 9k7Pg4T5I8nL+r0FUTmSHvudSZG80jgI7iCvhRpQH6mBRgSjHpRa+8fNSwsvSM2BhVAc CgCefV6NHVP+5y6n73EJZ1CqnJZUdJ0pA00JpmFsVZ5EhJGVtrq9SCREJtf3AD9xza6a hwhM9I4VzGM/sixgu4mTQJRBrw5sEBWuGw8NfVeK4w+7fXEhhSh+OQMgpnaRL4uIyVtb OYsg== X-Received: by 10.50.169.6 with SMTP id aa6mr15562509igc.1.1363122402733; Tue, 12 Mar 2013 14:06:42 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPS id l2sm21699939igb.1.2013.03.12.14.06.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 14:06:42 -0700 (PDT) Message-ID: <513F98E0.6000804@gmail.com> Date: Tue, 12 Mar 2013 15:06:40 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Sullivan References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> In-Reply-To: <20130312205006.GI41728@mx1.yitter.info> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 21:06:44 -0000 Andrew - On 3/12/13 2:50 PM, Andrew Sullivan wrote: > On Tue, Mar 12, 2013 at 04:37:10PM -0400, Murray S. Kucherawy wrote: > >> I am probably making some assumptions here, about which I should be careful >> given the weird hat that's around here somewhere. It's based on a property >> of WHOIS that exists now, at least with numbers: if I ask for 1.2.3.4, then >> I will get back the registration for the tightest containing subnet >> registration, and possibly all of them upwards. If a WEIRDS server did the >> same with names (or could if asked), then example.com would be the returned >> result for foo.bar.example.com. > But why should you believe what example.com says about > foo.bar.example.com? If we could believe that, we wouldn't need a new > mechanism. There are times in practice when it's useful to make certain assumptions like "if there is no response to a given query at a FQDN, hop all the way to the registered domain to see what it says." That's not to say that this model fits all use cases, just that sometimes it's helpful (and your proposal seems to support it by pointing me in the right direction). So, for example, I'd publish a SOPA record at "way.down.the.tree.org" pointing to "tree.org". Then if what I'm looking for doesn't exist at "way.down.the.tree.org", I would know that the answer is at "tree.org". This may actually be a bastardization of what you're ultimately trying to accomplish, but does seem to serve my goals with the added benefit of weening myself off of the public suffix list. - Trent > > A > -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From superuser@gmail.com Tue Mar 12 15:58:30 2013 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 472E011E80F0 for ; Tue, 12 Mar 2013 15:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 A0ONehtx9LRE for ; Tue, 12 Mar 2013 15:58:29 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3BE11E80E8 for ; Tue, 12 Mar 2013 15:58:29 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id p43so388528wea.38 for ; Tue, 12 Mar 2013 15:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZQBiIY+Y9EBVzjbB5iBrtH0aiFSoQIdE6TxItpdwu8o=; b=LekjQ2uDZeW/P1CWEDBPJPPfNX+s/j/AfOH46d7txnc8J3hPTbPgbgDAHegiZQdNRn pofcosxezWLOFAgplvi4/mG2gCFJA13yGgobzwgcmSiJyngnIzR8sMVJF0qIAqr5/Vgi jE9H/oFqGyf1Z1W7MxWPc6PnCOToTWNBq+YwrwADFsDvvVNxvn/erDjPiPobbo4BAs+s x2R/aao1V++CvSz/aeWxcerutb/JIWaf6dhVO1TJ9KihK8pXOKWwlRzda+25l7b4iRcd RHr5P/TIqRAmj3MSaMYIcgz///sp86L7R2mlru4RpKeGVoO863r3nU+2ZeyntTVLFdrG HTfA== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr22873391wic.33.1363129108291; Tue, 12 Mar 2013 15:58:28 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Tue, 12 Mar 2013 15:58:28 -0700 (PDT) In-Reply-To: <20130312205006.GI41728@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <7B65185F-2517-4800-AE6A-CBA88F8B5720@vpnc.org> <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> Date: Tue, 12 Mar 2013 18:58:28 -0400 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c2257448693504d7c23a55 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] "finding registered domains" 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, 12 Mar 2013 22:58:30 -0000 --001a11c2257448693504d7c23a55 Content-Type: text/plain; charset=ISO-8859-1 In my use case, it's defined that an example.com policy is used (if it exists) in the absence of a foo.bar.example.com policy. The problem is I don't know how far up the tree to make that second query. So in my case I explicitly will believe the parent/grandparent/whatever statement, but I don't know how far up to go, and I don't want to ask everyone; I only want to ask at most two questions. On Tue, Mar 12, 2013 at 4:50 PM, Andrew Sullivan wrote: > On Tue, Mar 12, 2013 at 04:37:10PM -0400, Murray S. Kucherawy wrote: > > > I am probably making some assumptions here, about which I should be > careful > > given the weird hat that's around here somewhere. It's based on a > property > > of WHOIS that exists now, at least with numbers: if I ask for 1.2.3.4, > then > > I will get back the registration for the tightest containing subnet > > registration, and possibly all of them upwards. If a WEIRDS server did > the > > same with names (or could if asked), then example.com would be the > returned > > result for foo.bar.example.com. > > But why should you believe what example.com says about > foo.bar.example.com? If we could believe that, we wouldn't need a new > mechanism. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c2257448693504d7c23a55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In my use case, it's defined that an example.com policy is used (if it exists) in the absence = of a foo.bar.example.com policy.= =A0 The problem is I don't know how far up the tree to make that second= query.

So in my case I explicitly will believe the parent/grandparent/whatever= statement, but I don't know how far up to go, and I don't want to = ask everyone; I only want to ask at most two questions.


On Tue, Mar 12, 2013 at 4:50 PM, Andrew = Sullivan <ajs@anvilwalrusden.com> wrote:
On Tue, Mar 12, 2013 at 04:37:10PM -0400, Murray S. Kuche= rawy wrote:

> I am probably making some assumptions here, about which I should be ca= reful
> given the weird hat that's around here somewhere. =A0It's base= d on a property
> of WHOIS that exists now, at least with numbers: if I ask for 1.2.3.4,= then
> I will get back the registration for the tightest containing subnet > registration, and possibly all of them upwards. =A0If a WEIRDS server = did the
> same with names (or could if asked), then example.com would be the returned
> result for fo= o.bar.example.com.

But why should you believe what example.com says about
foo.bar.example.co= m? =A0If we could believe that, we wouldn't need a new
mechanism.

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001a11c2257448693504d7c23a55-- From ajs@anvilwalrusden.com Tue Mar 12 20:18:28 2013 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 4AA1811E80E3 for ; Tue, 12 Mar 2013 20:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 g22Q2+tztrJF for ; Tue, 12 Mar 2013 20:18:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B383511E80E1 for ; Tue, 12 Mar 2013 20:18:26 -0700 (PDT) Received: from mx1.yitter.info (dhcp-46aa.meeting.ietf.org [130.129.70.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 02CDE8A031 for ; Wed, 13 Mar 2013 03:18:25 +0000 (UTC) Date: Tue, 12 Mar 2013 23:17:56 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130313031756.GC41909@mx1.yitter.info> References: <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> <513F98E0.6000804@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <513F98E0.6000804@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 03:18:28 -0000 On Tue, Mar 12, 2013 at 03:06:40PM -0600, J. Trent Adams wrote: > There are times in practice when it's useful to make certain assumptions > like "if there is no response to a given query at a FQDN, hop all the > way to the registered domain to see what it says." Right. Just to be clear, if there were _no_ response here (i.e. a NODATA response), then that has the same semantics as the "root target" response: nobody else is in my policy authority realm. But, > So, for example, I'd publish a SOPA record at "way.down.the.tree.org" > pointing to "tree.org". Then if what I'm looking for doesn't exist at > "way.down.the.tree.org", I would know that the answer is at "tree.org". yes, this is exactly right. > This may actually be a bastardization of what you're ultimately trying > to accomplish, but does seem to serve my goals with the added benefit of > weening myself off of the public suffix list. No, it's not a bastardization at all: it's _exactly_ what I'm trying to accomplish. (And now you can see why I thought that example.com to example.net was just a free extra feature, though I see now with your help why it is problematic.) A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Mar 12 20:27:26 2013 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 3853311E80F9 for ; Tue, 12 Mar 2013 20:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 gPSdWqn9WBwz for ; Tue, 12 Mar 2013 20:27:25 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AB88111E80D1 for ; Tue, 12 Mar 2013 20:27:25 -0700 (PDT) Received: from mx1.yitter.info (dhcp-46aa.meeting.ietf.org [130.129.70.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3F8208A031 for ; Wed, 13 Mar 2013 03:27:25 +0000 (UTC) Date: Tue, 12 Mar 2013 23:26:55 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130313032655.GD41909@mx1.yitter.info> References: <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 03:27:26 -0000 On Tue, Mar 12, 2013 at 06:58:28PM -0400, Murray S. Kucherawy wrote: > In my use case, it's defined that an example.com policy is used (if it > exists) in the absence of a foo.bar.example.com policy. The problem is I > don't know how far up the tree to make that second query. In order for that to be defined, you put a SOPA record at foo.bar.example.com that says "example.com". If you have no SOPA record, the policy for foo.bar.example.com is "nobody else shares this". This is a "default closed" policy, which I think has to be the right one. There's something slightly awkward about this for the CA case, however, when you have deep trees and you want a wildcard cert that descends the tree from example.com. I'm still not sure what to do about that, because it's going to be impossible to enumerate all the names under a wildcard (and anyway, you can't do multi-label wildcards). I remain a little unhappy about this, but it strikes me that anyone doing wildcard certs for deep trees may be in a world of hurt anyway, and it would be better to add an additional SOPA record for (for instance) *.oneIactuallyWant.example.com. > So in my case I explicitly will believe the parent/grandparent/whatever > statement, but I don't know how far up to go, and I don't want to ask > everyone; I only want to ask at most two questions. As long as you have the pointer up the tree, that should work. A -- Andrew Sullivan ajs@anvilwalrusden.com From MHammer@ag.com Tue Mar 12 21:41:04 2013 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 2407011E8164 for ; Tue, 12 Mar 2013 21:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzbaF11NmRq2 for ; Tue, 12 Mar 2013 21:41:02 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 53C8E11E80E1 for ; Tue, 12 Mar 2013 21:41:02 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 00:41:01 -0400 From: "MH Michael Hammer (5304)" To: Andrew Sullivan , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] "finding registered domains" Thread-Index: AQHOHpZMP5BTWxKTGUm1LqSfeE4juZihPyuAgAEDWQCAAGWbgIAAE/kAgAAJCwCAAAN7AIAAA5+AgAAj3ACAAEsBgP//z0DA Date: Wed, 13 Mar 2013 04:41:00 +0000 Message-ID: References: <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> <20130313032655.GD41909@mx1.yitter.info> In-Reply-To: <20130313032655.GD41909@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.201] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 04:41:04 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Andrew Sullivan > Sent: Tuesday, March 12, 2013 11:27 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] "finding registered domains" >=20 > On Tue, Mar 12, 2013 at 06:58:28PM -0400, Murray S. Kucherawy wrote: > > In my use case, it's defined that an example.com policy is used (if it > > exists) in the absence of a foo.bar.example.com policy. The problem > > is I don't know how far up the tree to make that second query. >=20 > In order for that to be defined, you put a SOPA record at > foo.bar.example.com that says "example.com". If you have no SOPA record, > the policy for foo.bar.example.com is "nobody else shares this". This is= a > "default closed" policy, which I think has to be the right one. >=20 I'm trying to wrap my head around this for the use case for domain trees su= ch as example.co.uk. We know (or should know) that the (or at least one imp= ortant) cut is always going to be at .co.uk. I think this is one of the use= cases that has been problematic. Do we really want to rely on each subdoma= in up the tree publishing a SOPA record for this type of case? What do we d= o when some subdomains publish and others do not? Is the intent to force do= main administrators to go along by them ending up with suboptimal outcomes = if they don't? I'm not asking these things to be snarky - I'm really not clear on the thin= king here. In the email authentication space we've always gone to some leng= ths to avoid imposing new standards (SPF, DKIM, DMARC) on folks that don't = really care to participate. I'm also concerned because my experience is tha= t so many admins/domain owners get even the simplest DNS records wrong in i= mplementation. > There's something slightly awkward about this for the CA case, however, > when you have deep trees and you want a wildcard cert that descends the > tree from example.com. I'm still not sure what to do about that, because= it's > going to be impossible to enumerate all the names under a wildcard (and > anyway, you can't do multi-label wildcards). I remain a little unhappy a= bout > this, but it strikes me that anyone doing wildcard certs for deep trees m= ay be > in a world of hurt anyway, and it would be better to add an additional SO= PA > record for (for instance) *.oneIactuallyWant.example.com. >=20 > > So in my case I explicitly will believe the > > parent/grandparent/whatever statement, but I don't know how far up to > > go, and I don't want to ask everyone; I only want to ask at most two > questions. >=20 > As long as you have the pointer up the tree, that should work. >=20 > A >=20 > -- Mike From yaojk@cnnic.cn Wed Mar 13 04:41:11 2013 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 DB11921F8CCE for ; Wed, 13 Mar 2013 04:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.995 X-Spam-Level: X-Spam-Status: No, score=-97.995 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.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 QSbZizGRNajS for ; Wed, 13 Mar 2013 04:41:11 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id B572021F8CBB for ; Wed, 13 Mar 2013 04:41:09 -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; Wed, 13 Mar 2013 19:41:03 +0800 Message-ID: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> From: "Jiankang YAO" To: "Andrew Sullivan" , References: <20130310042250.GE33497@mx1.yitter.info> Date: Wed, 13 Mar 2013 19:41:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 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] "finding registered domains" 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, 13 Mar 2013 11:41:12 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BhbnZpbHdhbHJ1c2Rlbi5jb20+DQpUbzogPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4NClNl bnQ6IFN1bmRheSwgTWFyY2ggMTAsIDIwMTMgMTI6MjIgUE0NClN1YmplY3Q6IFthcHBzLWRpc2N1 c3NdICJmaW5kaW5nIHJlZ2lzdGVyZWQgZG9tYWlucyINCg0KDQo+DQouLi4NCj4gSSB3b24ndCBo YXZlIGFueSBzbGlkZXMgb24gTW9uZGF5OyBJIHJlYWxseSBqdXN0IHdhbnQgdG8gbGVhcm4gdGhl DQo+IGZvbGxvd2luZzoNCj4gDQo+ICAgIDEuICBEbyBwZW9wbGUgdGhpbmsgdGhpcyBpcyB3b3Jr IHRoYXQgbmVlZHMgdG8gYmUgZG9uZT8NCj4gDQoNCg0KSSBhbSBzdGlsbCBub3QgdmVyeSBjbGVh ciBhYm91dCB3aGF0IHRoZSBwcm9ibGVtIGlzIGFuZCB3aGF0IHRoZSBwb3NzaWxiZSBzb2x1dGlv biBpcy4NCg0KIENvdWxkIHlvdSBraW5kbHkgc3VtbWFyaXplIGl0IGluIG9uZSBvciB0d28gc2Vu dGVuY2VzID8NCg0KDQpKaWFua2FuZyBZYW8NCg== From hallam@gmail.com Wed Mar 13 07:07:48 2013 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 1332521F8DA4 for ; Wed, 13 Mar 2013 07:07:48 -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 gg6icqvnmftI for ; Wed, 13 Mar 2013 07:07:47 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1945C21F8D8E for ; Wed, 13 Mar 2013 07:07:46 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hi8so2799997wib.13 for ; Wed, 13 Mar 2013 07:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=09omPMmlSem5+9CPR0GeVNgG6xgsul8hL9UYWlaOV7s=; b=LqzodU02+v/DTJNKRWD7hCX3IaDIK3pbRYun6TQgQP7WOVqe4x6rbqi3EgYsfSfQhE MJ840DnBq3SRDXMv2dy019P9KhKNxGOAdxgnUjoASF93e1jxeewKXRuSJY51FsysY2/u 2uLgI3vyLlTkM0O8Zt4ArV5LdJluL0c5aILUyRixeAE+9XgyLwKkOUf3EDUl4YIXLhix 7y4r4UfIUtYUycS92B7f5qM3W1VNHiCPWvFBU5e7iD+mOccAodEflBYVSMxjsr5DhGc3 nWcPApPbNd2uMxqUsa6S0HJsAL8ioAed8mQtfhq042T22QvfwbYF7qwT4M442EI254mX e8pA== MIME-Version: 1.0 X-Received: by 10.180.97.132 with SMTP id ea4mr27135691wib.23.1363183666193; Wed, 13 Mar 2013 07:07:46 -0700 (PDT) Received: by 10.194.11.71 with HTTP; Wed, 13 Mar 2013 07:07:45 -0700 (PDT) In-Reply-To: References: <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> <20130313032655.GD41909@mx1.yitter.info> Date: Wed, 13 Mar 2013 10:07:45 -0400 Message-ID: From: Phillip Hallam-Baker To: "MH Michael Hammer (5304)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 14:07:48 -0000 On Wed, Mar 13, 2013 at 12:41 AM, MH Michael Hammer (5304) wrote: > I'm not asking these things to be snarky - I'm really not clear on the th= inking here. In the email authentication space we've always gone to some le= ngths to avoid imposing new standards (SPF, DKIM, DMARC) on folks that don'= t really care to participate. I'm also concerned because my experience is t= hat so many admins/domain owners get even the simplest DNS records wrong in= implementation. That is why I am concentrating on getting the new TLDs issued by ICANN to publish records that say 'this is a public delegation point' that would be used as input to prefix lists. That has a plausible deployment model. The way I would word this problem is that any protocol that depends on more than 5% of parties to deploy before it provides value is doomed and to be successful it probably needs to provide value at a much lower deployment. >> There's something slightly awkward about this for the CA case, however, >> when you have deep trees and you want a wildcard cert that descends the >> tree from example.com. I'm still not sure what to do about that, becaus= e it's >> going to be impossible to enumerate all the names under a wildcard (and >> anyway, you can't do multi-label wildcards). I remain a little unhappy = about >> this, but it strikes me that anyone doing wildcard certs for deep trees = may be >> in a world of hurt anyway, and it would be better to add an additional S= OPA >> record for (for instance) *.oneIactuallyWant.example.com. Wildcards are only one reason that CAs use the public prefix list. Obviously a wildcard certificate for *.co.uk would be undesirable. Mere presence of a DNS record is not going to cause a CA to automatically change their policy on *.co.uk wildcards. But publication of a record might well cause an exception to be signaled for human administrator review. --=20 Website: http://hallambaker.com/ From johnl@iecc.com Wed Mar 13 07:43:45 2013 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 2F98621F8D77 for ; Wed, 13 Mar 2013 07:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.849 X-Spam-Level: X-Spam-Status: No, score=-110.849 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 djfZDBctUOxl for ; Wed, 13 Mar 2013 07:43:44 -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 4D73921F8D2B for ; Wed, 13 Mar 2013 07:43:44 -0700 (PDT) Received: (qmail 48218 invoked from network); 13 Mar 2013 14:43:44 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Mar 2013 14:43:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140909f.xn--yuvv84g.k1303; i=johnl@user.iecc.com; bh=mccdBDPAd1TRQjhkLNtdiNH4EznJsOwNJnpzwdCHlWg=; b=LmSNSF2L9jL8eBrTNJTvHUZujUGgrW8Do8QXvntHlGwXLFWj7y7v7HhSrbZuMrBvQN3pg17TalpLV99N/lu9zRVffRipZyRjnsAqE58WxlcbZkQKxAKWarZr24PAuacyfc9mJ5o8ajR3zVMYh36+RUo1y1SgdHnOc9ZvbdgPRGs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5140909f.xn--yuvv84g.k1303; olt=johnl@user.iecc.com; bh=mccdBDPAd1TRQjhkLNtdiNH4EznJsOwNJnpzwdCHlWg=; b=JjrMaSsXvRMRKbyh6LPeu6Sh3S8Z91FuckyinJJl+bBdlWDsVzqR4pZ95witydsyiQ75NUyNc8i30eYyNixUyVvep8R57lZtcdHdks/SgWh+xR1qJxXvNLzhTmzdqrFuYnlowuaOJXzt+SaBAiGZ8ILnu5MEjiMn+jTH97x3guc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Mar 2013 14:43:21 -0000 Message-ID: <20130313144321.37307.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 14:43:45 -0000 >I am still not very clear about what the problem is and what the possilbe solution is. > > Could you kindly summarize it in one or two sentences ? I agree that use cases would help a lot. The ones I'm aware of are: * Web cookies: limit how high up the DNS tree a site can promote its cookies. * DMARC and other mail authentication: find policy documents for a domain given one of its subdomains * SSL/TLS certificates: prevent certificate issue for names at or above public delegation points * Variants: state that two parallel names are under the same management (has issues different from the previous three) R's, John From hallam@gmail.com Wed Mar 13 10:20:46 2013 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 8674A21F8C82 for ; Wed, 13 Mar 2013 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 X88nVTbnKOKU for ; Wed, 13 Mar 2013 10:20:44 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE3B21F8507 for ; Wed, 13 Mar 2013 10:20:44 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id fg15so1172560wgb.1 for ; Wed, 13 Mar 2013 10:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dZuhjHJS8+lQC00mCe+IUZiQixjKmnZbpKl3al7TJLM=; b=w6sJ1UmNjBfC0fnNn8aiiP3AjLXj6HxUc3b/mrqGy2HpJbeZAMLHxPgbhoor5QbLHF OtKYe7jTYWL8bhisjK+S3jBrfpruacLX5QxhLUq+huqA/6aPbEQ3rDX+jaH0yc5QnrPo 4w4S4qYZ8ZPHxVPAc9a8J9prg8EibqMj47gx8sF0v4YLqEn626PtQeFsQbVsHdb0I2j9 oIZhNAmPpK0e/iM7ykHLdfTzWa+2SKnPhLkdU5SwVVQbG2TgmD/60J33FXXCgps/4kcg 5I7P8LZPhd8kQCKQm1v8Fxdg2l9pjWgAQr6/7cwcGbNh/4aN3kd+DOEOmWFXdgFXQ4ey 4wyg== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr28337143wiv.26.1363195243177; Wed, 13 Mar 2013 10:20:43 -0700 (PDT) Received: by 10.194.11.71 with HTTP; Wed, 13 Mar 2013 10:20:42 -0700 (PDT) In-Reply-To: <20130313144321.37307.qmail@joyce.lan> References: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> <20130313144321.37307.qmail@joyce.lan> Date: Wed, 13 Mar 2013 13:20:42 -0400 Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 17:20:46 -0000 On Wed, Mar 13, 2013 at 10:43 AM, John Levine wrote: >>I am still not very clear about what the problem is and what the possilbe solution is. >> >> Could you kindly summarize it in one or two sentences ? > > I agree that use cases would help a lot. The ones I'm aware of are: +1 The presentation of the information in DNS terms is trivial. The whole problem is knowing what information to present and why. > * Web cookies: limit how high up the DNS tree a site can promote its cookies. Also prevent cookie sharing across subtrees, especially to reduce cross site contamination issues when some parts of a tree are outsourced. HTTP is not the only protocol with cookies. There are application level cookies as well. Rule 81 applies here and probably provides grounds for a corollary. So if I outsource management of my shopping cart to a payment processor and my Web site to a cheap hosting service I probably don't want cookies set on one to be visible on the other. My view is that anything more complex than defining a domain subtree as a distinct administrative region from all others is going to be too complex to implement securely. > * DMARC and other mail authentication: find policy documents for a > domain given one of its subdomains > > * SSL/TLS certificates: prevent certificate issue for names at or above public > delegation points Actually VeriSign would be perfectly entitled to obtain an SSL certificate off a public root for .com What would be *BAD* would be *.com The use made of the public suffix list is rather more however. If someone is applying for a.b.c.d.e.f.g.h.i.example.com it probably does not have an email server on it. It might even be an appliance that does not have SMTP capability. Sending an email to check ownership of the domain is not going to work. The email would have to go to admin@example.com. Regardless of what the DNS mythology claims, the DNS administrator of example.com has complete control over the subtree beneath it. That is how the DNS is designed. If the owner of a.b.c.d.e.f.g.h.i.example.com wants independence from example.com they have only one route and that is to buy a domain of their own. So while there are other applications where you might want to treat different parts of the subtree as independent administrative domains (ai.mit.edu might not want to share cookies with lcs.mit.edu) that is not the case for CAs. > * Variants: state that two parallel names are under the same management (has > issues different from the previous three) That would be an interesting and useful problem but I really don't want to commit to going down that rathole. That looks to me like something that might suggest that we need to think about an extensible approach. > R's, > John > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Website: http://hallambaker.com/ From ajs@anvilwalrusden.com Wed Mar 13 10:51:05 2013 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 F32E021F8DB9 for ; Wed, 13 Mar 2013 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 TFh+wSwPUbU8 for ; Wed, 13 Mar 2013 10:51:04 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 770AC21F8DEC for ; Wed, 13 Mar 2013 10:51:04 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9F0038A031 for ; Wed, 13 Mar 2013 17:50:57 +0000 (UTC) Date: Wed, 13 Mar 2013 13:50:46 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130313175046.GB45769@mx1.yitter.info> References: <20130311210857.GG38441@mx1.yitter.info> <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> <20130313032655.GD41909@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 17:51:05 -0000 On Wed, Mar 13, 2013 at 04:41:00AM +0000, MH Michael Hammer (5304) wrote: > > > > this is one of the use cases that has been problematic. Do we really > want to rely on each subdomain up the tree publishing a SOPA record > for this type of case? No, of course not. Nominet puts a SOPA record with the root target at co.uk. That means, "This name does not share its administrative realm with any other name," which is correct. Nobody else needs to publish anything for that to take effect. It's only when you want to make positive association between two different names that you need to have records at both sides. > and others do not? Is the intent to force domain administrators to > go along by them ending up with suboptimal outcomes if they don't? No, the intent is to pick the safest possible state ("no shared administrative realm") as the default, and to require positive action if you want an association with other names. I think Brad's point about siblings is that the approach I'm arguing for breaks a current expectation many people have -- that all the siblings are "safe". But that was always a dangerous arrangement, and I think it is becoming more dangerous over time. > I'm not asking these things to be snarky I didn't take it that way. I think the proposal I'm making needs plenty of examination and prodding. I appreciate the comments and questions. Thanks. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Wed Mar 13 10:56:24 2013 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 DA3FC21F8D98 for ; Wed, 13 Mar 2013 10:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 KMJ0Denr6Pke for ; Wed, 13 Mar 2013 10:56:24 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 18CF121F8C5C for ; Wed, 13 Mar 2013 10:56:24 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 0AEC58A031 for ; Wed, 13 Mar 2013 17:56:23 +0000 (UTC) Date: Wed, 13 Mar 2013 13:55:53 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130313175552.GC45769@mx1.yitter.info> References: <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> <20130313032655.GD41909@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 17:56:25 -0000 On Wed, Mar 13, 2013 at 10:07:45AM -0400, Phillip Hallam-Baker wrote: > > The way I would word this problem is that any protocol that depends on > more than 5% of parties to deploy before it provides value is doomed > and to be successful it probably needs to provide value at a much > lower deployment. I think the proposal I offer needs no more work by anyone tht your proposal, and its deployment costs are exactly the same. The only difference between them is that the proposal I've made covers more cases because it doesn't depend on the dodgy "public delegation point" notion. That's not the problem you have. For instance, my employer (Dyn) operates a service in dyndns.org that accepts host names from customers and puts them in a zone. There is no delegation. Yet almost every name in the dyndns.org zone is in a different administrative realm. If SOPA existed, we could signal this by putting a SOPA record with the root target at dyndns.org. None of our customers would need to do anything. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsalgado@nic.cl Wed Mar 13 10:57:01 2013 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 F03E221F8E11 for ; Wed, 13 Mar 2013 10:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIacyRPDO5to for ; Wed, 13 Mar 2013 10:57:00 -0700 (PDT) Received: from mail.nic.cl (mail.nic.cl [IPv6:2001:1398:1::6008]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5321F8C5C for ; Wed, 13 Mar 2013 10:57:00 -0700 (PDT) Received: from mail.nic.cl (localhost.localdomain [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 6F0ACCC829E for ; Wed, 13 Mar 2013 14:56:59 -0300 (CLST) Received: from vulcano.intra.nic.cl (unknown [IPv6:2001:1398:4:1:172:30:10:58]) by mail.nic.cl (Postfix) with ESMTP id 5775FCC829B for ; Wed, 13 Mar 2013 14:56:59 -0300 (CLST) Message-ID: <5140BDEB.8080203@nic.cl> Date: Wed, 13 Mar 2013 14:56:59 -0300 From: Hugo Salgado User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130313144321.37307.qmail@joyce.lan> In-Reply-To: <20130313144321.37307.qmail@joyce.lan> X-Enigmail-Version: 1.5.1 OpenPGP: id=B525FA6E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on Wed Mar 13 14:56:59 2013 -0300 (CLST) Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 17:57:01 -0000 On 03/13/2013 11:43 AM, John Levine wrote: >> I am still not very clear about what the problem is and what the possilbe solution is. >> >> Could you kindly summarize it in one or two sentences ? > > I agree that use cases would help a lot. The ones I'm aware of are: > > * Web cookies: limit how high up the DNS tree a site can promote its cookies. > > * DMARC and other mail authentication: find policy documents for a > domain given one of its subdomains > > * SSL/TLS certificates: prevent certificate issue for names at or above public > delegation points > > * Variants: state that two parallel names are under the same management (has > issues different from the previous three) Also from Firefox browser: * domain highlighting in the URL bar * restricting the setting of the document.domain property (DOM same-origin policy) Hugo From zwnj.org@gmail.com Wed Mar 13 11:30:15 2013 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 2707021F8EF5 for ; Wed, 13 Mar 2013 11:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 PwtnttbwB5r9 for ; Wed, 13 Mar 2013 11:30:14 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5497521F8E71 for ; Wed, 13 Mar 2013 11:29:52 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id dr13so1292136wgb.14 for ; Wed, 13 Mar 2013 11:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=B3Hnm8aGhTrmPneZZrJH+FnRFP6gt0hzLdiXmakjy+o=; b=iu8n1DcffjtMULXw0PXcGdGW665mk1qWgyrR8RwWsRc6jkvXEelYwiCdoHD1y6EkiK o1NcRK1WQsK66UpC4yV5b+JcaSyAAAoHCl0dYTa/bFuRteT7w7vabtZKhf6oDNBLpCiz iYawtbfTL8fKUg5Eq+B5OnkZ66Gbzos5mWrzljt2V+79oX2YO5gWx/iOIJ2PazSxA7uf lIFuSf2Sp3/FTh9pAx4jvtRpQsvIWze/lT9m+5AfxOcuK8r5WxtBoMzppgMh5i38t3Ei XWMUHCIC4TNp5R7WsnmejAsPyk8cXcgzp6EsstYUsSV8+V3bDmRu/POGmjTcfFUys4im zO0w== MIME-Version: 1.0 X-Received: by 10.180.81.164 with SMTP id b4mr29072976wiy.34.1363199390413; Wed, 13 Mar 2013 11:29:50 -0700 (PDT) Sender: behnam@gmail.com X-Google-Sender-Delegation: behnam@gmail.com Received: by 10.194.26.4 with HTTP; Wed, 13 Mar 2013 11:29:50 -0700 (PDT) In-Reply-To: <20130313175552.GC45769@mx1.yitter.info> References: <20130312184051.GE39324@mx1.yitter.info> <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> <20130313032655.GD41909@mx1.yitter.info> <20130313175552.GC45769@mx1.yitter.info> Date: Wed, 13 Mar 2013 14:29:50 -0400 X-Google-Sender-Auth: YKPOp4sHaeu2EgLBLCreJW7pSKk Message-ID: From: Behnam Esfahbod To: Andrew Sullivan Content-Type: multipart/alternative; boundary=14dae9cc9fbe6c788904d7d297aa Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 18:30:15 -0000 --14dae9cc9fbe6c788904d7d297aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andrew, Reading the draft, I couldn't find any definition/description of what an "administrative realm" or "authority" is. You are trying to address all the issues listed here (cookies, DN highlighting, etc) but it is not obvious to me why these all could/should be treated the same way. For example, company Example may wants to prevent cookie sharing between its domain (example.com) and their outsourced shopping subdomain ( shop.example.com), but likes to keep the address-bar domain-name highlighting to "example.com", because of marketing reasons. So, are you suggesting that there should be one administrative/authority aspect for domain name hierarchy and the applications SHOULD adopt to this assumption and behave similarly in different aspects of domain name hierarchy (again, cookies, DN highlighting, etc)? Thanks, -Behnam On Wed, Mar 13, 2013 at 1:55 PM, Andrew Sullivan wr= ote: > On Wed, Mar 13, 2013 at 10:07:45AM -0400, Phillip Hallam-Baker wrote: > > > > The way I would word this problem is that any protocol that depends on > > more than 5% of parties to deploy before it provides value is doomed > > and to be successful it probably needs to provide value at a much > > lower deployment. > > I think the proposal I offer needs no more work by anyone tht your > proposal, and its deployment costs are exactly the same. The only > difference between them is that the proposal I've made covers more > cases because it doesn't depend on the dodgy "public delegation point" > notion. That's not the problem you have. For instance, my employer > (Dyn) operates a service in dyndns.org that accepts host names from > customers and puts them in a zone. There is no delegation. Yet > almost every name in the dyndns.org zone is in a different > administrative realm. If SOPA existed, we could signal this by > putting a SOPA record with the root target at dyndns.org. None of our > customers would need to do anything. > > Best, > > A > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Behnam Esfahbod | =D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8=A7=D8=B3=D9=81=D9=87= =D8=A8=D8=AF http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B --14dae9cc9fbe6c788904d7d297aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andrew,

Reading the draft, I coul= dn't find any definition/description of what an "administrative re= alm" or "authority" is. You are trying to address all the is= sues listed here (cookies, DN=C2=A0highlighting, etc) but it is not obvious= to me why these all could/should be treated the same way.

For example, company Example may wants to p= revent cookie sharing between its domain (ex= ample.com) and their outsourced shopping subdomain (shop.example.com), but likes to keep the address-bar d= omain-name highlighting to "example.com= ", because of marketing reasons.

So, are you suggesting that there should be= one administrative/authority aspect for domain name hierarchy and the appl= ications SHOULD adopt to this assumption and behave similarly in different = aspects of domain name hierarchy (again, cookies, DN highlighting, etc)?

Thanks,
-Behnam




On Wed, Mar 13, 2013 at 1:55 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Mar 13, 2013 at 10:07:45AM -0400, Ph= illip Hallam-Baker wrote:
>
> The way I would word this problem is that any protocol that depends on=
> more than 5% of parties to deploy before it provides value is doomed > and to be successful it probably needs to provide value at a much
> lower deployment.

I think the proposal I offer needs no more work by anyone tht your
proposal, and its deployment costs are exactly the same. =C2=A0The only
difference between them is that the proposal I've made covers more
cases because it doesn't depend on the dodgy "public delegation po= int"
notion. =C2=A0That's not the problem you have. =C2=A0For instance, my e= mployer
(Dyn) operates a service in dyndns.org that accepts host names from
customers and puts them in a zone. =C2=A0There is no delegation. =C2=A0Yet<= br> almost every name in the dy= ndns.org zone is in a different
administrative realm. =C2=A0If SOPA existed, we could signal this by
putting a SOPA record with the root target at dyndns.org. =C2=A0None of our
customers would need to do anything.

Best,

A
--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________________= __________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
=
Behnam Esfahbod |=C2=A0=D8=A8=D9=87=D9=86=D8=A7=D9=85 =D8= =A7=D8=B3=D9=81=D9=87=D8=A8=D8=AF
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9= 7520 5701 CA40 259E 0F8B

--14dae9cc9fbe6c788904d7d297aa-- From bhill@paypal-inc.com Wed Mar 13 11:56:49 2013 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 E281121F8C1A for ; Wed, 13 Mar 2013 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=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 Kpn+sb9VKn4T for ; Wed, 13 Mar 2013 11:56:49 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id DD85621F8D94 for ; Wed, 13 Mar 2013 11:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1363201009; x=1394737009; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DXe23IoZyzXr3M7X8510QaNPnTTTisBJMAx3k3p8idY=; b=j0/2gI22Cc+qCMJ/VdBB8fsQriZIoNNudazwMgY62ChgQsR6XdbK7A6Q ayrZlsz095TVfjArq3L16xjmuCrpSSehjxOpbgVUYpHwcmxMis5k1jWMC gmGiqcVgjNbwP0WwHTr5n+BR/y2cTGQ8eVc5lxzlwYf/zWSrGIL1CYrmD 0=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.84,838,1355126400"; d="scan'208";a="14050777" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 13 Mar 2013 11:56:48 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 12:56:48 -0600 From: "Hill, Brad" To: Andrew Sullivan , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] "finding registered domains" Thread-Index: AQHOHUb/R4SnLKDS10yVBt4lLf5fTZiiFg1QgADRtYCAARPCgA== Date: Wed, 13 Mar 2013 18:56:47 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27961C9F@DEN-EXDDA-S12.corp.ebay.com> References: <20130310042250.GE33497@mx1.yitter.info> <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com> <20130312201915.GD41728@mx1.yitter.info> In-Reply-To: <20130312201915.GD41728@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 18:56:50 -0000 ... > > 3) I think if this is going to live in the DNS, it should respect > > the structure of, and say things about, the DNS, rather than > > describing a distinct and arbitrary overlay topology of > > administrative trust relationships. >=20 > Just to be careful here, no matter _what_ we do, we are describing an arb= itrary > overlay topology of administrative trust relationships. > That is necessarily true, because the relationships that currently exist = in the > DNS are DNS-topological only. People are _used_ to the idea that names a= re > related to one another in particular ways, and as a cultural fact that is= mostly > true; but in the not very distant past, it wasn't, and there's reason to = suppose it > might not obtain in the near future. [Hill, Brad] Well, I meant to respect the basic structure as a tree that (m= ostly) directly encodes only ancestor / descendant relationships, rather th= an arbitrary cross-linkages across different branches. (CNAME notwithstand= ing) As a matter of how the DNS works, and how it will continue to work for= things like DNSSEC, the DNS admin of a given label has control of descenda= nt labels. The hierarchy of control is more than just implied. ... > > 4) I am also concerned with mixing the state of siblings as to whether > > they share an administrative relationship with the parent or not. > > Whether the depth in the DNS hierarchy is a "real" thing or not, it > > has been treated as such and been a part of the web security model for > > almost 20 years. The "walk towards the root until you find a > > boundary, and all siblings are equal" procedures apply not just for > > setting cookies, but to core JavaScript and therefore the Same Origin > > Policy through a feature known as "domain lowering". >=20 > I take very seriously the argument that there is an existing and widely-d= eployed > model. I note, however, that the widely-deployed model is about to be th= rown > out anyway, regardless of how we feel about it. For a significant number= of the > new TLDs are so-called ".brand" TLDs, and I'm pretty sure that the operat= ors of > .megacorp are going to want to be able to set shared cookies in > www.megacorp and product1.megacorp and so on. >=20 > It seems to me, however, that we might need a way to make this sort of > behaviour the default. The wildcard trick was intended to make that easy= , but > I'm not perfectly sure it will. >=20 Allowing cookies or document.domain to be lowered to a gTLD controlled by a= single entity is not quite "throwing out" the current model, it is just ch= anging the depth of the hard stop - the algorithm and basic model otherwise= remains totally intact. In contrast, changes differentiate domain lowerin= g properties among siblings at the same depth are a much more substantial c= hange to how the Web security model works and increases the complexity of t= he algorithms and implementations, the mental model for users, and the comp= lexity and size of the data needed to support that model.=20 -Brad From bhill@paypal-inc.com Wed Mar 13 12:47:01 2013 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 D2F4A21F8DDB for ; Wed, 13 Mar 2013 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 oEsPElKm-98P for ; Wed, 13 Mar 2013 12:47:00 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id AD64721F8DC9 for ; Wed, 13 Mar 2013 12:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1363204021; x=1394740021; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=crqStUryEYT9zTSaJh35wGPJGK1c86yUcSHEUa9iOiw=; b=PU9lew0uvkLmtC/K+Fy3DzEl4HKVmwqjYhla5j2VSJ37AmfMEqPKMvOF /tBS4w6UMC/KJJEM/40yfstuk74bBTPIJC1yfOVc7dUm1EGNd41RDgjKR lAYO1XXXSkSREgPaSPUJVB88Dvlr6HDA9mUVm0t+YP4+zX0hL6ei6r6kx c=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.84,838,1355126400"; d="scan'208";a="14053320" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 13 Mar 2013 12:47:00 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 13:46:44 -0600 From: "Hill, Brad" To: Hugo Salgado , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] "finding registered domains" Thread-Index: AQHOHUb/R4SnLKDS10yVBt4lLf5fTZijhMuEgACXc4CAADYagP//uhPQ Date: Wed, 13 Mar 2013 19:46:43 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E27961E10@DEN-EXDDA-S12.corp.ebay.com> References: <20130313144321.37307.qmail@joyce.lan> <5140BDEB.8080203@nic.cl> In-Reply-To: <5140BDEB.8080203@nic.cl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [apps-discuss] "finding registered domains" 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, 13 Mar 2013 19:47:02 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > On Behalf Of Hugo Salgado > Sent: Wednesday, March 13, 2013 1:57 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] "finding registered domains" >=20 >=20 > On 03/13/2013 11:43 AM, John Levine wrote: > >> I am still not very clear about what the problem is and what the possi= lbe > solution is. > >> > >> Could you kindly summarize it in one or two sentences ? > > > > I agree that use cases would help a lot. The ones I'm aware of are: > > > > * Web cookies: limit how high up the DNS tree a site can promote its co= okies. > > > > * DMARC and other mail authentication: find policy documents for a > > domain given one of its subdomains > > > > * SSL/TLS certificates: prevent certificate issue for names at or > > above public delegation points > > > > * Variants: state that two parallel names are under the same > > management (has issues different from the previous three) >=20 > Also from Firefox browser: >=20 > * domain highlighting in the URL bar >=20 > * restricting the setting of the document.domain property (DOM > same-origin policy) >=20 > Hugo [Hill, Brad] And possibly HSTS and Public Key Pinning with includeSubDomain= s flag set. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ray.polk@oracle.com Thu Mar 14 08:26:17 2013 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 1633911E82B0 for ; Thu, 14 Mar 2013 08:26:17 -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 Y-dC+D3sMucr for ; Thu, 14 Mar 2013 08:26:12 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id B8E3811E81D1 for ; Thu, 14 Mar 2013 08:26:12 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2EFQ9cd005833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Mar 2013 15:26:10 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2EFQ98r004326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 15:26:09 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2EFQ9oU015631; Thu, 14 Mar 2013 10:26:09 -0500 MIME-Version: 1.0 Message-ID: <06f33cf7-d3e6-4d64-b956-c7c35447a479@default> Date: Thu, 14 Mar 2013 08:26:08 -0700 (PDT) From: Ray Polk To: X-Mailer: Zimbra on Oracle Beehive Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-http-problem 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, 14 Mar 2013 15:26:17 -0000 True; error location & multiple errors are useful for validation of the bod= y. Those notions might also be useful for multiple input errors of other t= ypes as well, right? 403 - we return 403 when user agents provide incorrect CSRF prevention toke= ns &/or access_tokens &/or don't have permission. we're required to inform= UA of the issue (otherwise return 404); if both the CSRF token & access_to= ken are wrong, we'd like to inform on both issues in one response; possibly= specifying the erroneous query param or entity value. 406 - UA might have gotten more than one header wrong; so might be good to = specify which headers were wrong in order to scope the required list of val= id values 409 - where multiple fields violated some kind of scope/uniqueness constrai= nt Multiple errors needn't be only with input (headers, query parameters, requ= est body) either. I could envision a request causing more than one top lev= el error (say...406 & 409 at the same time). So anyway, w/e was chosen for error location (errorPath / errorFragmentIden= tifier / ...) might need to handle identifying header, query param, request= entity field....matrix param? ...path param?! ...or should there be one = response field per input type? ...or...? ----------- Could you provide an example of using an anchor / frag id? would it just b= e the json/yaml/xml/... field prefixed with a hash? ----------- Regarding "more" -- custom top level field are also allowed in the response= , right? to be ignored by clients? (per sec 3.3) If that's the case, is = there need for the "more" section? Regards, Ray ----- Original Message ----- From: dret@berkeley.edu To: ray.polk@oracle.com Cc: apps-discuss@ietf.org Sent: Friday, March 8, 2013 5:45:47 PM GMT -07:00 US/Canada Mountain Subject: Re: [apps-discuss] draft-nottingham-http-problem hello ray. thanks for the feedback. On 2013-03-08 14:28 , Ray Polk wrote: > I think http-problem is a good idea, and we're looking at adopting it. > A few questions: > Has the notion of errorField or problemPath been considered? Given a > problem, say 422, it might be useful to point out the associative array > entry / attribute / field that was problematic. The value could be the > field name or jsonPath to the erroneous field. this sounds mostly like a validation approach, where you are validating=20 the request and then have a specific point where validation failed.=20 while this is something that can happen, the question is whether this is=20 general enough to warrant a specific field. problems can occur for many=20 reasons, and validation is just one part of that. if such a field was added, the best way to do it might be a fragment=20 identifier, because the media type of the request could be anything, and=20 maybe the most general way to point to something might be a fragment=20 identifier. > Other than adding additional info to "more", is there any consideration > for multiple problems in one response? For instance, there may be more > than one problematic field in a request. It would be advantageous to > report them all at once instead of piecemeal. Perhaps a subProblem > field or array that contains additional problems? again, that sounds a lot like being very validation-oriented. the idea=20 is to report HTTP-level problems, not so much validation messages about=20 specific fragments where the requests caused validation problems. if=20 this kind of validation and reporting resulting errors is what you want=20 to do, the "more" is probably the way to go. > Has anyone written a bit of client code for this yet? nothing generic that i am aware of, but we're using it in specific=20 client code. and maybe it's a bit early for broader adoption because the=20 format is still evolving. mark probably can chime in here. cheers, dret. --=20 erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From superuser@gmail.com Thu Mar 14 12:40:07 2013 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 BB58111E820E for ; Thu, 14 Mar 2013 12:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9-3CIfk3Mbs6 for ; Thu, 14 Mar 2013 12:40:07 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F39BF11E8166 for ; Thu, 14 Mar 2013 12:40:06 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id 12so1388677wgh.3 for ; Thu, 14 Mar 2013 12:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=kyLZn6yUVQEEjWhtqQT1ara+/YjGqyVW/1yWp0MNCnk=; b=wcIZFg4c3FthI1F8H7ur99vIMYTpp/KOUsnxrM+9GcxvUcDbNts69qoDj3Nu8W6d0b z24iIQxdgWHf1TYCODaiNhM6aDpPhmXd2TZFoLSvjdEJmk0QpyH7ZiktYPAk687g+dnv r9fjnaF/QoBvxURuspUJ7+f9eaFwcBjgOES6rhyIe0xTjskVThhGqYAK/5c5KXE4qQJm JOjMb8CfS4PDle3S8urOlj15p+foRM+02Vh2g3EQo2bCv/iAJ/OBn6YaT5bXJN1VhJ1O BaI77CYqy8W697GyXRjZXTnSsclGtctoDrGGoCU6ept2+0luIP9Bk6u7sgQpCOYlG+fP ktpQ== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr6597634wjc.35.1363290006171; Thu, 14 Mar 2013 12:40:06 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Thu, 14 Mar 2013 12:40:06 -0700 (PDT) Date: Thu, 14 Mar 2013 15:40:06 -0400 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e013d1da88b395b04d7e7b050 Subject: [apps-discuss] draft-kucherawy-rfc5451bis 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, 14 Mar 2013 19:40:07 -0000 --089e013d1da88b395b04d7e7b050 Content-Type: text/plain; charset=ISO-8859-1 I've uploaded an update to draft-kucherawy-rfc5451bis for review. It incorporates the feedback I've received over the last few months since the last version. https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ To recap: RFC5451 defines a standard message header field for recording the results of things like DKIM and SPF by border MTAs so internal things like MUAs don't have to repeat those checks. This is an update draft based on operational experience since the proposed standard was originally published in 2009. So, two things: 1) Reviewers, please! I think this is pretty much ready to go as it's been around since last June with some reviews, but nothing lately. A final glance by some of the apps community (especially mail people) would be grand. 2) I'd like to process this through APPSAWG. Salvatore would have to shepherd it since I can't shepherd my own document. Is that a reasonable path for this work? There isn't an active working group doing SMTP things, and we know our ADs would prefer to avoid sponsoring things if possible. Thanks, -MSK, participatorially --089e013d1da88b395b04d7e7b050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've uploaded an update to draft-k= ucherawy-rfc5451bis for review.=A0 It incorporates the feedback I've re= ceived over the last few months since the last version.

https://datatr= acker.ietf.org/doc/draft-kucherawy-rfc5451bis/

To recap: RFC5451 defines a standard message header field fo= r recording the results of things like DKIM and SPF by border MTAs so inter= nal things like MUAs don't have to repeat those checks.=A0 This is an u= pdate draft based on operational experience since the proposed standard was= originally published in 2009.

So, two things:

1) Reviewers, please!=A0 = I think this is pretty much ready to go as it's been around since last = June with some reviews, but nothing lately.=A0 A final glance by some of th= e apps community (especially mail people) would be grand.

2) I'd like to process this through APPSAWG.=A0 Salvatore wou= ld have to shepherd it since I can't shepherd my own document.=A0 Is th= at a reasonable path for this work?=A0 There isn't an active working gr= oup doing SMTP things, and we know our ADs would prefer to avoid sponsoring= things if possible.

Thanks,
-MSK, participatorially

--089e013d1da88b395b04d7e7b050-- From ajs@anvilwalrusden.com Thu Mar 14 13:04:16 2013 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 2DE3311E80D7 for ; Thu, 14 Mar 2013 13:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 gU6mAhLRxpjv for ; Thu, 14 Mar 2013 13:04:15 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A9BAA11E81DE for ; Thu, 14 Mar 2013 13:04:15 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 071508A031 for ; Thu, 14 Mar 2013 20:04:14 +0000 (UTC) Date: Thu, 14 Mar 2013 16:04:13 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130314200412.GE50106@mx1.yitter.info> References: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> <20130313144321.37307.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130313144321.37307.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 14 Mar 2013 20:04:16 -0000 On Wed, Mar 13, 2013 at 02:43:21PM -0000, John Levine wrote: > * Variants: state that two parallel names are under the same management (has > issues different from the previous three) I'd like _not_ to include this as a target. I can see how this trick could be abused to help that problem, but the discussion upthread about cross-domain linkages and the potential for load in the DNS suggests to me that this is the wrong mechanism. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Mar 14 13:07:47 2013 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 8265211E81DC for ; Thu, 14 Mar 2013 13:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 bW-ai0b2j9em for ; Thu, 14 Mar 2013 13:07:47 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1130A11E80D7 for ; Thu, 14 Mar 2013 13:07:47 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 79E8C8A031 for ; Thu, 14 Mar 2013 20:07:46 +0000 (UTC) Date: Thu, 14 Mar 2013 16:07:44 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130314200744.GF50106@mx1.yitter.info> References: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> <20130313144321.37307.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 14 Mar 2013 20:07:47 -0000 On Wed, Mar 13, 2013 at 01:20:42PM -0400, Phillip Hallam-Baker wrote: > Regardless of what the DNS mythology claims, the DNS administrator of > example.com has complete control over the subtree beneath it. That is > how the DNS is designed. If the owner of a.b.c.d.e.f.g.h.i.example.com > wants independence from example.com they have only one route and that > is to buy a domain of their own. Well, yes and no. The administrator of example.com has complete control over the subtree beneath in the sense that s/he can either create names underneath, _or_ can delegate beneath, _or_ can delete the delegation. But if the administrator of example.com delegates away h.i.example.com, s/he has no control over what goes inside h.i.example.com. It's trivially true that any name has control of the delegations beneath it. But I don't see how it's relevant. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Thu Mar 14 13:09:14 2013 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 880F211E80D7 for ; Thu, 14 Mar 2013 13:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 woAx4AF78i9F for ; Thu, 14 Mar 2013 13:09:14 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2621F8D26 for ; Thu, 14 Mar 2013 13:09:13 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm11so4596233wib.1 for ; Thu, 14 Mar 2013 13:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=GvEK+kXGVes2cHDkfr51FHblR7/lBeYtjcU66FqeDj0=; b=TOD76xfRWbvY1oWhy/2UplNs41RRhRJbHfjMVblvJkW+jekblTdYUIuxZnp3vSsfIb fhfivKM4ePDJ9dh5MwPK5O0K5cVvHtJA943N8KlNR+Qx5T/W9jmqBhAOQQluAc+/oggu 4FFJxoEta1SX+xoWKpkJnS8FEAnxwa2sofs82NI4Ch2kuIb3YKt5bsZniuUNU/CYSZsj ObSAT45gNNNoGdR2T2zBJL8GdRT1T1Q6mYEzhAqFIK30wRgIkDF29kD5+MMMN+G51SyY QDuYoPv+f3cgns9EptFDoSYYmf8XbS5p0NBX+Y9ddd34+RXipT9xSGiqUCncnZ9Q1AaQ OKWQ== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr6725720wjc.35.1363291744945; Thu, 14 Mar 2013 13:09:04 -0700 (PDT) Received: by 10.180.189.6 with HTTP; Thu, 14 Mar 2013 13:09:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Mar 2013 16:09:04 -0400 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e013d1da82ed8fe04d7e81845 Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 14 Mar 2013 20:09:14 -0000 --089e013d1da82ed8fe04d7e81845 Content-Type: text/plain; charset=ISO-8859-1 Reviewers might find this diff from RFC5451 to the current version to be helpful: http://www.blackops.org/~msk/draft-kucherawy-rfc5451bis-from-rfc5451.diff.html -MSK On Thu, Mar 14, 2013 at 3:40 PM, Murray S. Kucherawy wrote: > I've uploaded an update to draft-kucherawy-rfc5451bis for review. It > incorporates the feedback I've received over the last few months since the > last version. > > https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ > > To recap: RFC5451 defines a standard message header field for recording > the results of things like DKIM and SPF by border MTAs so internal things > like MUAs don't have to repeat those checks. This is an update draft based > on operational experience since the proposed standard was originally > published in 2009. > > So, two things: > > 1) Reviewers, please! I think this is pretty much ready to go as it's > been around since last June with some reviews, but nothing lately. A final > glance by some of the apps community (especially mail people) would be > grand. > > 2) I'd like to process this through APPSAWG. Salvatore would have to > shepherd it since I can't shepherd my own document. Is that a reasonable > path for this work? There isn't an active working group doing SMTP things, > and we know our ADs would prefer to avoid sponsoring things if possible. > > Thanks, > -MSK, participatorially > > --089e013d1da82ed8fe04d7e81845 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reviewers might find this diff from RFC5451 to the cu= rrent version to be helpful:

http://www.blackops.org= /~msk/draft-kucherawy-rfc5451bis-from-rfc5451.diff.html

-MSK


On Thu, Mar 14, 2013 at 3:40 PM, Murray S. Kucherawy <super= user@gmail.com> wrote:
I'v= e uploaded an update to draft-kucherawy-rfc5451bis for review.=A0 It incorp= orates the feedback I've received over the last few months since the la= st version.

https://datatracker.ietf.org/doc/draft-kucherawy-rfc545= 1bis/

To recap: RFC5451 defines a standard message header field fo= r recording the results of things like DKIM and SPF by border MTAs so inter= nal things like MUAs don't have to repeat those checks.=A0 This is an u= pdate draft based on operational experience since the proposed standard was= originally published in 2009.

So, two things:

1) Reviewers, please!=A0 = I think this is pretty much ready to go as it's been around since last = June with some reviews, but nothing lately.=A0 A final glance by some of th= e apps community (especially mail people) would be grand.

2) I'd like to process this through APPSAWG.=A0 Salvatore wou= ld have to shepherd it since I can't shepherd my own document.=A0 Is th= at a reasonable path for this work?=A0 There isn't an active working gr= oup doing SMTP things, and we know our ADs would prefer to avoid sponsoring= things if possible.

Thanks,
-MSK, participatorially


--089e013d1da82ed8fe04d7e81845-- From ajs@anvilwalrusden.com Thu Mar 14 13:14:25 2013 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 1298E21F8E21 for ; Thu, 14 Mar 2013 13:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 YpjMwjVJ20Iu for ; Thu, 14 Mar 2013 13:14:24 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD4521F8B2B for ; Thu, 14 Mar 2013 13:14:24 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E31DA8A031 for ; Thu, 14 Mar 2013 20:14:23 +0000 (UTC) Date: Thu, 14 Mar 2013 16:14:22 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130314201421.GG50106@mx1.yitter.info> References: <20130310042250.GE33497@mx1.yitter.info> <370C9BEB4DD6154FA963E2F79ADC6F2E2795D464@DEN-EXDDA-S12.corp.ebay.com> <20130312201915.GD41728@mx1.yitter.info> <370C9BEB4DD6154FA963E2F79ADC6F2E27961C9F@DEN-EXDDA-S12.corp.ebay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E27961C9F@DEN-EXDDA-S12.corp.ebay.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 14 Mar 2013 20:14:25 -0000 On Wed, Mar 13, 2013 at 06:56:47PM +0000, Hill, Brad wrote: > > admin of a given label has control of descendant labels. The > hierarchy of control is more than just implied. > This hierarchy is a straight artifact of the hierarchical name space. So yes, but once you've performed delegation you can't control what happens on the other side of the zone cut (except by removing the delegation). Or, of course, maybe you can: maybe you're the same organization. This is sort of the point of what we're trying to do: there's no way to read that distinction from the DNS today. > algorithm and basic model otherwise remains totally intact. In > contrast, changes differentiate domain lowering properties among > siblings at the same depth are a much more substantial change to how > the Web security model works and increases the complexity of the > algorithms and implementations, the mental model for users, and the > complexity and size of the data needed to support that model. Well, yes, but people are doing this anyway, with really lousy security now. So it feels to me like we need to support it, even if we put in a deployment note making observations about what the experience might be particularly during early deployment. And after all, it is entirely possible to support the present model of operation in the approach I've outlined. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Mar 14 13:17:45 2013 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 737B911E81BE for ; Thu, 14 Mar 2013 13:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 6874g7lpCIKw for ; Thu, 14 Mar 2013 13:17:45 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 031E611E81B6 for ; Thu, 14 Mar 2013 13:17:45 -0700 (PDT) Received: from mx1.yitter.info (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 25F2E8A031 for ; Thu, 14 Mar 2013 20:17:35 +0000 (UTC) Date: Thu, 14 Mar 2013 16:17:33 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130314201733.GH50106@mx1.yitter.info> References: <20130312202442.GE41728@mx1.yitter.info> <20130312205006.GI41728@mx1.yitter.info> <20130313032655.GD41909@mx1.yitter.info> <20130313175552.GC45769@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] "finding registered domains" 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, 14 Mar 2013 20:17:45 -0000 On Wed, Mar 13, 2013 at 02:29:50PM -0400, Behnam Esfahbod wrote: > For example, company Example may wants to prevent cookie sharing between > its domain (example.com) and their outsourced shopping subdomain ( > shop.example.com), but likes to keep the address-bar domain-name > highlighting to "example.com", because of marketing reasons. This is an interesting point. It seems to me, however, that the whole point of the address bar name highlighting is supposed to be for the _user_, and to tell that user its scope. That makes me think that the answer here is, "Example loses." But the broader question is, "Is it sensible for a given name to have different administrative realms for different purposes?" If so, not to put too fine a point on it, I think we're screwed. A -- Andrew Sullivan ajs@anvilwalrusden.com From dret@berkeley.edu Thu Mar 14 15:18:03 2013 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 717F921F9063 for ; Thu, 14 Mar 2013 15:18:03 -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 BtexIsSFCQ50 for ; Thu, 14 Mar 2013 15:18:02 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id B0ED021F8F26 for ; Thu, 14 Mar 2013 15:18:02 -0700 (PDT) Received: from c-50-136-167-63.hsd1.ca.comcast.net ([50.136.167.63] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UGGTJ-0005vG-7l; Thu, 14 Mar 2013 15:18:02 -0700 Message-ID: <51424C92.8020100@berkeley.edu> Date: Thu, 14 Mar 2013 15:17:54 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <06f33cf7-d3e6-4d64-b956-c7c35447a479@default> In-Reply-To: <06f33cf7-d3e6-4d64-b956-c7c35447a479@default> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-nottingham-http-problem 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, 14 Mar 2013 22:18:03 -0000 hello ray. On 2013-03-14 08:26 , Ray Polk wrote: > True; error location & multiple errors are useful for validation of the body. Those notions might also be useful for multiple input errors of other types as well, right? > 403 - we return 403 when user agents provide incorrect CSRF prevention tokens &/or access_tokens &/or don't have permission. we're required to inform UA of the issue (otherwise return 404); if both the CSRF token & access_token are wrong, we'd like to inform on both issues in one response; possibly specifying the erroneous query param or entity value. when it comes to authentication, exposing too much detail definitely always may be a security issue. (the same is btw true for exposing implementation details such as software details/version, or even more detailed reports such as crash reports.) > 406 - UA might have gotten more than one header wrong; so might be good to specify which headers were wrong in order to scope the required list of valid values 406 specifically talk about providing details in a content type capable of doing so. while services are free to use their own, they might as well choose to use an HTTP problem report. i am not sure whether this (since it's part of HTTP itself) might warrant some special handling in the problem report schema. it could be either this, or there could just be growing consensus about a problemType and how 406 are handled. > 409 - where multiple fields violated some kind of scope/uniqueness constraint i think this is very similar to the 406 situation. > Multiple errors needn't be only with input (headers, query parameters, request body) either. I could envision a request causing more than one top level error (say...406 & 409 at the same time). that's simply impossible because of how HTTP works currently. why i do get your point, you can only report a 406 or a 409, and then include the details for that. we don't want to change HTTP error handling. > So anyway, w/e was chosen for error location (errorPath / errorFragmentIdentifier / ...) might need to handle identifying header, query param, request entity field....matrix param? ...path param?! ...or should there be one response field per input type? ...or...? yes, but that would be up for the problemType to specify. > Could you provide an example of using an anchor / frag id? would it just be the json/yaml/xml/... field prefixed with a hash? given that the context of an HTTP response is the request URI, i assume that using just a relative URI (starting with a hash) might be one way to go. on the other hand, such a relative URI would be a fragment of the *resource*, and not of the *request entity*, so maybe it would be a bad idea to do it like this. i am actually not quite sure how to best address this (since the request entity is not really a resource with a referencable URI), but maybe mark has some idea here. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From dave@cridland.net Fri Mar 15 04:34:04 2013 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 B3F2321F8D66 for ; Fri, 15 Mar 2013 04:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 5agJJM5aMWKj for ; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7DB21F8ABD for ; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so3192248oag.25 for ; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uvoqz0MZEHKnBPZgbkN653+BMZ7CFM5If6e0mCvqcEk=; b=GNoXtQKWcOSD0vM7KP03kD0nU92VmRcOeCake/JoBA8b5jbJ4fppjRFdJTol+zGyml YS7emGDabcvkRGuwfORkYOQs1lDRRrrNwBAFonA+yk7wdtNqXap19xhlLuP+cahlZE23 WrgB0FonH/OXU52XAt8FTZQnmrDmJnRxlW238= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=uvoqz0MZEHKnBPZgbkN653+BMZ7CFM5If6e0mCvqcEk=; b=AtjaY4Qumckov25GEI6b6k3kspf1czSSSfVPbAWXzWlwvttrayW72utRSpCbMK3SCO qe7qKSwtvXy1+JcVVQ0UBvDSt//gpBG1yqf1wzA+FXk0xE40KlAxBMhOQBEqoH9y4P4m 52/lPxXVwTOhLT8zcr1kZBoHJtTeCFqpBu1j44YcVoDZDUd0i3qHGXd0xEZzNPymogC0 9RhCx84HS602HnITEUdCJb7obSe9wA0xu3t5Elub6jEnJ5aSw/x+tiSkZXhmP1XmVw/q Kg06MRsIKmC9Aax0U8i+9s+tlamMtnXiVuSu/CXBJSFVvBslzKqUuuwSUp75P40Op2Wi f6HA== MIME-Version: 1.0 X-Received: by 10.60.10.226 with SMTP id l2mr2834490oeb.67.1363347243187; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 15 Mar 2013 04:34:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Mar 2013 11:34:03 +0000 Message-ID: From: Dave Cridland To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=e89a8fb1f8d022d7fe04d7f5047a X-Gm-Message-State: ALoCoQmoQHLgFYVTflBUqMZrH5mBN10ZWy6vZDXfdOpAsQSv6yN3sJcYxR10bMubGbV9yyozLjl1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 15 Mar 2013 11:34:04 -0000 --e89a8fb1f8d022d7fe04d7f5047a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 14, 2013 at 7:40 PM, Murray S. Kucherawy wrote: > I've uploaded an update to draft-kucherawy-rfc5451bis for review. It > incorporates the feedback I've received over the last few months since the > last version. > > https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ > > I've not seen this document before, nor its predecessor, so I'm casting a fresh pair of eyes on it. This may result in my not having understood the draft, but I'll pretend that's the draft's fault rather than it possibly being my own idiocy. For the most part, this document looks fine and solid. Two items concern me in a major way; one further item has me mildly nervous. First, the minor one: The header includes definition of a version ABNF production optionally following the authentication server's identity. It took me some time to find the note of how to treat this; I didn't see any examples with it present either. Second, the first major one: The examples tend to imply, for the most part, a canonical form to the header, which places CFWS is only particular places. In particular, all the examples are of the form auth-srv-id "; " method "=" result, with some optional properties and/or reason, with one single exception (which includes a comment in lieu of a reason). It's not immediately apparent to a comparatively novice reader that the following header field is valid: Authentication-Results: foo.example.net (My mailserver) / (I am number) 1 (You see) ; dkim (Because I like it) /2 (Two yay) = (wait for it) pass ; policy (And a dot can go here) . (Like that) fruit (which surprised me) = (because I was not expecting it) banana I appreciate it's always nicer to only write pretty examples, but given the specification, providing a nasty one is probably needed, lest people expect to take a whitespace delimited token and split it on '='. For some reason I particularly wasn't expecting the CFWS around the dot. (Maybe that's because I'm out of practise with header parsing). In any case, highlighting this with an example seems appropriate and useful. Thirdly, one more major concern: You'll note that I included a version for the method in my example above. The definition for this, from the comments in the ABNF, suggests that this relates to the version of RFC 5451 and successors used, but this seems unlikely - I'm also at a loss as to what a receiving implementation should do with such a method, since the handling of version seems to be specified only for the version number after the auth-srv-id. I have a vague suspicion that the correct thing to do here may be to deprecate the method version entirely, but I might be missing something - still, it doesn't appear to relate to the method, but the header field. Dave. --e89a8fb1f8d022d7fe04d7f5047a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Mar 14, 2013 at 7:40 PM, Murray S. Kucherawy <superuser@= gmail.com> wrote:
I'v= e uploaded an update to draft-kucherawy-rfc5451bis for review.=A0 It incorp= orates the feedback I've received over the last few months since the la= st version.

https://datatracker.ietf.org/doc/draft-kucherawy-rfc545= 1bis/


I&= #39;ve not seen this document before, nor its predecessor, so I'm casti= ng a fresh pair of eyes on it. This may result in my not having understood = the draft, but I'll pretend that's the draft's fault rather tha= n it possibly being my own idiocy.

For the most part, this document looks fine= and solid.

Two items concern me in a = major way; one further item has me mildly nervous.

First, the minor one:

The header includes definition of a version ABNF production optionally fol= lowing the authentication server's identity. It took me some time to fi= nd the note of how to treat this; I didn't see any examples with it pre= sent either.

Second, the first major one:

The examples tend to imply, for the most part, a can= onical form to the header, which places CFWS is only particular places. In = particular, all the examples are of the form auth-srv-id "; " met= hod "=3D" result, with some optional properties and/or reason, wi= th one single exception (which includes a comment in lieu of a reason). It&= #39;s not immediately apparent to a comparatively novice reader that the fo= llowing header field is valid:

Authentication-Results: foo.example.net (My mailserver) / (I am number) 1 (You = see) ; dkim (Because I like it) /2 (Two yay) =3D (wait for it) pass ; polic= y (And a dot can go here) . (Like that) fruit (which surprised me) =3D (bec= ause I was not expecting it) banana

I appreciate it's always nicer to only = write pretty examples, but given the specification, providing a nasty one i= s probably needed, lest people expect to take a whitespace delimited token = and split it on '=3D'. For some reason I particularly wasn't ex= pecting the CFWS around the dot. (Maybe that's because I'm out of p= ractise with header parsing).

In any case, highlighting this with an exam= ple seems appropriate and useful.

Thir= dly, one more major concern:

You'l= l note that I included a version for the method in my example above. The de= finition for this, from the comments in the ABNF, suggests that this relate= s to the version of RFC 5451 and successors used, but this seems unlikely -= I'm also at a loss as to what a receiving implementation should do wit= h such a method, since the handling of version seems to be specified only f= or the version number after the auth-srv-id.

I have a vague suspicion that the correct t= hing to do here may be to deprecate the method version entirely, but I migh= t be missing something - still, it doesn't appear to relate to the meth= od, but the header field.

Dave.
--e89a8fb1f8d022d7fe04d7f5047a-- From fgaliegue@gmail.com Fri Mar 15 06:24:06 2013 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 232E921F8D42 for ; Fri, 15 Mar 2013 06:24:06 -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 P5BUxdDgW6xt for ; Fri, 15 Mar 2013 06:24:05 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A56B621F85FC for ; Fri, 15 Mar 2013 06:24:00 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id h14so1574393eak.32 for ; Fri, 15 Mar 2013 06:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=rb0Boy962CloqmNiTsIZH4UX/L7INFmXfO76XLpu+dg=; b=eyXehcUrGUX3tLmQAmsl792UyFKAOlgeythztfXJBLPua8qf172FMlRaJffgg7LZmr 6KjprgVkHGqd85/3bf9QPXuNvM0jYqFoNIfV2Ob76bfNFKD7lFUZRnS+L1Hb8iG7BVb7 4zP5SbLh3dSWu1FqliWqs+Sag7VIVJwGRbO9bndLtX+Q5yNmFgPAk7lxqe6kKqN8HzYc H6Z0b/GQS/mlF/eBWqpwhrPrdF0ZTbCoGf/fe+J6E2gMCGVGWnxqICGl0FbpWC4DgpBG eKf1ymeCY9nKveKSj/B0fHB730YlcCLCpJ9PhxvfaLi0Fyc1PUAgLPVlR8FVNLB5Synd 3snQ== MIME-Version: 1.0 X-Received: by 10.14.209.131 with SMTP id s3mr18136071eeo.26.1363353839733; Fri, 15 Mar 2013 06:23:59 -0700 (PDT) Received: by 10.14.1.7 with HTTP; Fri, 15 Mar 2013 06:23:59 -0700 (PDT) Date: Fri, 15 Mar 2013 14:23:59 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] RFC 6570: what is the dot for in section 3? 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, 15 Mar 2013 13:24:06 -0000 Hello, The grammar for a variable name reads as such: varspec = varname [ modifier-level4 ] varname = varchar *( ["."] varchar ) varchar = ALPHA / DIGIT / "_" / pct-encoded I fail to see any mention of the dot anywhere else in the document when it appears in this context and I don't see any example either, not even in appendix A. And the "varchar" grammar token adds to the confusion since it seems to indicate the dot has a special role. If, for example I have a variable foo defined as: { "bar": 1, "baz": 2 } what is "foo.bar"? Does it refer to another variable entirely, or is it value of key "bar" in associate array "foo"? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From bortzmeyer@nic.fr Fri Mar 15 09:40:02 2013 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 23C8621F85EE for ; Fri, 15 Mar 2013 09:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 0nhlDS-afuct for ; Fri, 15 Mar 2013 09:39:56 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 19FE821F84F7 for ; Fri, 15 Mar 2013 09:39:54 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id C42323BC7B; Fri, 15 Mar 2013 16:39:52 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id 93DF6F004E5; Fri, 15 Mar 2013 17:39:25 +0100 (CET) Date: Fri, 15 Mar 2013 12:39:25 -0400 From: Stephane Bortzmeyer To: John Levine Message-ID: <20130315163925.GA477@laperouse.bortzmeyer.org> References: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> <20130313144321.37307.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130313144321.37307.qmail@joyce.lan> X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 15 Mar 2013 16:40:04 -0000 On Wed, Mar 13, 2013 at 02:43:21PM -0000, John Levine wrote a message of 23 lines which said: > I agree that use cases would help a lot. The ones I'm aware of are: Also (from actual experience at a TLD registry with both 2nd-level and 3rd-level registrations): Finding the guy in charge of a name. Two subcases: * A X.509 CA receives a request to authenticate www.foobar.asso.fr. Should it send the confirmation email to the holder of asso.fr or to the holder of foobar.asso.fr? * www.foobar.asso.fr hosts a phishing site. Should we write to abuse@foobar.asso.fr or to abuse@asso.fr? That's why I support the idea of doing something to solve this problem. (And I volunteer to review.) From johnl@taugh.com Fri Mar 15 13:24:18 2013 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 8B9C021F88F1 for ; Fri, 15 Mar 2013 13:24:18 -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 o93TY9U+pjsG for ; Fri, 15 Mar 2013 13:24:18 -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 C2F4221F88B0 for ; Fri, 15 Mar 2013 13:24:17 -0700 (PDT) Received: (qmail 81069 invoked from network); 15 Mar 2013 20:24:17 -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=13cab.51438371.k1303; bh=3JfHkczQbV09p+xaDIq/J4ng1PbUfNsppkDxIvZiC1c=; b=FOrY8WS5BMk42RrL8i2Mq+BHQvHT29aU8tS793HSZbLT/gCv1Xjeilyl5HNHk7mOHR+xqJpceooub5ahaT+jD6xAhK67rTi8lDf0qXmxN1T5FITghGAy2JvFO34E3v5n186pqDmZr9NLeqZLhdAmxx3j7iDcAIR37UlEAqaV/2c= 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=13cab.51438371.k1303; bh=3JfHkczQbV09p+xaDIq/J4ng1PbUfNsppkDxIvZiC1c=; b=g7f7JEFY8E568ZWaLitBTfB7oTim0rsnVke1EFFMamzqLzYqjFiTNYHVcu7KV957W2Pi2FcJY7lfhGrcCvEJAoKqdl0AbJ/3Iyiqckk1iy2MGRzwt/cnBO5Vd1E+OKOjBuv7dySeM++HbWl+liRBbOCcZQq1M8M/qxjz+ssNQxQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 15 Mar 2013 20:23:55 -0000 Date: 15 Mar 2013 16:24:13 -0400 Message-ID: From: "John R Levine" To: "Stephane Bortzmeyer" In-Reply-To: <20130315163925.GA477@laperouse.bortzmeyer.org> References: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> <20130313144321.37307.qmail@joyce.lan> <20130315163925.GA477@laperouse.bortzmeyer.org> 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: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 15 Mar 2013 20:24:18 -0000 > * A X.509 CA receives a request to authenticate > www.foobar.asso.fr. Should it send the confirmation email to the > holder of asso.fr or to the holder of foobar.asso.fr? > > * www.foobar.asso.fr hosts a phishing site. Should we write to > abuse@foobar.asso.fr or to abuse@asso.fr? Those look to me basically the same as finding the highest name in the tree under the same management. The next step of getting the contact info is WEIRDS' department. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. PS: That second scenario is why I run abuse.net. It would be nice if I didn't have to any more. From bortzmeyer@nic.fr Fri Mar 15 15:05:24 2013 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 A419521F896D for ; Fri, 15 Mar 2013 15:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 AetG7pzyi+KK for ; Fri, 15 Mar 2013 15:05:22 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 8F83621F896B for ; Fri, 15 Mar 2013 15:05:19 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 221ED3BE45; Fri, 15 Mar 2013 22:05:17 +0000 (UTC) Received: by tyrion (Postfix, from userid 1000) id 1DFCAF0055E; Fri, 15 Mar 2013 22:56:53 +0100 (CET) Date: Fri, 15 Mar 2013 17:56:53 -0400 From: Stephane Bortzmeyer To: John Levine Message-ID: <20130315215652.GA8704@laperouse.bortzmeyer.org> References: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> <20130313144321.37307.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130313144321.37307.qmail@joyce.lan> X-Transport: UUCP rules X-Operating-System: Ubuntu 12.04 (precise) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 15 Mar 2013 22:05:24 -0000 On Wed, Mar 13, 2013 at 02:43:21PM -0000, John Levine wrote a message of 23 lines which said: > I agree that use cases would help a lot. The ones I'm aware of are: Another one I had at $DAYJOB: we make statistics about the "most frequently requested" domains on our authoritative name servers. Of course, we want foo.bar.example.fr and machin.example.fr to be counted both as "example.fr". Some DNS statistics program (like DSC) do it blindly, just by the number of labels. But .fr delegates both at the 2nd and 3rd level (gouv.fr, asso.fr, tm.fr...). We had to use Mozilla Public Suffix List (via the excellent ) for that (for .fr, we know the registration rules and could have hardwired them, but the program had to work for other TLD). From johnl@taugh.com Fri Mar 15 15:16:38 2013 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 5CBEF21F88A0 for ; Fri, 15 Mar 2013 15:16:38 -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 UnF6UkLJoSk1 for ; Fri, 15 Mar 2013 15:16:37 -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 8359621F861B for ; Fri, 15 Mar 2013 15:16:21 -0700 (PDT) Received: (qmail 7187 invoked from network); 15 Mar 2013 22:16:20 -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=1c12.51439db4.k1303; bh=RBcpw56C1cgXLiokj49ehiXxY2wvG3izTVuV4iECkyI=; b=jNBX/1meJxfSpdmVog49T7oxLwVPB8mBC5CQ2G8hRCFefMu1G0M5yt9RGObx1pjFuU7JrVsYjLb5TozOTt2naP3uwLcP3iatOAOO4tuLIXRzL61Yd9biE/bQrPX1wm5ZUm0VcAijVk1fqAoPPXvlAkV/lSJhksat26J4mUx/diw= 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=1c12.51439db4.k1303; bh=RBcpw56C1cgXLiokj49ehiXxY2wvG3izTVuV4iECkyI=; b=O+HkG70WUuw9uBWI2l884A2Jv6avNsZUa4f/spiYA0Np4YTMkjf6hyXQlSSgahPswS233qJ15/o3k6pQTwh4aQS3QIQlgaBZ6ojlPzl38p3BTBdwwIq+v/SG4a7lYv6lfXTsMjhvn+x/CxjDdK6fJxEFI6HLTuZ5F9wIijF5rSE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 15 Mar 2013 22:15:58 -0000 Date: 15 Mar 2013 18:16:17 -0400 Message-ID: From: "John R Levine" To: "Stephane Bortzmeyer" In-Reply-To: <20130315215652.GA8704@laperouse.bortzmeyer.org> References: <83AFF07DE0F646C0860A0631F973E9D1@LENOVO47E041CF> <20130313144321.37307.qmail@joyce.lan> <20130315215652.GA8704@laperouse.bortzmeyer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-443767558-1363385780=:3600" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] "finding registered domains" 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, 15 Mar 2013 22:16:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-443767558-1363385780=:3600 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> I agree that use cases would help a lot. The ones I'm aware of are: > > Another one I had at $DAYJOB: we make statistics about the "most > frequently requested" domains on our authoritative name servers. Of > course, we want foo.bar.example.fr and machin.example.fr to be counted > both as "example.fr". Some DNS statistics program (like DSC) do it > blindly, just by the number of labels. But .fr delegates both at the > 2nd and 3rd level (gouv.fr, asso.fr, tm.fr...). We had to use Mozilla > Public Suffix List (via the excellent > ) for that (for .fr, we > know the registration rules and could have hardwired them, but the > program had to work for other TLD). If you're running an authoritative server, you're mostly handing out referrals, so you know exactly where the delegations are. Why don't you have your statistics programs report what the servers actually did? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-443767558-1363385780=:3600 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIIBgYJKoZIhvcNAQcCoIIH9zCCB/MCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBSMwggUfMIIEB6ADAgECAhBqmDwY4viwyBNv7hg7djRHMA0G CSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDgyNzAwMDAwMFoX DTEyMDgyNjIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2gu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjjY2CfvJ3My a2g1aOrImd0uJVLaah8aKJ8PSJJZth2vTQsMq3ozNxcZWKKRROOUfMeJWQDa xl0J7d0XCdVjK40s+ZWKvlqwxLHCyIn4Enzk8lkoMq2qQUqnGaGbNQBxQK11 4JINMKOLMkP1WZgOwfDcROBhlKnK7FgNFgXouNS0nFUzosqlKOfYW6Ryl5rV cLInOqGv78O/ekb9YtzHMVlrF9sKC5D8ijis0RY5uvdb47YCoKvI/Pm5g2wK EYeD+sJXhSUp3zPct5VLDG1jrN2zjQEVrSFDQ/Ny58EnaNkOSMdE1tRQ7/Nf ckoMGXqJRedbx7d/H62kGaDb7QrAawIDAQABo4IB3zCCAdswHwYDVR0jBBgw FoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFFNpWjhcj0fXS96W ENsvzag4QY9yMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1Ud JQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqg SIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6 MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP am9obmxAdGF1Z2guY29tMA0GCSqGSIb3DQEBBQUAA4IBAQB1BxfCpqDbjmN/ bGxym680l1in8LQqE0Vr/zbbz9lcDIPDdaQRDxtRkEf5KdlSrfLk23R0Ri9x UQanAmVsFpboEhR/rmSdECdkImgAHd+ruZwNpbwX5+U8T0yaU0/Y/Xm+Rdfa KuEJTVFsO9S6KsKkgTyDoeMoCRIER6ChQyRE51QCyREk9xt6aw03Vj42mZBq v4mYNVpqzFLs9JLCotV7C9oViKip1UzYj3khybTrC0wn8Q+c99qr03YCpdD5 G+fotgtPEBomtRW4UnUBmZ3foBBah5mTSwPkaBC6p1yN+2qEy075c5tzT/EH xs7UzXgqn87a8S6cROUqPtykd+NGMYICqzCCAqcCAQEwgagwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGqYPBji+LDIE2/uGDt2NEcwCQYFKw4DAhoFAKCB2DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMTUyMjE2 MTdaMCMGCSqGSIb3DQEJBDEWBBSuJizeYLXJ9plRl6BqDr7VfswPKTB5Bgkq hkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQAzAg3HcGdGWjVmM3y0RrxWv1qzjhWc/s3edpsexmJvzGxV9hlJSBIMrBbS alwmaoxjedUUdZSWRuxCSl4u4YqjUDJ8GVojieD3uvNDXnCWwweoV6393+gd JPMtwqpKIyqYrwQbifwhQlqOvK5jkajx1G5lIFnl/RcgkhcaTOT3FU2Mnkh2 Ncvc3MyrkZV72RaV1IL99E/kx4apR1pVVO9FdsEecQjzMNZfG4T8XXzDD2lc 1uhVxC8+JNQYCRgIBsA4ohaoNFMpfalFQc4+X5BfCnuP4tEweIxAZ0s9hP77 +Vfp+1BFBaZp1lq1nt2i5DEA87AAAqwGxUxrKJSsdXk8 --3825401791-443767558-1363385780=:3600-- From vesely@tana.it Sat Mar 16 01:52:15 2013 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 01F2521F8C00 for ; Sat, 16 Mar 2013 01:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 YY9HXuGy-qlL for ; Sat, 16 Mar 2013 01:52:14 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6017C21F8BFD for ; Sat, 16 Mar 2013 01:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1363423932; bh=7UKi+/NVLo0uPXybJ5BGNXJCPf2vl7wZIQ6uJnZJPw0=; l=882; h=Date:From:To:References:In-Reply-To; b=LWS7dSSqsLR9f7Bw3TqTurvXA2LRy/X7ttpDJk5z+1zNuPHyTu/kLExcSI+5BJF3y Pn9Fcf14EZ6IKVnEg+I/A42GdV9v5LGdxpiKK484Vp8ntsLVKUwzUBgAzWajqaNgMc wmSw812HtBGhVGfMloq5kiYhe1oCPjXQkF8Oz1LI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 16 Mar 2013 09:52:12 +0100 id 00000000005DC039.00000000514432BC.00004B05 Message-ID: <514432BC.1010805@tana.it> Date: Sat, 16 Mar 2013 09:52:12 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 16 Mar 2013 08:52:15 -0000 On Fri 15/Mar/2013 12:34:03 +0100 Dave Cridland wrote: > > Authentication-Results: foo.example.net (My mailserver) / (I am > number) 1 (You see) ; dkim (Because I like it) /2 (Two yay) = (wait > for it) pass ; policy (And a dot can go here) . (Like that) fruit > (which surprised me) = (because I was not expecting it) banana My understanding is that the above is not valid. Nuking three chars, the first "/" and the "1" from autherv-id, which should be dot-atom, and then the ";" between "pass" and "policy", which shouldn't be there, I can parse it with my new Perl function, and get: $VAR1 = { 'dkim' => [ { 'policy_fruit' => 'banana', 'result' => 'pass' } ] }; (I s/./_/ for ease of use.) I agree the grammar is laid down too lazily. For example, dot-atom allows equal signs to be part of property, e.g. "fru=it", which would be unparsable. From vesely@tana.it Sat Mar 16 01:59:49 2013 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 7069F21F8895 for ; Sat, 16 Mar 2013 01:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 ysuWtDhIYdVe for ; Sat, 16 Mar 2013 01:59:48 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B455321F8873 for ; Sat, 16 Mar 2013 01:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1363424387; bh=8rLODaMjK+SLUhOgJkjhHD0aJaNhMlGlwK5IG9hWJ0Q=; l=1248; h=Date:From:To:References:In-Reply-To; b=lq/Ar39WuSUlJEIlGOFCZbnwBgAxjhRggNZomVoeKfGgPPoG6wXtvARIx3Uf/Lqb/ D+qnnIuePhTdSm+wDIt2A7Cm8zgD5TMda9iw2Dcaa/HymneMnexJkkOYbEaPb/NAGW hNlOOqYi9dAs3Onfk6AV7qPZ/5PrNemFyiPGA0bI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 16 Mar 2013 09:59:47 +0100 id 00000000005DC039.0000000051443483.00006DD0 Message-ID: <51443483.9030805@tana.it> Date: Sat, 16 Mar 2013 09:59:47 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> In-Reply-To: <514432BC.1010805@tana.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 16 Mar 2013 08:59:49 -0000 On Sat 16/Mar/2013 09:52:12 +0100 Alessandro Vesely wrote: > On Fri 15/Mar/2013 12:34:03 +0100 Dave Cridland wrote: >> >> Authentication-Results: foo.example.net (My mailserver) / (I am >> number) 1 (You see) ; dkim (Because I like it) /2 (Two yay) = (wait >> for it) pass ; policy (And a dot can go here) . (Like that) fruit >> (which surprised me) = (because I was not expecting it) banana > > My understanding is that the above is not valid. Nuking three chars, > the first "/" and the "1" from autherv-id, which should be dot-atom, Oops, I overlooked that "[ CFWS version ]" in authres-header. Thus you helped me catch a bug. Thanks! > and then the ";" between "pass" and "policy", which shouldn't be > there, I can parse it with my new Perl function, and get: > > $VAR1 = { > 'dkim' => [ > { > 'policy_fruit' => 'banana', > 'result' => 'pass' > } > ] > }; > > (I s/./_/ for ease of use.) > > I agree the grammar is laid down too lazily. For example, dot-atom > allows equal signs to be part of property, e.g. "fru=it", which would > be unparsable. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From dave@cridland.net Sat Mar 16 11:43:42 2013 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 22B0A21F85E8 for ; Sat, 16 Mar 2013 11:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 ZLW2WFUKuD79 for ; Sat, 16 Mar 2013 11:43:40 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 987BC21F8454 for ; Sat, 16 Mar 2013 11:43:40 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so4390321oag.40 for ; Sat, 16 Mar 2013 11:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZGuyYLwqt1XvzVlFpLywFqlXd5PKz3+kXqz1OCyCClY=; b=f5LilFx5LCnMvvIjGkC/8Uv+QQz1n5a7U2uH1Yimx3FkV9biVO079IH0/o/lGd6jNq x7djj81GikVp/oJUUynSaXmJJunOylsk78FV89FWEqTSVPzV0uFGZ0clwq3w5FpuvMuX yqb4I84oNT7JhYRaAG0iDHMEcw25cQAdfBYGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ZGuyYLwqt1XvzVlFpLywFqlXd5PKz3+kXqz1OCyCClY=; b=jTF8Xg3XLgTxkKtT5Lyv/Gx+pqd1B1Fwo9u9E3pu1wQZ5yp5oXB0+3TYSZET5DXkS6 VW2c4r2+6ugBSPKF1gbtsFosjA5FUiFHCF046wgBatsPBFsqMelXg6FT0kQrSSuNvWAj mPyxok0U378JkQV+ofR0nrPmF9l960TmuiyvCNXL4GPl2X4MLN/3f0LqPpQI+btLW7an /KxF2PuP6HLkyh6oVjpRQbrCdnzRzy5tf8S+xlgqPeBki/MUDMRhBij1AnK/ya6aXdIR ODcGuu7JqM4r2p7QxkjFM+I8hdviCrVAAhIgShItB1x5U5XDI2pqdZwaqr6L2JIM1lIw 1Vvw== MIME-Version: 1.0 X-Received: by 10.182.72.5 with SMTP id z5mr4783094obu.24.1363459417889; Sat, 16 Mar 2013 11:43:37 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Sat, 16 Mar 2013 11:43:37 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Sat, 16 Mar 2013 11:43:37 -0700 (PDT) In-Reply-To: <51443483.9030805@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> Date: Sat, 16 Mar 2013 18:43:37 +0000 Message-ID: From: Dave Cridland To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d0447853344f89a04d80f22f6 X-Gm-Message-State: ALoCoQkIxZuVtt74vMdN7t+vPhMecWEjfN5572b1baXi0ftMCrgY6Wg/f4B5gqUyc+3j2TqkowBj Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 16 Mar 2013 18:43:42 -0000 --f46d0447853344f89a04d80f22f6 Content-Type: text/plain; charset=ISO-8859-1 On 16 Mar 2013 08:59, "Alessandro Vesely" wrote: > > On Sat 16/Mar/2013 09:52:12 +0100 Alessandro Vesely wrote: > > On Fri 15/Mar/2013 12:34:03 +0100 Dave Cridland wrote: > >> > >> Authentication-Results: foo.example.net (My mailserver) / (I am > >> number) 1 (You see) ; dkim (Because I like it) /2 (Two yay) = (wait > >> for it) pass ; policy (And a dot can go here) . (Like that) fruit > >> (which surprised me) = (because I was not expecting it) banana > > > > My understanding is that the above is not valid. Nuking three chars, > > the first "/" and the "1" from autherv-id, which should be dot-atom, > > Oops, I overlooked that "[ CFWS version ]" in authres-header. Thus > you helped me catch a bug. Thanks! > That was even the one that was properly specified... it's the other one I'm more concerned with. Dave. --f46d0447853344f89a04d80f22f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 16 Mar 2013 08:59, "Alessandro Vesely" <vesely@tana.it> wrote:
>
> On Sat 16/Mar/2013 09:52:12 +0100 Alessandro Vesely wrote:
> > On Fri 15/Mar/2013 12:34:03 +0100 Dave Cridland wrote:
> >>
> >> Authentication-Results: fo= o.example.net (My mailserver) / (I am
> >> number) 1 (You see) ; dkim (Because I like it) /2 (Two yay) = =3D (wait
> >> for it) pass ; policy (And a dot can go here) . (Like that) f= ruit
> >> (which surprised me) =3D (because I was not expecting it) ban= ana
> >
> > My understanding is that the above is not valid. =A0Nuking three = chars,
> > the first "/" and the "1" from autherv-id, wh= ich should be dot-atom,
>
> Oops, I overlooked that "[ CFWS version ]" in authres-header= . =A0Thus
> you helped me catch a bug. =A0Thanks!
>

That was even the one that was properly specified... it'= s the other one I'm more concerned with.

Dave.

--f46d0447853344f89a04d80f22f6-- From vesely@tana.it Sun Mar 17 02:18:19 2013 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 9599021F87E5 for ; Sun, 17 Mar 2013 02:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 TwMzM2KnduoB for ; Sun, 17 Mar 2013 02:18:19 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2D21F87D7 for ; Sun, 17 Mar 2013 02:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1363511897; bh=WemwkQEW1FI9uid/vde6kiuBxAcroeoC5orL6qq4RlI=; l=1083; h=Date:From:To:References:In-Reply-To; b=cmb45pAri5Fu0xAxce4LUvYQcbKlZxu40Qi4sskvJdB6wz7ZdiGbPQRE8vfthquXn L2248H3DO5Gx6bxnrNK4aFr+edvDyX9RCA9KNOCbHmK0DNN99UQgI6ZJYSJDF5skIL bSwxZsEEuaONtLPcW5bzauQWf9E6ZO95X8Lel3Eg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sun, 17 Mar 2013 10:18:16 +0100 id 00000000005DC039.0000000051458A58.000038EA Message-ID: <51458A59.8040206@tana.it> Date: Sun, 17 Mar 2013 10:18:17 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 17 Mar 2013 09:18:19 -0000 On Sat 16/Mar/2013 19:43:37 +0100 Dave Cridland wrote: > On 16 Mar 2013 08:59, "Alessandro Vesely" wrote: >> >> Oops, I overlooked that "[ CFWS version ]" in authres-header. Thus >> you helped me catch a bug. Thanks! >> > > That was even the one that was properly specified... it's the other > one I'm more concerned with. "Properly" might be something of an overstatement. Section 2.3 says: For tracing and debugging purposes, the authentication identifier MAY instead be the hostname of the MTA performing the authentication check whose result is being reported. This is also useful for another purpose, as described in Section 4. Moreover, some implementations have considered appending a delimiter such as "/" and following it with useful transport tracing data such as the [SMTP] queue ID or a timestamp. Informal discussions like that tend to be ambiguous because "/" is allowed in dot-atom. Hence one doesn't know whether the text means something like: server.example.com/Q304b5 / 1 or: server.example.com / 197813 From dave@cridland.net Sun Mar 17 04:35:02 2013 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 294C121F88B1 for ; Sun, 17 Mar 2013 04:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 cLkRMfPo+BEX for ; Sun, 17 Mar 2013 04:35:01 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D106021F88B9 for ; Sun, 17 Mar 2013 04:35:00 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uz6so4478868obc.6 for ; Sun, 17 Mar 2013 04:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qPaxeyT6vwWdCNjTA8pRrCNWJROnF7KsS55Bi29O7Cw=; b=ZuRgfIVRs+PLPM61+mR3ODmaAR4wfVD8iTbY7MIyvWTlwWryEEME0N1CUX5X6CQWCo DpD1HlQq0IBWmyeJmxWS/kNQhdlB+ReMnMCI7Io47yMixHRfcSi7uNe21EJTn43/Z7Yf DNHXgmboDxAro2mK5kM2G7wLtOWEEn/qYFTJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=qPaxeyT6vwWdCNjTA8pRrCNWJROnF7KsS55Bi29O7Cw=; b=GoTMaB17svq0Yj60Ow3iVlqtsIK2Q8DWjT2FGXnrRzK6s73RYRpabkCiVakqg1QaRJ 1T9vtbeb3gEfZZ6n8NvVV8dzqQ6QXAY3iuPOCCh8WW3O+9tzfALprmG4N4Q7yrGcDjv+ 5tkxwdJ1rIeg92dNF0eEuAjhn/IEFf1saTaCK/UvaAIthTdCh3tceYkJ0X/ICLH4/GDn FZQE5vA0rI3WFYHGff63XfYfeYNPuhtQW3ueHkooo7Sw6VuILbeC9SeRdBuVr2mw7CGB fmC7i2r0m1WJArMMqscpInh6yhWyYyG9oWIB62EewWUJNsa22fxYrgTM52KxD5qXDnZl LZXw== MIME-Version: 1.0 X-Received: by 10.60.31.79 with SMTP id y15mr5506199oeh.123.1363520099784; Sun, 17 Mar 2013 04:34:59 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Sun, 17 Mar 2013 04:34:59 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Sun, 17 Mar 2013 04:34:59 -0700 (PDT) In-Reply-To: <51458A59.8040206@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> Date: Sun, 17 Mar 2013 11:34:59 +0000 Message-ID: From: Dave Cridland To: Alessandro Vesely Content-Type: multipart/alternative; boundary=e89a8fb1f16431326a04d81d433f X-Gm-Message-State: ALoCoQkImHPXe28vSN+f7uFpC6ME2Y/ghS551SXFUruVeXKh1wHNYuVwHTJ+OQXfKyfeYlbgW/qb Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 17 Mar 2013 11:35:02 -0000 --e89a8fb1f16431326a04d81d433f Content-Type: text/plain; charset=ISO-8859-1 Oh, well spotted. I'd not seen that one. --e89a8fb1f16431326a04d81d433f Content-Type: text/html; charset=ISO-8859-1

Oh, well spotted. I'd not seen that one.

--e89a8fb1f16431326a04d81d433f-- From eburger@standardstrack.com Mon Mar 18 07:59:25 2013 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 C518D21F8F2B for ; Mon, 18 Mar 2013 07:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.713 X-Spam-Level: X-Spam-Status: No, score=-99.713 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 o0Bq+GEbZGWq for ; Mon, 18 Mar 2013 07:59:25 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4533A21F8F25 for ; Mon, 18 Mar 2013 07:59:25 -0700 (PDT) Received: from 8.sub-70-192-200.myvzw.com ([70.192.200.8]:6143 helo=[10.184.52.190]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UHbX0-0001Tt-0i; Mon, 18 Mar 2013 07:59:22 -0700 Mime-Version: 1.0 (1.0) From: Eric Burger Content-Type: multipart/alternative; boundary=Apple-Mail-D19D0371-3D99-47E9-B244-413F2990C3E6 X-Mailer: iPad Mail (10B146) Message-Id: Date: Mon, 18 Mar 2013 10:59:22 -0400 Content-Transfer-Encoding: 7bit To: "draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org" , "xrblock-chairs@tools.ietf.org" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Apps Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10 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, 18 Mar 2013 14:59:25 -0000 --Apple-Mail-D19D0371-3D99-47E9-B244-413F2990C3E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable In general, this document is ready to go. I have one editorial suggestion. I= n order to understand this document, I had to read draft-ietf-xrblock-rtcp-x= r-discard-11 and draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 to figure= out where this draft fits into the jitter reporting ecosystem. I get why th= ese are all small, separate drafts. However, I could not easily find an over= arching document tying things together. draft-ietf-xrblock-rtcp-xr-discard-r= le-metrics-05 does a decent job in the Introduction of describing the relati= onship between xr-burst-gap-discard and xr-discard. However, that is in the c= ontext of why we have a third draft on what on first read looks like the sam= e metrics. The three drafts cover three facets of jitter metrics. What is missing is a r= oadmap for implementors that does two things. The first is it makes it clear= where to go to do what. I can easily imagine an implementor wanting to do j= itter measurements, finding just one of these drafts, and think they need to= do a proprietary extension because the IETF 'forgot' to include something i= n the jitter reporting. Another issue is I found myself reading xr-discard a= nd xr-burst-gap-discard in parallel. They made a whole lot more sense readin= g them that way than one at a time. Moreover, I found I had to read them in p= arallel to understand xr-burst-gap-discard. Therefore, it would be helpful t= o either have a separate roadmap document or a paragraph or two in each docu= ment referring the reader to the other documents. That way the reader knows t= hey exist, knows there may be a better / more coverage for reporting than a s= ingle document implies, and they can find the other documents. I would offer= this will improve the readability and ultimate interoperability of the resu= lting implementations.= --Apple-Mail-D19D0371-3D99-47E9-B244-413F2990C3E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable In general, this document is ready to go. I= have one editorial suggestion. In order to understand this document, I had t= o read draft-= ietf-xrblock-rtcp-xr-discard-11 and draft-ietf-xrblock-rtcp-xr-discard-= rle-metrics-05 to figure out where this draft fits into the j= itter reporting ecosystem. I get why these are all small, separate drafts. H= owever, I could not easily find an overarching document tying things togethe= r. dra= ft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 does a decent job in the Intr= oduction of describing the relationship between xr-burst-gap-discard and xr-= discard. However, that is in the context of why we have a third draft on wha= t on first read looks like the same metrics.

The three drafts cover three facet= s of jitter metrics. What is missing is a roadmap for implementors that does= two things. The first is it makes it clear where to go to do what. I can ea= sily imagine an implementor wanting to do jitter measurements, finding just o= ne of these drafts, and think they need to do a proprietary extension becaus= e the IETF 'forgot' to include something in the jitter reporting. Another is= sue is I found myself reading xr-discard and xr-burst-gap-discard in paralle= l. They made a whole lot more sense reading them that way than one at a time= . Moreover, I found I had to read them in parallel to understand= xr-burst-gap-discard. Therefore, it would be helpful to either have a separ= ate roadmap document or a paragraph or two in each document referring the re= ader to the other documents. That way the reader knows they exist, knows the= re may be a better / more coverage for reporting than a single document impl= ies, and they can find the other documents. I would offer this will improve t= he readability and ultimate interoperability of the resulting implementation= s.
= --Apple-Mail-D19D0371-3D99-47E9-B244-413F2990C3E6-- From acooper@cdt.org Mon Mar 18 08:31:21 2013 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 B16F321F85CE; Mon, 18 Mar 2013 08:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 DlZ2xSEjoB+C; Mon, 18 Mar 2013 08:31:21 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8A50B21F856D; Mon, 18 Mar 2013 08:31:20 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 18 Mar 2013 11:31:17 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 11:31:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (WebFinger) 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: Mon, 18 Mar 2013 15:31:21 -0000 Given how little control Internet users already have over which = information about them appears in which context, I do not have a lot of = confidence that the claimed discoverability benefits of WebFinger = outweigh its potential to further degrade users' ability to keep = particular information about themselves within specific silos. However, = I'm coming quite late to this document, so perhaps that balancing has = already been discussed, and it strikes me as unreasonable to try to = stand in the way of publication at this point. Two suggestions in section 8: s/personal information/personal data/ (see = http://tools.ietf.org/html/draft-iab-privacy-considerations-06#section-2.2= -- personal data is a more widely accepted term and covers a larger = range of information about people) The normative prohibition against using WebFinger to publish personal = data without authorization is good, but the notion of implicit = authorization leaves much uncertainty about what I imagine will be a use = case of interest: taking information out of a controlled context and = making it more widely available. To make it obvious that this has been = considered, I would suggest adding one more sentence to the end of the = fourth paragraph: "Publishing one's personal data within an access-controlled or otherwise = limited environment on the Internet does not equate to providing = implicit authorization of further publication of that data via = WebFinger." Alissa On Mar 4, 2013, at 3:24 PM, The IESG wrote: >=20 > The IESG has received a request from the Applications Area Working = Group > WG (appsawg) to consider the following document: > - 'WebFinger' > as Proposed Standard >=20 > 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 2013-03-18. 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. >=20 > Abstract >=20 >=20 > This specification defines the WebFinger protocol, which can be used > to discover information about people or other entities on the > Internet using standard HTTP methods. WebFinger discovers > information for a URI that might not be usable as a locator > otherwise, such as account or email URIs. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From mnot@mnot.net Mon Mar 18 17:01:23 2013 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 6B70521F8AE8 for ; Mon, 18 Mar 2013 17:01: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 gqM3CbTzGRxt for ; Mon, 18 Mar 2013 17:01:22 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 95D9721F8ADC for ; Mon, 18 Mar 2013 17:01:22 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.42.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DD779509B9; Mon, 18 Mar 2013 20:01:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Tue, 19 Mar 2013 11:01:16 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Francis Galiegue X-Mailer: Apple Mail (2.1499) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 6570: what is the dot for in section 3? 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, 19 Mar 2013 00:01:23 -0000 It's there as a convenience to implementations, so they can model data = structures (e.g., dictionaries) easily. On 16/03/2013, at 12:23 AM, Francis Galiegue = wrote: > Hello, >=20 > The grammar for a variable name reads as such: >=20 > varspec =3D varname [ modifier-level4 ] > varname =3D varchar *( ["."] varchar ) > varchar =3D ALPHA / DIGIT / "_" / pct-encoded >=20 > I fail to see any mention of the dot anywhere else in the document > when it appears in this context and I don't see any example either, > not even in appendix A. And the "varchar" grammar token adds to the > confusion since it seems to indicate the dot has a special role. >=20 > If, for example I have a variable foo defined as: >=20 > { "bar": 1, "baz": 2 } >=20 > what is "foo.bar"? Does it refer to another variable entirely, or is > it value of key "bar" in associate array "foo"? >=20 > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema in Java: http://json-schema-validator.herokuapp.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From tobias.gondrom@gondrom.org Mon Mar 18 19:30:32 2013 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 D18D121F8EFC for ; Mon, 18 Mar 2013 19:30:32 -0700 (PDT) X-Quarantine-ID: <9AsFOTMNj11d> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: ...t-schaad-pkix-rfc2875-bis\342\200\213.all@tools.ie[...] X-Spam-Flag: NO X-Spam-Score: -95.061 X-Spam-Level: X-Spam-Status: No, score=-95.061 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.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 9AsFOTMNj11d for ; Mon, 18 Mar 2013 19:30:32 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6021F8EFD for ; Mon, 18 Mar 2013 19:30:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=SZPPsNGVqzRU2Kfr/EQZEviBGFRt6m9QBBYk0vl2rOqmHY/FB7OySI9MWCb44mu7z1jNpzTPJg9Xr+CS0eU5IzLwCTp7rkAjzq1cX364freFkDS/PNFjjvQ9Le9CJN+p; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; Received: (qmail 21529 invoked from network); 19 Mar 2013 03:30:29 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Mar 2013 03:30:29 +0100 Message-ID: <5147CDBE.5010809@gondrom.org> Date: Tue, 19 Mar 2013 10:30:22 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-schaad-pkix-rfc2875-bis​.all@tools.ietf.org X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------050603000603070804000509" Cc: iesg@ietf.org Subject: [apps-discuss] AppsDir review of draft-schaad-pkix-rfc2875-bis-07 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, 19 Mar 2013 02:30:32 -0000 This is a multi-part message in MIME format. --------------050603000603070804000509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-schaad-pkix-rfc2875-bis-07 Title: Constrained Application Protocol (CoAP) Reviewer: Tobias Gondrom Review Date: 18.03.2013 Summary: This draft is good work and almost ready for publication as Standards Track RFC Please clean up a number of spelling errors, mostly in section 1, a few downward refs in the idnits and one minor question. Comments/Questions: - section 4.1. ASN.1 Encoding This question may be outdated, but would it be worth to mention in the section to which ASN.1 version the spec is conform? - Nits: section 1: s/Among the responsibilities of a Certificate Authority in issuing a certificates/Among the responsibilities of a Certificate Authority in issuing certificates s/ and that it verify that/ and that it verifies that s/requester of the certificate is call/requester of the certificate is called s/Two methods use the the key agreement process/Two methods use the key agreement process (there might be more...) Reference Errors: ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 6234 Best regards, Tobias --------------050603000603070804000509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-schaad-pkix-rfc2875-bis-07
Title: Constrained Application Protocol (CoAP)
Reviewer: Tobias Gondrom
Review Date: 18.03.2013

Summary: This draft is good work and almost ready for publication as Standards Track RFC

Please clean up a number of spelling errors, mostly in section 1, a few downward refs in the idnits and one minor question.

Comments/Questions:
- section 4.1.  ASN.1 Encoding
This question may be outdated, but would it be worth to mention in the section to which ASN.1 version the spec is conform?

- Nits:
section 1:
s/Among the responsibilities of a Certificate Authority in issuing a certificates/Among the responsibilities of a Certificate Authority in issuing certificates
s/ and that it verify that/ and that it verifies that
s/requester of the certificate is call/requester of the certificate is called
s/Two methods use the the key agreement process/Two methods use the key agreement process
(there might be more...)


Reference Errors:
  ** Downref: Normative reference to an Informational RFC: RFC 2104

  ** Downref: Normative reference to an Informational RFC: RFC 2986

  ** Downref: Normative reference to an Informational RFC: RFC 6234


Best regards, Tobias


 --------------050603000603070804000509-- From hannes.tschofenig@gmx.net Tue Mar 19 06:54:56 2013 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 B23FC21F8B51; Tue, 19 Mar 2013 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.565 X-Spam-Level: X-Spam-Status: No, score=-101.565 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_46=1, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, 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 LVs7Rp91ksgL; Tue, 19 Mar 2013 06:54:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1E621F8B3B; Tue, 19 Mar 2013 06:54:55 -0700 (PDT) Received: from 3capp-gmx-bs53.server.lan ([172.19.170.137]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0ME0kj-1UUqMT1SFr-00HORc; Tue, 19 Mar 2013 14:54:54 +0100 Received: from [194.251.119.196] by 3capp-gmx-bs53.server.lan with HTTP; Tue Mar 19 14:54:54 CET 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ietf@ietf.org Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Mar 2013 14:54:54 +0100 (CET) Importance: normal Sensitivity: Normal In-Reply-To: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:In3SBqOT23iP/JllAptlj5yIFF16E84vFey0In0DUNR jNToXLG2iYZpbeq36WWZa4bwmEBd0FJ76SWELeayzitaHOJqQp 0qAV2y5B+UcVEi7wouYaApJ7Znh0ECy07Sn0Qosh7q1fsakeEt DchRcWuG8eijATpXvPB6/KzKfnXRTDA2dck5lFAQURWkci0rrT yn7XnIEVVlq8H7UszKIool0qoYSF4cp1KCNR+TU2igUnYgYUYj /+0gHs7X+OWsZHscmuglgmGZZAvWH0KQeCQzQB/XnIIAqKcl4n u1UDMI= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] =?utf-8?q?Last_Call=3A_=3Cdraft-ietf-appsawg-webfi?= =?utf-8?q?nger-10=2Etxt=3E_=28WebFinger=29_to=09Proposed_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, 19 Mar 2013 13:54:56 -0000

Hi all,

I was hoping that some of the remarks tha= t I provided last year (e.g., http://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg08965.html) would help to clarify the content of the document. Tha= t didn't quite happen...

In earlier versions of the document I= had the impression that the acct: URI scheme always had to be used as inpu= t to the lookup process but as Section 4.5 explains this is not necessary. = The resource parameter may contain other URIs as well. Section 4.5 does not= give a lot of description of when certain URIs are utilized.

For= example, in Section 3.1 the example talks about a user receiving an email = from bob@examle.com and this email address is then used by WebFinger but th= e request example shows an acct: URI scheme (rather than a mailto URI). It = seems that there is the unstated assumption (at least in that example) that= the mailto URI is the same as the acct: URI, which of course isn't nec= essarily the case. I believe it would be good to state these assumptions to= avoid confusing the reader.

Think about it: If you receive a SIP= URI (which also has an email alike structure with a username @ domain part= ) that does not mean either that you can use this as an email address eithe= r. In some rare cases you might.

If you bel= ieve that everyone would get the difference anyway (because the URI scheme = determines the semantic of the identifier) then have a look at the Google W= ebFinger page (see http://code.google.com/p/webfinger/). At least these guy= s don't understand the difference either.

In general, I am wo= ndering whether there are additional assumptions implied about the URI sche= me associated with the identifier in the lookup mechanism. For example, the= text in Section 3.3 talks about email client configuration and it seems th= at the requestor is interested in receiving information about the email con= figuration based on the resource=3Dmailto... URI scheme usage. If I use a d= ifferent URI scheme (like a aaa: URI scheme) would my response look differe= nt?

Then, there is a question about the lack of privacy considerat= ions in the document.

The usage of the WebFinger mechanism requir= es the requestor to have access to the full username@domain identifier. Whi= le this may be OK in some cases when the response relates very much to the = specific user account it may be a problem in other cases. For example, in t= he OAuth case there is the idea that the user identifier may be hidden from= the relying party but you have just required that identifier to be provide= d to the relying party to start the entire OAuth exchange (in the discovery= ).

The example in Section 3.1 returns information that relates to = the specific username and therefore it makes sense to provide the username = part of the identifier to the service that constructs the query. For the Op= enID Connect discovery procedure described in Section 3.2 I wonder whether = this is always desirable.

Could you expand the description a bit t= o explain why the relying party in this case has to obtain the username par= t as well? The returned information does not seem to be specific to a certa= in user. It is the server configuration. It would be nice if the configurat= ion of an identity provider software (e.g., OpenID Connect) is not differen= t for every user.

I believe it is just fair to ask for a warning = to be added to the security consideration section indicating that WebFinger= may have an impact on your privacy expectation since it shares information= with the relying party that other mechanisms do not provide. So, if you th= ink that this just works like other discovery mechanisms the IETF had worke= d on in the past then you might be surprised.

I would even volunt= eer to provide text but I fear that you are not going to like it.

Ciao
Hannes
Gesendet: M= ontag, 04. März 2013 um 21:24 Uhr
Von: "= The IESG" <iesg-secretary@ietf.org>
An: = ;IANA <drafts-lastcall@icann.org>
Cc: apps-d= iscuss@ietf.org
Betreff: [apps-discuss] Last Call:= <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standa= rd

The IESG has = received a request from the Applications Area Working Group
WG (appsaw= g) to consider the following document:
- 'WebFinger'
&l= t;draft-ietf-appsawg-webfinger-10.txt> as Proposed Standard

T= he IESG plans to make a decision in the next few weeks, and solicits
f= inal comments on this action. Please send substantive comments to the
= ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the
b= eginning of the Subject line to allow automated sorting.

Abstrac= t


This specification defines the WebFinger protocol, wh= ich can be used
to discover information about people or other entit= ies on the
Internet using standard HTTP methods. WebFinger discove= rs
information for a URI that might not be usable as a locator
= otherwise, such as account or email URIs.




= The file can be obtained via
http://datatracker.ietf.= org/doc/draft-ietf-appsawg-webfinger/

IESG discussion can be= tracked via
http://datatracker.ietf.org/doc/d= raft-ietf-appsawg-webfinger/ballot/


No IPR declaration= s have been submitted directly on this I-D.


______________= _________________________________
apps-discuss mailing list
apps-= discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-disc= uss


From enrico.marocco@telecomitalia.it Tue Mar 19 08:47:36 2013 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 DA8A121F8EE1 for ; Tue, 19 Mar 2013 08:47:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: ...pps-discuss@ietf.org>,\n\t<\342\200\213draft-ietf-xr[...] X-Spam-Flag: NO X-Spam-Score: -101.569 X-Spam-Level: X-Spam-Status: No, score=-101.569 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, 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 LtgVXmmCMOz7 for ; Tue, 19 Mar 2013 08:47:36 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id B3E7E21F8EDF for ; Tue, 19 Mar 2013 08:47:35 -0700 (PDT) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 19 Mar 2013 16:47:32 +0100 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.19.9.235) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 19 Mar 2013 16:47:31 +0100 Message-ID: <51488893.4080202@telecomitalia.it> Date: Tue, 19 Mar 2013 16:47:31 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , <​draft-ietf-xrblock-rtcp-xr-decodability.all@tools.ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090900030108020504020301" X-TI-Disclaimer: Disclaimer1 Subject: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-decodability-09 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, 19 Mar 2013 15:47:37 -0000 --------------ms090900030108020504020301 Content-Type: text/plain; charset=UTF-8 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-xrblock-rtcp-xr-decodability-09 Title: RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics reporting Reviewer: Enrico Marocco Review Date: 2013-03-19 IETF Last Call Date: Unknown IESG Telechat Date: Unknown Summary: This draft is ready for publication as a Standards Track RFC. =46rom an APPS point of view there no issues with this document, but a bunch of nits the RFC Editor would have spotted anyway. Nits: General note: ETSI TR 101 290 is mentioned in several places throughout the document. It should be replaced with the actual reference ([ETSI]). Abstract: The last sentence is really hard to read. I'm not sure I entirely understand what it means, so I'll let it up to the authors to propose a better wording. S. 3, "Reserved" definition: s/senders ignored/senders and ignored/ --------------ms090900030108020504020301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC 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 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAzMTkx NTQ3MzFaMCMGCSqGSIb3DQEJBDEWBBQrIggYWQPAGU+0G5NFYxgI1egj5zBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEABD4npffyYxNed4NNVmLHOIN3NNyU2utWsmtFXTP0 5ruEHSCmT4pMvqdcQwJJ9G8EQx0jd2H6tE7g7DSPXfax56Kkzi/qKW8CiWFvSiECamM89U2i ThnThW8nv9bwlrjwfp3YiugMV4aJ8UXW1OM3IZv/Au58+E77mwM1Zt0Gkr+9RimRgvNuEcmK DI3mBqk8YxefVzUSluZaWYZVpl01OJ4XRFCniE2/HK+hViz/WVOMkwutxJHypCLw+b779P/E FId4SNsUNQVRu3GU0wFYn/tAOERWWh5YBHZHEYI6/rXLMo3q8uWYvA8atTu6pEhMGGwb2sSP vzNKge6n4hdOgQAAAAAAAA== --------------ms090900030108020504020301-- From laurentwalter.goix@telecomitalia.it Tue Mar 19 09:03:29 2013 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 D404511E80A5; Tue, 19 Mar 2013 09:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Jhn8X6jKHATt; Tue, 19 Mar 2013 09:03:29 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id EEEC011E80A4; Tue, 19 Mar 2013 09:03:27 -0700 (PDT) Content-Type: multipart/mixed; boundary="_93e49596-2ac1-406f-86ed-24ce46fe7460_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 19 Mar 2013 17:03:26 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 19 Mar 2013 17:03:26 +0100 From: Goix Laurent Walter To: Hannes Tschofenig , "ietf@ietf.org" Date: Tue, 19 Mar 2013 17:03:22 +0100 Thread-Topic: [apps-discuss] Last Call: (WebFinger) to Proposed Standard Thread-Index: Ac4kqV8zPtGIPZ0sTiO0onBkg3e+5wAEVK/g Message-ID: References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] R: Last Call: (WebFinger) 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, 19 Mar 2013 16:03:30 -0000 --_93e49596-2ac1-406f-86ed-24ce46fe7460_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C5743EGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C5743EGRFMBX704BA02_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gaGFubmVzLCBhbGwsDQpbc25pcF0NClRoZSB1c2FnZSBvZiB0aGUgV2ViRmluZ2VyIG1l Y2hhbmlzbSByZXF1aXJlcyB0aGUgcmVxdWVzdG9yIHRvIGhhdmUgYWNjZXNzIHRvIHRoZSBmdWxs IHVzZXJuYW1lQGRvbWFpbiBpZGVudGlmaWVyLiBXaGlsZSB0aGlzIG1heSBiZSBPSyBpbiBzb21l IGNhc2VzIHdoZW4gdGhlIHJlc3BvbnNlIHJlbGF0ZXMgdmVyeSBtdWNoIHRvIHRoZSBzcGVjaWZp YyB1c2VyIGFjY291bnQgaXQgbWF5IGJlIGEgcHJvYmxlbSBpbiBvdGhlciBjYXNlcy4gRm9yIGV4 YW1wbGUsIGluIHRoZSBPQXV0aCBjYXNlIHRoZXJlIGlzIHRoZSBpZGVhIHRoYXQgdGhlIHVzZXIg aWRlbnRpZmllciBtYXkgYmUgaGlkZGVuIGZyb20gdGhlIHJlbHlpbmcgcGFydHkgYnV0IHlvdSBo YXZlIGp1c3QgcmVxdWlyZWQgdGhhdCBpZGVudGlmaWVyIHRvIGJlIHByb3ZpZGVkIHRvIHRoZSBy ZWx5aW5nIHBhcnR5IHRvIHN0YXJ0IHRoZSBlbnRpcmUgT0F1dGggZXhjaGFuZ2UgKGluIHRoZSBk aXNjb3ZlcnkpLg0KDQpUaGUgZXhhbXBsZSBpbiBTZWN0aW9uIDMuMSByZXR1cm5zIGluZm9ybWF0 aW9uIHRoYXQgcmVsYXRlcyB0byB0aGUgc3BlY2lmaWMgdXNlcm5hbWUgYW5kIHRoZXJlZm9yZSBp dCBtYWtlcyBzZW5zZSB0byBwcm92aWRlIHRoZSB1c2VybmFtZSBwYXJ0IG9mIHRoZSBpZGVudGlm aWVyIHRvIHRoZSBzZXJ2aWNlIHRoYXQgY29uc3RydWN0cyB0aGUgcXVlcnkuIEZvciB0aGUgT3Bl bklEIENvbm5lY3QgZGlzY292ZXJ5IHByb2NlZHVyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIg SSB3b25kZXIgd2hldGhlciB0aGlzIGlzIGFsd2F5cyBkZXNpcmFibGUuDQoNCkNvdWxkIHlvdSBl eHBhbmQgdGhlIGRlc2NyaXB0aW9uIGEgYml0IHRvIGV4cGxhaW4gd2h5IHRoZSByZWx5aW5nIHBh cnR5IGluIHRoaXMgY2FzZSBoYXMgdG8gb2J0YWluIHRoZSB1c2VybmFtZSBwYXJ0IGFzIHdlbGw/ IFRoZSByZXR1cm5lZCBpbmZvcm1hdGlvbiBkb2VzIG5vdCBzZWVtIHRvIGJlIHNwZWNpZmljIHRv IGEgY2VydGFpbiB1c2VyLiBJdCBpcyB0aGUgc2VydmVyIGNvbmZpZ3VyYXRpb24uIEl0IHdvdWxk IGJlIG5pY2UgaWYgdGhlIGNvbmZpZ3VyYXRpb24gb2YgYW4gaWRlbnRpdHkgcHJvdmlkZXIgc29m dHdhcmUgKGUuZy4sIE9wZW5JRCBDb25uZWN0KSBpcyBub3QgZGlmZmVyZW50IGZvciBldmVyeSB1 c2VyLg0KDQpbd2FsdGVyXSBmb3IgaG9zdC13aWRlIGluZm9ybWF0aW9uIHlvdSBtYXkgcXVlcnkg Zm9yIC8ud2VsbC1rbm93bi93ZWJmaW5nZXI/cmVzb3VyY2U9aHR0cDovL2V4YW1wbGUuY29tIGFs dGhvdWdoIGl0IGxvb2tzIHF1aXRlIG9kZCB0byBtZSAoYnV0IHRlY2huaWNhbGx5IGZlYXNpYmxl KSBhbmQgY2VydGFpbmx5IGlzbuKAmXQgY2FsbGVkIG91dCBpbiB0aGUgY3VycmVudCB0ZXh0IHRv IGtub3cuIE9yIHlvdSBjb3VsZCAoYmV0dGVyKSByZWx5IG9uIHRoZSBob3N0LW1ldGEgZW5kcG9p bnQgKHJmYzY0MTUpIGFuZCB1c2UgeHJkIG9yIGpyZCByZXByZXNlbnRhdGlvbiwgb3B0aW9uYWxs eSBvdmVyIGh0dHBzIGlmIHlvdSBjYXJlIGFib3V0IHNlY3VyaXR5LiBUaGlzIGlzIHRoZSBhcHBy b2FjaCB3ZSB0b29rIHdpdGhpbiBPTUEgdG8gYXV0b2NvbmZpZ3VyZSB0aGUgY2xpZW50IGJhc2Vk IG9uIHRoZSBwdXJlIGRvbWFpbiBpbmZvcm1hdGlvbiAodGhlIHJwIGRvZXMgbm90IG5lY2Vzc2Fy aWx5IGhhdmUgdGhlIGtub3dsZWRnZSBvZiB0aGUgdXNlcm5hbWUgYW5kIHNob3VsZG7igJl0IGFz ayB0aGUgdXNlciBmb3IgaXQpLiBUaGlzIHdheSB5b3UgY2FuIGRpc2NvdmVyIHRoZSBvYXV0aDIg ZW5kcG9pbnRzIGZvciBleGFtcGxlIGFuZCBnZXQgdGhlIHVzZXIgbG9naW4gb24gaGlzIGZhdm9y aXRlIHBvcnRhbCB0byBvYnRhaW4gaGlzIHRva2VuLg0KDQoNCkkgYmVsaWV2ZSBpdCBpcyBqdXN0 IGZhaXIgdG8gYXNrIGZvciBhIHdhcm5pbmcgdG8gYmUgYWRkZWQgdG8gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb24gc2VjdGlvbiBpbmRpY2F0aW5nIHRoYXQgV2ViRmluZ2VyIG1heSBoYXZlIGFu IGltcGFjdCBvbiB5b3VyIHByaXZhY3kgZXhwZWN0YXRpb24gc2luY2UgaXQgc2hhcmVzIGluZm9y bWF0aW9uIHdpdGggdGhlIHJlbHlpbmcgcGFydHkgdGhhdCBvdGhlciBtZWNoYW5pc21zIGRvIG5v dCBwcm92aWRlLiBTbywgaWYgeW91IHRoaW5rIHRoYXQgdGhpcyBqdXN0IHdvcmtzIGxpa2Ugb3Ro ZXIgZGlzY292ZXJ5IG1lY2hhbmlzbXMgdGhlIElFVEYgaGFkIHdvcmtlZCBvbiBpbiB0aGUgcGFz dCB0aGVuIHlvdSBtaWdodCBiZSBzdXJwcmlzZWQuDQoNCkkgd291bGQgZXZlbiB2b2x1bnRlZXIg dG8gcHJvdmlkZSB0ZXh0IGJ1dCBJIGZlYXIgdGhhdCB5b3UgYXJlIG5vdCBnb2luZyB0byBsaWtl IGl0Lg0KDQpDaWFvDQpIYW5uZXMNCkdlc2VuZGV0OiBNb250YWcsIDA0LiBNw6RyeiAyMDEzIHVt IDIxOjI0IFVocg0KVm9uOiAiVGhlIElFU0ciIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZz4NCkFu OiBJQU5BIDxkcmFmdHMtbGFzdGNhbGxAaWNhbm4ub3JnPg0KQ2M6IGFwcHMtZGlzY3Vzc0BpZXRm Lm9yZw0KQmV0cmVmZjogW2FwcHMtZGlzY3Vzc10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1hcHBz YXdnLXdlYmZpbmdlci0xMC50eHQ+IChXZWJGaW5nZXIpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoN ClRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgQXBwbGljYXRpb25zIEFy ZWEgV29ya2luZyBHcm91cA0KV0cgKGFwcHNhd2cpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg ZG9jdW1lbnQ6DQotICdXZWJGaW5nZXInDQo8ZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0x MC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQoNClRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBk ZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KZmluYWwgY29tbWVu dHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRo ZQ0KaWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTMtMDMtMTguIEV4Y2VwdGlvbmFs bHksIGNvbW1lbnRzIG1heSBiZQ0Kc2VudCB0byBpZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVp dGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxp bmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0DQoNCg0KVGhpcyBzcGVj aWZpY2F0aW9uIGRlZmluZXMgdGhlIFdlYkZpbmdlciBwcm90b2NvbCwgd2hpY2ggY2FuIGJlIHVz ZWQNCnRvIGRpc2NvdmVyIGluZm9ybWF0aW9uIGFib3V0IHBlb3BsZSBvciBvdGhlciBlbnRpdGll cyBvbiB0aGUNCkludGVybmV0IHVzaW5nIHN0YW5kYXJkIEhUVFAgbWV0aG9kcy4gV2ViRmluZ2Vy IGRpc2NvdmVycw0KaW5mb3JtYXRpb24gZm9yIGEgVVJJIHRoYXQgbWlnaHQgbm90IGJlIHVzYWJs ZSBhcyBhIGxvY2F0b3INCm90aGVyd2lzZSwgc3VjaCBhcyBhY2NvdW50IG9yIGVtYWlsIFVSSXMu DQoNCg0KDQoNClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci8NCg0KSUVTRyBkaXNj dXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWFwcHNhd2ctd2ViZmluZ2VyL2JhbGxvdC8NCg0KDQpObyBJUFIgZGVjbGFy YXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlzY3Vz cyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkg c3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29u ZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25l IGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyBy aWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9j dW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1t ZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3Vh IGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg aXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGlu dGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcs IHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1t YWlsLCBUaGFua3MuDQoNCltjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDNAVEku RGlzY2xhaW1lcl1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwg c2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoNCg== --_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C5743EGRFMBX704BA02_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0 cm9uaWNhMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4w Y20gMi4wY20gMi4wY207fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5IZWxsbyBoYW5u ZXMsIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQomcXVvdDtTZWdvZSBVSSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltzbmlwXTwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpUaGUgdXNhZ2Ug b2YgdGhlIFdlYkZpbmdlciBtZWNoYW5pc20gcmVxdWlyZXMgdGhlIHJlcXVlc3RvciB0byBoYXZl IGFjY2VzcyB0byB0aGUgZnVsbCB1c2VybmFtZUBkb21haW4gaWRlbnRpZmllci4NCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGlsZSB0aGlzIG1heSBiZSBPSyBpbiBzb21l IGNhc2VzIHdoZW4gdGhlIHJlc3BvbnNlIHJlbGF0ZXMgdmVyeSBtdWNoIHRvIHRoZSBzcGVjaWZp YyB1c2VyIGFjY291bnQgaXQgbWF5IGJlIGEgcHJvYmxlbSBpbiBvdGhlciBjYXNlcy4gRm9yIGV4 YW1wbGUsIGluIHRoZSBPQXV0aCBjYXNlIHRoZXJlIGlzIHRoZSBpZGVhDQogdGhhdCB0aGUgdXNl ciBpZGVudGlmaWVyIG1heSBiZSBoaWRkZW4gZnJvbSB0aGUgcmVseWluZyBwYXJ0eSBidXQgeW91 IGhhdmUganVzdCByZXF1aXJlZCB0aGF0IGlkZW50aWZpZXIgdG8gYmUgcHJvdmlkZWQgdG8gdGhl IHJlbHlpbmcgcGFydHkgdG8gc3RhcnQgdGhlIGVudGlyZSBPQXV0aCBleGNoYW5nZSAoaW4gdGhl IGRpc2NvdmVyeSkuPGJyPg0KPGJyPg0KVGhlIGV4YW1wbGUgaW4gU2VjdGlvbiAzLjEgcmV0dXJu cyBpbmZvcm1hdGlvbiB0aGF0IHJlbGF0ZXMgdG8gdGhlIHNwZWNpZmljIHVzZXJuYW1lIGFuZCB0 aGVyZWZvcmUgaXQgbWFrZXMgc2Vuc2UgdG8gcHJvdmlkZSB0aGUgdXNlcm5hbWUgcGFydCBvZiB0 aGUgaWRlbnRpZmllciB0byB0aGUgc2VydmljZSB0aGF0IGNvbnN0cnVjdHMgdGhlIHF1ZXJ5LiBG b3IgdGhlIE9wZW5JRCBDb25uZWN0IGRpc2NvdmVyeSBwcm9jZWR1cmUgZGVzY3JpYmVkIGluDQog U2VjdGlvbiAzLjIgSSB3b25kZXIgd2hldGhlciB0aGlzIGlzIGFsd2F5cyBkZXNpcmFibGUuPGJy Pg0KPGJyPg0KQ291bGQgeW91IGV4cGFuZCB0aGUgZGVzY3JpcHRpb24gYSBiaXQgdG8gZXhwbGFp biB3aHkgdGhlIHJlbHlpbmcgcGFydHkgaW4gdGhpcyBjYXNlIGhhcyB0byBvYnRhaW4gdGhlIHVz ZXJuYW1lIHBhcnQgYXMgd2VsbD8gVGhlIHJldHVybmVkIGluZm9ybWF0aW9uIGRvZXMgbm90IHNl ZW0gdG8gYmUgc3BlY2lmaWMgdG8gYSBjZXJ0YWluIHVzZXIuIEl0IGlzIHRoZSBzZXJ2ZXIgY29u ZmlndXJhdGlvbi4gSXQgd291bGQgYmUgbmljZSBpZiB0aGUgY29uZmlndXJhdGlvbg0KIG9mIGFu IGlkZW50aXR5IHByb3ZpZGVyIHNvZnR3YXJlIChlLmcuLCBPcGVuSUQgQ29ubmVjdCkgaXMgbm90 IGRpZmZlcmVudCBmb3IgZXZlcnkgdXNlci4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlt3YWx0ZXJdIGZvciBob3N0LXdpZGUg aW5mb3JtYXRpb24geW91IG1heSBxdWVyeSBmb3IgLy53ZWxsLWtub3duL3dlYmZpbmdlcj9yZXNv dXJjZT1odHRwOi8vZXhhbXBsZS5jb20gYWx0aG91Z2ggaXQgbG9va3MgcXVpdGUgb2RkIHRvIG1l IChidXQNCiB0ZWNobmljYWxseSBmZWFzaWJsZSkgYW5kIGNlcnRhaW5seSBpc27igJl0IGNhbGxl ZCBvdXQgaW4gdGhlIGN1cnJlbnQgdGV4dCB0byBrbm93LiBPciB5b3UgY291bGQgKGJldHRlcikg cmVseSBvbiB0aGUgaG9zdC1tZXRhIGVuZHBvaW50IChyZmM2NDE1KSBhbmQgdXNlIHhyZCBvciBq cmQgcmVwcmVzZW50YXRpb24sIG9wdGlvbmFsbHkgb3ZlciBodHRwcyBpZiB5b3UgY2FyZSBhYm91 dCBzZWN1cml0eS4gVGhpcyBpcyB0aGUgYXBwcm9hY2ggd2UgdG9vaw0KIHdpdGhpbiBPTUEgdG8g YXV0b2NvbmZpZ3VyZSB0aGUgY2xpZW50IGJhc2VkIG9uIHRoZSBwdXJlIGRvbWFpbiBpbmZvcm1h dGlvbiAodGhlIHJwIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGhhdmUgdGhlIGtub3dsZWRnZSBvZiB0 aGUgdXNlcm5hbWUgYW5kIHNob3VsZG7igJl0IGFzayB0aGUgdXNlciBmb3IgaXQpLiBUaGlzIHdh eSB5b3UgY2FuIGRpc2NvdmVyIHRoZSBvYXV0aDIgZW5kcG9pbnRzIGZvciBleGFtcGxlIGFuZCBn ZXQgdGhlIHVzZXIgbG9naW4NCiBvbiBoaXMgZmF2b3JpdGUgcG9ydGFsIHRvIG9idGFpbiBoaXMg dG9rZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpJIGJlbGlldmUg aXQgaXMganVzdCBmYWlyIHRvIGFzayBmb3IgYSB3YXJuaW5nIHRvIGJlIGFkZGVkIHRvIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gaW5kaWNhdGluZyB0aGF0IFdlYkZpbmdlciBt YXkgaGF2ZSBhbiBpbXBhY3Qgb24geW91ciBwcml2YWN5IGV4cGVjdGF0aW9uIHNpbmNlIGl0IHNo YXJlcyBpbmZvcm1hdGlvbiB3aXRoIHRoZSByZWx5aW5nIHBhcnR5IHRoYXQgb3RoZXIgbWVjaGFu aXNtcyBkbyBub3QgcHJvdmlkZS4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5TbywgaWYgeW91IHRoaW5rIHRoYXQgdGhpcyBqdXN0IHdvcmtzIGxpa2Ugb3RoZXIgZGlzY292 ZXJ5IG1lY2hhbmlzbXMgdGhlIElFVEYgaGFkIHdvcmtlZCBvbiBpbiB0aGUgcGFzdCB0aGVuIHlv dSBtaWdodCBiZSBzdXJwcmlzZWQuDQo8YnI+DQo8YnI+DQpJIHdvdWxkIGV2ZW4gdm9sdW50ZWVy IHRvIHByb3ZpZGUgdGV4dCBidXQgSSBmZWFyIHRoYXQgeW91IGFyZSBub3QgZ29pbmcgdG8gbGlr ZSBpdC4NCjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDM0Q5 RTUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDsNCm1hcmdpbi1sZWZ0OjcuNXB0O21h cmdpbi10b3A6Ny41cHQ7bWFyZ2luLXJpZ2h0OjMuNzVwdDttYXJnaW4tYm90dG9tOjMuNzVwdDsN CndvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSIgbmFtZT0icXVvdGUiPg0KPGRpdiBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+R2VzZW5kZXQ6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7TW9udGFnLCAwNC4gTcOkcnogMjAxMyB1bSAyMToyNCBVaHI8YnI+DQo8 Yj5Wb246PC9iPiZuYnNwOyZxdW90O1RoZSBJRVNHJnF1b3Q7ICZsdDtpZXNnLXNlY3JldGFyeUBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5Bbjo8L2I+Jm5ic3A7SUFOQSAmbHQ7ZHJhZnRzLWxhc3RjYWxs QGljYW5uLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7YXBwcy1kaXNjdXNzQGlldGYub3Jn PGJyPg0KPGI+QmV0cmVmZjo8L2I+Jm5ic3A7W2FwcHMtZGlzY3Vzc10gTGFzdCBDYWxsOiAmbHQ7 ZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMC50eHQmZ3Q7IChXZWJGaW5nZXIpIHRvIFBy b3Bvc2VkIFN0YW5kYXJkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgbmFt ZT0icXVvdGVkLWNvbnRlbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxicj4NClRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0 aGUgQXBwbGljYXRpb25zIEFyZWEgV29ya2luZyBHcm91cDxicj4NCldHIChhcHBzYXdnKSB0byBj b25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4NCi0gJ1dlYkZpbmdlcic8YnI+DQom bHQ7ZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMC50eHQmZ3Q7IGFzIFByb3Bvc2VkIFN0 YW5kYXJkPGJyPg0KPGJyPg0KVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRo ZSBuZXh0IGZldyB3ZWVrcywgYW5kIHNvbGljaXRzPGJyPg0KZmluYWwgY29tbWVudHMgb24gdGhp cyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZTxicj4NCmll dGZAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDEzLTAzLTE4LiBFeGNlcHRpb25hbGx5LCBj b21tZW50cyBtYXkgYmU8YnI+DQpzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0 aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlPGJyPg0KYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0 IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuPGJyPg0KPGJyPg0KQWJzdHJhY3Q8YnI+ DQo8YnI+DQo8YnI+DQpUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgV2ViRmluZ2VyIHBy b3RvY29sLCB3aGljaCBjYW4gYmUgdXNlZDxicj4NCnRvIGRpc2NvdmVyIGluZm9ybWF0aW9uIGFi b3V0IHBlb3BsZSBvciBvdGhlciBlbnRpdGllcyBvbiB0aGU8YnI+DQpJbnRlcm5ldCB1c2luZyBz dGFuZGFyZCBIVFRQIG1ldGhvZHMuIFdlYkZpbmdlciBkaXNjb3ZlcnM8YnI+DQppbmZvcm1hdGlv biBmb3IgYSBVUkkgdGhhdCBtaWdodCBub3QgYmUgdXNhYmxlIGFzIGEgbG9jYXRvcjxicj4NCm90 aGVyd2lzZSwgc3VjaCBhcyBhY2NvdW50IG9yIGVtYWlsIFVSSXMuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYTxicj4NCjxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdl ci8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXIvPC9hPjxicj4NCjxicj4NCklFU0cgZGlzY3Vzc2lvbiBj YW4gYmUgdHJhY2tlZCB2aWE8YnI+DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXIvYmFsbG90LyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hcHBzYXdnLXdl YmZpbmdlci9iYWxsb3QvPC9hPjxicj4NCjxicj4NCjxicj4NCk5vIElQUiBkZWNsYXJhdGlvbnMg aGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC48YnI+DQo8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmFw cHMtZGlzY3VzcyBtYWlsaW5nIGxpc3Q8YnI+DQphcHBzLWRpc2N1c3NAaWV0Zi5vcmc8YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vz cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YXBwcy1kaXNjdXNzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ DQo8IS0tDQpzcGFuLkdyYW1FIHttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9 DQotLT4NCjwvc3R5bGU+DQo8dGFibGUgc3R5bGU9IndpZHRoOjYwMHB4OyI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgQXJpYWw7 IGZvbnQtc2l6ZToxMnB4OyBjb2xvcjojMDAwOyB0ZXh0LWFsaWduOiBqdXN0aWZ5IiB3aWR0aD0i Mzk1Ij4NCjxkaXYgYWxpZ249Imp1c3RpZnkiPjxzcGFuIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnk7IGxpbmUtaGVpZ2h0Om5vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpWZXJkYW5hIj5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaQ0KIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8g cmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxwIGFsaWduPSJq dXN0aWZ5Ij48c3BhbiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 OyBsaW5lLWhlaWdodDpub3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPlRo aXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHM8L3NwYW4+PC9pPjxpPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOg0KICA3LjVwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OlZlcmRhbmE7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOzxzcGFu IGNsYXNzPSJHcmFtRSI+aXM8L3NwYW4+Jm5ic3A7PC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToNCiAgNy41cHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTttc28t YW5zaS1sYW5ndWFnZTpFTi1HQiI+Y29uZmlkZW50aWFsDQogYW5kIG1heSBjb250YWluIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlz c2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1 bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUg c2VuZGVyDQogYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTpFTi1HQiI+DQo8L3NwYW4+PC9zcGFuPjwv cD4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFtaWx5OlZlcmRh bmEiPjxpbWcgc3JjPSJjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDNAVEkuRGlz Y2xhaW1lciIgYWx0PSJyaXNwZXR0YSBsJ2FtYmllbnRlIiB3aWR0aD0iMjYiIGhlaWdodD0iNDAi PlJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6gg bmVjZXNzYXJpby48L3NwYW4+PC9iPg0KPHA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A09A9E0A4B9C654E8672D1DC003633AE53A7C5743EGRFMBX704BA02_-- --_93e49596-2ac1-406f-86ed-24ce46fe7460_ 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= --_93e49596-2ac1-406f-86ed-24ce46fe7460_-- From superuser@gmail.com Tue Mar 19 10:39:01 2013 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 B9ADE21F8B96 for ; Tue, 19 Mar 2013 10:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CVN1fyM6fatR for ; Tue, 19 Mar 2013 10:39:01 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB3821F8CDD for ; Tue, 19 Mar 2013 10:39:00 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm11so4685283wib.5 for ; Tue, 19 Mar 2013 10:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=tU6d3FBw1AuKyJWVpG/wuBW1ft6eAxAmoFnlxWNR40Q=; b=fjUV+jS+mpj14qDaz/yAEKuWkKSLxIZov1owmtmSoJSeNmSGjVDpp2IH74jT8iQynZ Au4N3w6uueFoA4IgI8tYneIFk1ieJOUNPZjjSmTkevfG3FPp09l04KoJexXZn1psq1Jd gK0s9Lo5XfTp3QE0TT/HW/vkO24V/nSCm1RjIRv66gWmr/H7+5ygMob09tOvUHB15vLg PfyRQ2rOA5jORuJ/COB8Kp11gORYYnTPQEWjkXbN6bnJTrpf1Uk1M1+/bQpi+gzaDvsW RHaSHY+7LW1H1XJvY+oyxG/ZZOsIGpHZv1IYK6yc6CnmyVu/U6FaRQrwv39iFnTzvB1x AKeQ== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr4906296wib.33.1363714739387; Tue, 19 Mar 2013 10:38:59 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Tue, 19 Mar 2013 10:38:59 -0700 (PDT) Date: Tue, 19 Mar 2013 10:38:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f3ba6e39dc82104d84a9409 Subject: [apps-discuss] IETF 86 APPSAWG minutes available 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, 19 Mar 2013 17:39:01 -0000 --e89a8f3ba6e39dc82104d84a9409 Content-Type: text/plain; charset=ISO-8859-1 A draft version of the minutes from our meeting at IETF 86 in Orlando are now available online: http://www.ietf.org/proceedings/86/minutes/minutes-86-appsawg Please review them and let us know if we've missed anything. -MSK, APPSAWG co-chair --e89a8f3ba6e39dc82104d84a9409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A draft version of the minutes from our meeting = at IETF 86 in Orlando are now available online:

http://www.ietf.org/p= roceedings/86/minutes/minutes-86-appsawg

Please review them and let us know if we've missed anything.<= br>
-MSK, APPSAWG co-chair

--e89a8f3ba6e39dc82104d84a9409-- From mnot@mnot.net Tue Mar 19 19:03:51 2013 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 19D8921F8675 for ; Tue, 19 Mar 2013 19:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.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 b6wOhu-QvL28 for ; Tue, 19 Mar 2013 19:03:50 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 4982021F8626 for ; Tue, 19 Mar 2013 19:03:45 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.42.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 04F6D509B6; Tue, 19 Mar 2013 22:03:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <1AD639E1-35D3-4F17-8C4C-FFD2CC2CAE5C@me.com> Date: Wed, 20 Mar 2013 13:03:40 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1AD639E1-35D3-4F17-8C4C-FFD2CC2CAE5C@me.com> To: algermissen1971 X-Mailer: Apple Mail (2.1499) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Deprecation mechanism in JSON HOme Documents 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, 20 Mar 2013 02:03:51 -0000 Hi Jan, On 25/02/2013, at 7:04 PM, algermissen1971 = wrote: > Hi Mark, >=20 > in your latest draft of JSON Homep[1] you define a deprecation = mechanism that allows a provider to provide a hint to a consumer that a = certain described resource is in a deprecation period. >=20 > As designed now, this mechanism cannot be used to hint the deprecation = of a certain provided media type: >=20 > Suppose I have=20 >=20 >=20 > "http://example.org/rel/widgets": { > "href": "/widgets/", > "hints": { > "representations": ["application/widgetlist"] > } > } >=20 > and at some point, I have to evolve the media type in an incompatible = way, yielding a new media type 'application/special-new-widgetlist'. To = support both, new and old clients, I'd let the types coexist: >=20 > "http://example.org/rel/widgets": { > "href": "/widgets/", > "hints": { > "representations": = ["application/widgetlist","application/special-new-widgetlist"], > } > } Yes... > As time passes and clients pick up the shiny new media type, a point = is reached where I want to hint older clients that an upgrade is in = order. I'd like to deprecate the availability of the older media type = 'application/widgetlist'. >=20 > However ... that is impossible right now since 'deprecated' only = applies to the resource as a whole - which I deliberately do *not* want = to change or remove. >=20 > What are your thoughts? Is there a certain design decision behind your = approach that I am not seeing? Nope, just started to get deprecation in. Will think on this, thanks... >=20 > What do you think of augmenting the deprecation mechanism to something = like: >=20 > "http://example.org/rel/widgets": { > "href": "/widgets/", > "hints": { > "representations": = ["application/widgetlist","application/special-new-widgetlist"], > "deprecated-representations" : ["application/widgetlist"] > } > } That'd be one way to do it. However, I suspect we're eventually going to = want to put more information about representations in, so it could be = metadata, e.g., "hints": { "representations": {=20 "application/widgetlist": { "deprecated": true }, "application/special-new-widgetlist": { } } } -- Mark Nottingham http://www.mnot.net/ From jasnell@gmail.com Tue Mar 19 19:05:57 2013 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 D803121F8C08 for ; Tue, 19 Mar 2013 19:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gOr7RagxwNEH for ; Tue, 19 Mar 2013 19:05:57 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2658A21F871C for ; Tue, 19 Mar 2013 19:05:57 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id fa15so788832vbb.11 for ; Tue, 19 Mar 2013 19:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/IVbgmxUDCXV4EHilNldBxDHCQBQc9WAiVj2HDDPleE=; b=nO/drB2pGVm70KPoXD1qVBZy2jfXJj7ezT/5egwsOamdEky8MeVPagyow6nb+MnpO+ YGCdoLBEnmX0cqdgyQfBuq310k2y+P8sso1leqmmROOGvFj1G/CW8n9276/moCm2JldE eX/+kZKBNk74lfWGkATsVoh/adJCtfGdVyfffiTz32p/64Xsd5MVGwKju1wez+wHzrW3 lwNXQBNmET9M0mjyzAEP3xNzvgUhdzlAAGzR+DJI2/o2M2KLbwiSW21LcB7/E8fJ+Qwo DuLvctN4NcB4KybX26vX4wUY5by+K6buBz92c0bB79kriQdhcg+JE8E6llNKp6+GRXxo Q49g== X-Received: by 10.52.25.8 with SMTP id y8mr4759646vdf.88.1363745156644; Tue, 19 Mar 2013 19:05:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.32.228 with HTTP; Tue, 19 Mar 2013 19:05:35 -0700 (PDT) In-Reply-To: References: <1AD639E1-35D3-4F17-8C4C-FFD2CC2CAE5C@me.com> From: James M Snell Date: Tue, 19 Mar 2013 19:05:35 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=bcaec501620fa0496604d851a93c Cc: algermissen1971 , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Deprecation mechanism in JSON HOme Documents 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, 20 Mar 2013 02:05:58 -0000 --bcaec501620fa0496604d851a93c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This variation looks to be the most useful. On Tue, Mar 19, 2013 at 7:03 PM, Mark Nottingham wrote: > =E2=80=8B[snip]=E2=80=8B > > That'd be one way to do it. However, I suspect we're eventually going to > want to put more information about representations in, so it could be > metadata, e.g., > > "hints": { > "representations": { > "application/widgetlist": { > "deprecated": true > }, > "application/special-new-widgetlist": { > } > } > } > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --bcaec501620fa0496604d851a93c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This variation looks to be the most useful.=C2=A0<= /div>

On Tue, Mar = 19, 2013 at 7:03 PM, Mark Nottingham <mnot@mnot.net> wrote:
=E2=80=8B[snip]=E2=80=8B

That'd be one way to do it. However, I suspect we're eventual= ly going to want to put more information about representations in, so it co= uld be metadata, e.g.,

=C2=A0"hints": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "representations": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "application/w= idgetlist": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "deprecated": true
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "application/s= pecial-new-widgetlist": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}


--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



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

--bcaec501620fa0496604d851a93c-- From algermissen1971@me.com Wed Mar 20 00:01:44 2013 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 9422021F8B74 for ; Wed, 20 Mar 2013 00:01:44 -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 eWePeS2Tp5y1 for ; Wed, 20 Mar 2013 00:01:44 -0700 (PDT) Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtp002.mac.com [17.158.232.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10C21F8BF6 for ; Wed, 20 Mar 2013 00:01:40 -0700 (PDT) Received: from [172.20.10.2] ([80.187.102.26]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MJY00L9R656MD60@nk11p03mm-asmtp002.mac.com> for apps-discuss@ietf.org; Wed, 20 Mar 2013 07:01:40 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-20_03:2013-03-19, 2013-03-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303190313 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: algermissen1971 In-reply-to: Date: Wed, 20 Mar 2013 08:01:39 +0100 Content-transfer-encoding: quoted-printable Message-id: References: <1AD639E1-35D3-4F17-8C4C-FFD2CC2CAE5C@me.com> To: James M Snell X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Wed, 20 Mar 2013 11:46:08 -0700 Cc: Mark Nottingham , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Deprecation mechanism in JSON HOme Documents 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, 20 Mar 2013 07:01:44 -0000 On 20.03.2013, at 03:05, James M Snell wrote: > This variation looks to be the most useful.=20 +1 Just did not want to be too destructive on Marks' original design :-) Jan >=20 > On Tue, Mar 19, 2013 at 7:03 PM, Mark Nottingham = wrote: > =E2=80=8B[snip]=E2=80=8B >=20 > That'd be one way to do it. However, I suspect we're eventually going = to want to put more information about representations in, so it could be = metadata, e.g., >=20 > "hints": { > "representations": { > "application/widgetlist": { > "deprecated": true > }, > "application/special-new-widgetlist": { > } > } > } >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From rachel.huang@huawei.com Tue Mar 19 19:05:23 2013 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 983AA21F8DE3; Tue, 19 Mar 2013 19:05:23 -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 mZhrXAYTWVcW; Tue, 19 Mar 2013 19:05:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7C221F8DEF; Tue, 19 Mar 2013 19:05:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQV59014; Wed, 20 Mar 2013 02:05:20 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 20 Mar 2013 02:04:28 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 20 Mar 2013 02:05:20 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.126]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Wed, 20 Mar 2013 10:05:11 +0800 From: "Huangyihong (Rachel)" To: Enrico Marocco , "apps-discuss@ietf.org" , "??tools.ietf.org" Thread-Topic: APPSDIR review of draft-ietf-xrblock-rtcp-xr-decodability-09 Thread-Index: AQHOJLkfDBN/tRYAdkqxzB/KMwHJtpitw0tg Date: Wed, 20 Mar 2013 02:05:10 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4572CB56@nkgeml501-mbs.china.huawei.com> References: <51488893.4080202@telecomitalia.it> In-Reply-To: <51488893.4080202@telecomitalia.it> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 20 Mar 2013 11:46:19 -0700 Cc: "xrblock@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-decodability-09 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, 20 Mar 2013 02:05:23 -0000 RGVhciBFbnJpY28sDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFBsZWFzZSBzZWUgbXkgcmVw bGllcyBpbmxpbmUuDQoNCkJlc3QgUmVnYXJkcyENClJhY2hlbA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRW5yaWNvIE1hcm9jY28gW21haWx0bzplbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0XSANClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE5LCAyMDEzIDExOjQ4IFBN DQpUbzogYXBwcy1kaXNjdXNzQGlldGYub3JnOyA/P3Rvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBB UFBTRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxpdHkt MDkNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVj dG9yYXRlIHJldmlld2VyIGZvcg0KdGhpcyBkcmFmdCAoZm9yIGJhY2tncm91bmQgb24gYXBwc2Rp ciwgcGxlYXNlIHNlZQ0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93 aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZSApLg0KDQpQbGVhc2UgcmVzb2x2ZSB0aGVz ZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMNCnlvdSBt YXkgcmVjZWl2ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQg c2hlcGhlcmQNCm9yIEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0 Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItZGVjb2RhYmlsaXR5LTA5 DQpUaXRsZTogUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIEV4dGVuZGVkIFJlcG9ydCAoWFIp IEJsb2NrIGZvciBNUEVHMg0KVHJhbnNwb3J0IFN0cmVhbSAoVFMpIFByb2dyYW0gU3BlY2lmaWMg SW5mb3JtYXRpb24gKFBTSSkgSW5kZXBlbmRlbnQNCkRlY29kYWJpbGl0eSBTdGF0aXN0aWNzIE1l dHJpY3MgcmVwb3J0aW5nDQpSZXZpZXdlcjogRW5yaWNvIE1hcm9jY28NClJldmlldyBEYXRlOiAy MDEzLTAzLTE5DQpJRVRGIExhc3QgQ2FsbCBEYXRlOiBVbmtub3duDQpJRVNHIFRlbGVjaGF0IERh dGU6IFVua25vd24NCg0KU3VtbWFyeTogVGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRp b24gYXMgYSBTdGFuZGFyZHMgVHJhY2sgUkZDLg0KRnJvbSBhbiBBUFBTIHBvaW50IG9mIHZpZXcg dGhlcmUgbm8gaXNzdWVzIHdpdGggdGhpcyBkb2N1bWVudCwgYnV0IGENCmJ1bmNoIG9mIG5pdHMg dGhlIFJGQyBFZGl0b3Igd291bGQgaGF2ZSBzcG90dGVkIGFueXdheS4NCg0KTml0czoNCg0KR2Vu ZXJhbCBub3RlOiBFVFNJIFRSIDEwMSAyOTAgaXMgbWVudGlvbmVkIGluIHNldmVyYWwgcGxhY2Vz IHRocm91Z2hvdXQNCnRoZSBkb2N1bWVudC4gSXQgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggdGhl IGFjdHVhbCByZWZlcmVuY2UgKFtFVFNJXSkuDQoNCltSYWNoZWxdOiBPa2F5Lg0KDQpBYnN0cmFj dDogVGhlIGxhc3Qgc2VudGVuY2UgaXMgcmVhbGx5IGhhcmQgdG8gcmVhZC4gSSdtIG5vdCBzdXJl IEkNCmVudGlyZWx5IHVuZGVyc3RhbmQgd2hhdCBpdCBtZWFucywgc28gSSdsbCBsZXQgaXQgdXAg dG8gdGhlIGF1dGhvcnMgdG8NCnByb3Bvc2UgYSBiZXR0ZXIgd29yZGluZy4NCg0KW1JhY2hlbF06 IEhvdyBhYm91dCBjaGFuZ2luZyB0byB0aGUgZm9sbG93aW5nIHNlbnRlbmNlPw0KDQoiDQpUaGlz IGRvY3VtZW50IGRlZmluZXMgYW4gUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIEV4dGVuZGVk IFJlcG9ydCAoWFIpIEJsb2NrIHRoYXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgb2YgTVBFRzIgVFMg UHJvZ3JhbSBTcGVjaWZpYyBJbmZvcm1hdGlvbiAoUFNJKSBJbmRlcGVuZGVudCBkZWNvZGFiaWxp dHkgc3RhdGlzdGljcyBtZXRyaWNzIGZvciBhcHBsaWNhdGlvbnMgdXNpbmcgdHJhbnNtaXNzaW9u cyBvZiBNUEVHMiBUUyBvdmVyIFJUUC4gDQoNCiINCg0KUy4gMywgIlJlc2VydmVkIiBkZWZpbml0 aW9uOiBzL3NlbmRlcnMgaWdub3JlZC9zZW5kZXJzIGFuZCBpZ25vcmVkLw0KDQpbUmFjaGVsXTog T2theS4NCg== From paulej@packetizer.com Wed Mar 20 17:39:17 2013 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 231AD1F0D1C; Wed, 20 Mar 2013 17:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77khar3730St; Wed, 20 Mar 2013 17:39:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0F71F0CF7; Wed, 20 Mar 2013 17:39:15 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2L0dAs8013274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 20:39:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363826353; bh=Kg7GVYQBKK1XqFdhoP+dhUKJFedpQSpS/e9obnjPZRk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=B6LvmbQyhRY592N3Gos6grC6shCexRbVB8eh4ltR1Do13/uBqbl5jJuvsC+GBDx0U YjNLiEs96lEyz3y8KXr6Uq1MJFP/w/dHc5BB+c031ronCUiLL1UooI5DK+ijYuKZeZ iMkD48PvfMt3uesiiGPZ0jorznjhmPKIY3w9Q5AE= From: "Paul E. Jones" To: "'Dave Cridland'" , , , References: In-Reply-To: Date: Wed, 20 Mar 2013 20:39:26 -0400 Message-ID: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtZfV0Bqg Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 21 Mar 2013 00:39:17 -0000 Dave, My apologies for the belated reply. Please see my comments below. > 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-appsawg-webfinger-11 > Title: Webfinger > Reviewer: Dave Cridland > Review Date: 2013/03/11 > IESG Telechat Date: 2013/03/28 > Summary: Close to ready for publication as standards track; some > comments which suggest a new version may be required and/or technical > discussion needed. >=20 > Minor Comments: >=20 > 1) There's some suggestions that webfinger could be used for email > autoconfig; I suspect this is at best going to cause confusion > especially when there's a BOF tomorrow on the subject. This feels like > text that doesn't need to be present. This particular example provides a useful illustration of the = "properties" construct in the JRD format. It's there purely as an example and is not otherwise adopted as a provisioning mechanism. Would this have = presented confusion if the aggsrv BoF had not been scheduled? I think there are = some good ideas in the aggsrv proposal, but I do not think that that work or = this example will cause confusion. In the end, the IETF will adopt some mechanism for provision email servers and this small example in the WF document should not be a source of confusion. So, I do think the text should be there, but if you really think it = might cause some confusion, perhaps we insert a note to make it clearer that = this is only an example and not the way client devices should be provisioned? =20 > Also, it's a cursed subject anyway; see ACAP. :-) Yeah, I'll give you that. The outcome of the BoF seemed to be no = clearer than it was going in. =20 > Major Comments: >=20 > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines and > repeats RFC 5988's =A74; I think this should be deferred explicitly to = RFC > 5988 in entirety, rather than specifically only for registered link > relation types. >=20 > The good news is that this should simplify the text rather a lot: >=20 > """ > The value of the "rel" member is a string containing a link relation > type (see RFC 5988 [4]). Both registered and extended relation types = are > permitted. > """ I do not think we can simplify the text so much. There is an explicit limitation in the WebFinger draft that a "rel" value must either be a = single absolute URI or a registered link relation type. RFC 5988 allows for multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. = RFC 5988 also allows URIs with fragments, but WebFinger does not. Valid = URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs). These = decisions were intended to avoid ambiguity. Much of the text you removed talks about the other members of the link relation object, which include "type", "href", "titles", and = "properties". The value of the "rel" member dictates how the other members are = interpreted and so I think that text needs to remain. =20 > 2) The use of webfinger with arbitrary URIs is something I had not > previously realised. This raises some concerns for me, as it's not = clear > whether this is either genuinely desirable or whether it introduces > considerations (security and otherwise) beyond those discussed within > the document. >=20 > I would in general rather the mechanism were restricted to acct, http, > https, and perhaps mailto. I don't think use of one URI scheme vs. another makes any difference in terms of security. However, it was definitely the desire of the group = to be able to use any URI scheme, including some URIs like 'tel'. Use of = 'tel' would mean the exact resolution mechanism would have to be defined, but people did not want to preclude its use. For others that have a domain part, the desire is to be able to go to the server and request a JRD for that URI. There may or may not be information available for a given = URI, but the procedures for one URI or another would be exactly the same. =20 > 3) There is no use of SRV here; I would prefer an SRV resolution step > for at least acct and mailto scheme URIs, and possibly http/https as > well. My concern is that a corporate webserver is typically unlikely = to > be capable of providing webfinger services (being often externally > hosted), and while this could be solved by handling redirects, or by > reverse proxying, SRV feels like a more stable solution here. >=20 > I'd be curious as to whether this has been discussed. This was discussed at length, yes. We also discussed the use of the URI resource record type. SRV records will tell you what host to go to, but not what URI. URI records will tell you more precisely what URI to query. However, both mechanisms build a dependency on DNS that will not work in = web browsers. One of the first uses of WebFinger (for which there are = already a few libraries available) is to query for information about people = directly from JavaScript in a browser. Thus, it was preferred to use a = .well-known location rooted at the given host. =20 > 4) It would make =A78 more readable if it were split into subsections. = I > think the first three paragraphs form a discussion about the transport > security, the middle paragraphs discuss privacy, and the final = paragraph > discusses information reliability. That's a good suggestion. I'll make the changes (and adapt as I get = through other reviewers' comments). =20 > I suspect there is one more case to be concerned about, which is that = it > may be possible for an attacker to use webfinger resources to test the > existence of a hypothetical user; that is, one might use webfinger as = a > harvesting mechanism. Again, a valid point. I'll insert text into a new sub-section just = above "Information Reliability" and call it "Abuse Potential". Here's what I propose: ----------------- 8.3 Abuse Potential Service providers should be mindful of the potential for abuse using WebFinger. As one example, one might query a WebFinger server only to discover whether a given URI is valid or not. With such a query, the person may deduce that an email identifier is valid, for example. Such an approach could help spammers maintain a current list of known email addresses and to discover new ones. WebFinger could be used to associate a name or other personal information with an email address, allowing spammers to craft more convincing email messages. This might be of particular value in phishing attempts. ----------------- Paul From paulej@packetizer.com Wed Mar 20 18:28:05 2013 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 4B03F21F8D59; Wed, 20 Mar 2013 18:28:05 -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 Ldg6BRsSmcga; Wed, 20 Mar 2013 18:28:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 55F3321F8D77; Wed, 20 Mar 2013 18:28:04 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2L1RiCk016022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 21:27:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363829267; bh=86zGJViPIp2tbNX1FeamPrVqsLRc0W6UOFA73ayJtco=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=WntHBW0FDYHeimpy2qm2QElgasDO/P9pX5K43p3kDv7/DMhp0ri+9CW9yoy1zkW4R yze6JxjqY+1sD092+KyC3aGMbHW0QRc4gcP8eyEXGkFag7zRAsGYRFFz6pncFIXNpb 3HKt/+a6CybJcGE/IJQyoruj1EEyNIGjM/uiQyu4= From: "Paul E. Jones" To: "'Alissa Cooper'" , References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 20 Mar 2013 21:28:01 -0400 Message-ID: <055401ce25d3$5566f120$0034d360$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKDaKO5ldokcAP290Gb0nohuKjS1AOIlQ8RlyiQfkA= Content-Language: en-us Cc: webfinger@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (WebFinger) 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: Thu, 21 Mar 2013 01:28:05 -0000 Alissa, It was suggested that we remove the word "implicit". I'm OK with removing it. If we did that, would you want to add this new sentence or a modified version of it? Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: Monday, March 18, 2013 11:31 AM > To: ietf@ietf.org > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Last Call: 10.txt> (WebFinger) to Proposed Standard > > Given how little control Internet users already have over which > information about them appears in which context, I do not have a lot of > confidence that the claimed discoverability benefits of WebFinger > outweigh its potential to further degrade users' ability to keep > particular information about themselves within specific silos. However, > I'm coming quite late to this document, so perhaps that balancing has > already been discussed, and it strikes me as unreasonable to try to > stand in the way of publication at this point. > > Two suggestions in section 8: > > s/personal information/personal data/ > (see http://tools.ietf.org/html/draft-iab-privacy-considerations- > 06#section-2.2 -- personal data is a more widely accepted term and > covers a larger range of information about people) > > The normative prohibition against using WebFinger to publish personal > data without authorization is good, but the notion of implicit > authorization leaves much uncertainty about what I imagine will be a use > case of interest: taking information out of a controlled context and > making it more widely available. To make it obvious that this has been > considered, I would suggest adding one more sentence to the end of the > fourth paragraph: > > "Publishing one's personal data within an access-controlled or otherwise > limited environment on the Internet does not equate to providing > implicit authorization of further publication of that data via > WebFinger." > > Alissa > > On Mar 4, 2013, at 3:24 PM, The IESG wrote: > > > > > The IESG has received a request from the Applications Area Working > > Group WG (appsawg) to consider the following document: > > - 'WebFinger' > > as Proposed Standard > > > > 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 2013-03-18. 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 specification defines the WebFinger protocol, which can be used > > to discover information about people or other entities on the > > Internet using standard HTTP methods. WebFinger discovers > > information for a URI that might not be usable as a locator > > otherwise, such as account or email URIs. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > > 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 paulej@packetizer.com Wed Mar 20 19:38:19 2013 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 E7E0221F8B85; Wed, 20 Mar 2013 19:38:19 -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 rpilDfAhilha; Wed, 20 Mar 2013 19:38:13 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AEC2121F8B7E; Wed, 20 Mar 2013 19:38:13 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2L2c9UQ020143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 22:38:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363833491; bh=Fv2dgRo51HKtAwCVzg+V43FaBFbEHx5OK0EwcZyEHZw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=BsdkLWPAv7gYKPNoE8j69JGprD+61Z6uI+CR867sK40tg4UJsWAtrLp2es+XGNXa0 HGkMqXJexZxcARU2YJVFmkyqQfy6fE/GzWcRlJWyUHeMVM0djcmj26eV3XdDi0NXeI ZLKf1ktSrSOrQxmk/dopEH4ugO9IcFXDZrnSGVKI= From: "Paul E. Jones" To: "'Hannes Tschofenig'" , References: <20130304202430.31062.82246.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 20 Mar 2013 22:38:26 -0400 Message-ID: <056801ce25dd$2b28b010$817a1030$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI0gy1+Rm1ye8tHtMgU8uLcqP1pXAKuk/Htl80sTDA= Content-Language: en-us Cc: webfinger@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (WebFinger) 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: Thu, 21 Mar 2013 02:38:20 -0000 Hannes, =20 > I was hoping that some of the remarks that I provided last year (e.g., > http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html) = would > help to clarify the content of the document. That didn't quite = happen... Yeah, I wasn't copied. =20 > In earlier versions of the document I had the impression that the = acct: > URI scheme always had to be used as input to the lookup process but as > Section 4.5 explains this is not necessary. The resource parameter may > contain other URIs as well. Section 4.5 does not give a lot of > description of when certain URIs are utilized.=20 Correct, any URI might be used. That does not mean that the server will = respond for every URI, but some wanted "acct" and "email" and "tel" = URIs, for example. Also, using an HTTP URI could be used to return = additional information about a URI. =20 > For example, in Section 3.1 the example talks about a user receiving = an > email from bob@examle.com and this email address is then used by > WebFinger but the request example shows an acct: URI scheme (rather = than > a mailto URI). It seems that there is the unstated assumption (at = least > in that example) that the mailto URI is the same as the acct: URI, = which > of course isn't necessarily the case. I believe it would be good to > state these assumptions to avoid confusing the reader.=20 Fair point. How about immediately following the example, we add: 'Note the assumption made in above example that there is an "acct" URI = for the given "mailto" URI. This is not always the case.' > Think about it: If you receive a SIP URI (which also has an email = alike > structure with a username @ domain part) that does not mean either = that > you can use this as an email address either. In some rare cases you > might.=20 That's definitely true. However, this is one reason for encouraging the = use of the "acct" URI scheme, though. In general (though not always), = there is account associated with the user. The SIP URI, mailto URI, = etc., each have a user part. I believe it is a reasonable assumption = that there *may be* an 'acct' URI for the user. If not, WF will return = nothing. We intended WF to be useful to humans, too, which means that if a user = sees paulej@packetizer.com, the user will assume that might be a means = of reaching "paulej" at "packetizer.com" using any number of tools = (email, XMPP, H.323, etc.). They would be correct for most. Thus, = there is encouragement for WF servers to use the acct URI. =20 > If you believe that everyone would get the difference anyway (because > the URI scheme determines the semantic of the identifier) then have a > look at the Google WebFinger page (see > http://code.google.com/p/webfinger/). At least these guys don't > understand the difference either.=20 There was even a proposal that we use no URI scheme at all and merely = have the user@domain identifier. However, there is value in using a = proper URI with WF, since querying "h323:paulej@packetizer.com" might = return the address of my Gatekeeper, for example, versus the information = that would be returned for my account.=20 > In general, I am wondering whether there are additional assumptions > implied about the URI scheme associated with the identifier in the > lookup mechanism. For example, the text in Section 3.3 talks about = email > client configuration and it seems that the requestor is interested in > receiving information about the email configuration based on the > resource=3Dmailto... URI scheme usage. If I use a different URI scheme > (like a aaa: URI scheme) would my response look different? Yeah, it might look different. What a WF server wishes to return for a = given URI is really up to the administrator. It might be that the same = information is returned for any given URI scheme having the same = user@domain part, but the server could return different responses. =20 > Then, there is a question about the lack of privacy considerations in > the document.=20 We do have quite a bit of text in the security considerations section. = This will be called out more clearly with sub-sections, but there are at = least three full paragraphs on privacy, even going to the point of = providing the example that sharing location information might put a = person in danger from someone who wishes to inflict harm on them. = Personally, I thought that went a bit overboard, but that text was = requested, so it's there. =20 > The usage of the WebFinger mechanism requires the requestor to have > access to the full username@domain identifier. While this may be OK in > some cases when the response relates very much to the specific user > account it may be a problem in other cases. For example, in the OAuth > case there is the idea that the user identifier may be hidden from the > relying party but you have just required that identifier to be = provided > to the relying party to start the entire OAuth exchange (in the > discovery). WF is not for use with every protocol, so I cannot address OAuth = generically. However, WF *is* used as a part of OpenID Connect. So, = yes, the user provides his/her identifier to the RP. However, that = decision is a matter outside the scope of WF. > The example in Section 3.1 returns information that relates to the > specific username and therefore it makes sense to provide the username > part of the identifier to the service that constructs the query. For = the > OpenID Connect discovery procedure described in Section 3.2 I wonder > whether this is always desirable. This was requested as an example to align with the OpenID Connect specs. > Could you expand the description a bit to explain why the relying = party > in this case has to obtain the username part as well? The returned > information does not seem to be specific to a certain user. It is the > server configuration. It would be nice if the configuration of an > identity provider software (e.g., OpenID Connect) is not different for > every user.=20 I'm not sure what to add, but I would welcome input. My understanding = is that this is how OpenID Connect works. If I were to visit a web site = and log in, what do I provide the site? It would not necessarily have = to be my email address. It could be = user123456@openid-connect-provider.net Whatever the case, something has = to be provided. A simple user@domain identifier is something most users = understand. The URIs used with OpenID were not so friendly for the = average user. =20 > I believe it is just fair to ask for a warning to be added to the > security consideration section indicating that WebFinger may have an > impact on your privacy expectation since it shares information with = the > relying party that other mechanisms do not provide. So, if you think > that this just works like other discovery mechanisms the IETF had = worked > on in the past then you might be surprised.=20 I'm OK with introducing more text to the security considerations = section, but it should not be heavily focused on OpenID or OpenID = Connect. Many readers of this spec would not even know what a "relying = party" is, ether. We should keep it generic. =20 > I would even volunteer to provide text but I fear that you are not = going > to like it.=20 :-) Well, I didn't like some of the other text that was added, but I = accepted it since people demanded it. If there is another broad point = that needs to be made, then I'm willing to add the text. I just added a = section on "abuse potential", as you might have seen. Paul From acooper@cdt.org Thu Mar 21 06:44:36 2013 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 1BEB221F8F1E; Thu, 21 Mar 2013 06:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 77sdWnP3FrFc; Thu, 21 Mar 2013 06:44:35 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8121F8F0B; Thu, 21 Mar 2013 06:44:34 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 21 Mar 2013 09:44:32 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: <055401ce25d3$5566f120$0034d360$@packetizer.com> Date: Thu, 21 Mar 2013 09:44:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E7B73F6-808B-4D8B-BE42-73A56C475C06@cdt.org> References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> <055401ce25d3$5566f120$0034d360$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (WebFinger) 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: Thu, 21 Mar 2013 13:44:36 -0000 I suggest adding the sentence without the word "implicitly." The result = would be: "Further, WebFinger MUST NOT be used to provide any personal information = to any party unless explicitly authorized by the person whose = information is being shared. Publishing one's personal data within an = access-controlled or otherwise limited environment on the Internet does = not equate to providing authorization of further publication of that = data via WebFinger." Thanks, Alissa On Mar 20, 2013, at 9:28 PM, Paul E. Jones = wrote: > Alissa, >=20 > It was suggested that we remove the word "implicit". I'm OK with = removing > it. If we did that, would you want to add this new sentence or a = modified > version of it? >=20 > Paul >=20 >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Alissa Cooper >> Sent: Monday, March 18, 2013 11:31 AM >> To: ietf@ietf.org >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Last Call: > 10.txt> (WebFinger) to Proposed Standard >>=20 >> Given how little control Internet users already have over which >> information about them appears in which context, I do not have a lot = of >> confidence that the claimed discoverability benefits of WebFinger >> outweigh its potential to further degrade users' ability to keep >> particular information about themselves within specific silos. = However, >> I'm coming quite late to this document, so perhaps that balancing has >> already been discussed, and it strikes me as unreasonable to try to >> stand in the way of publication at this point. >>=20 >> Two suggestions in section 8: >>=20 >> s/personal information/personal data/ >> (see http://tools.ietf.org/html/draft-iab-privacy-considerations- >> 06#section-2.2 -- personal data is a more widely accepted term and >> covers a larger range of information about people) >>=20 >> The normative prohibition against using WebFinger to publish personal >> data without authorization is good, but the notion of implicit >> authorization leaves much uncertainty about what I imagine will be a = use >> case of interest: taking information out of a controlled context and >> making it more widely available. To make it obvious that this has = been >> considered, I would suggest adding one more sentence to the end of = the >> fourth paragraph: >>=20 >> "Publishing one's personal data within an access-controlled or = otherwise >> limited environment on the Internet does not equate to providing >> implicit authorization of further publication of that data via >> WebFinger." >>=20 >> Alissa >>=20 >> On Mar 4, 2013, at 3:24 PM, The IESG wrote: >>=20 >>>=20 >>> The IESG has received a request from the Applications Area Working >>> Group WG (appsawg) to consider the following document: >>> - 'WebFinger' >>> as Proposed Standard >>>=20 >>> 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 2013-03-18. 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. >>>=20 >>> Abstract >>>=20 >>>=20 >>> This specification defines the WebFinger protocol, which can be = used >>> to discover information about people or other entities on the >>> Internet using standard HTTP methods. WebFinger discovers >>> information for a URI that might not be usable as a locator >>> otherwise, such as account or email URIs. >>>=20 >>>=20 >>>=20 >>>=20 >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ >>>=20 >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ >>>=20 >>>=20 >>> No IPR declarations have been submitted directly on this I-D. >>>=20 >>>=20 >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>>=20 >>=20 >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 From dave@cridland.net Thu Mar 21 06:46:20 2013 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 CA96121F9067 for ; Thu, 21 Mar 2013 06:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 BIrYwDXnOqZC for ; Thu, 21 Mar 2013 06:46:19 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3957921F9037 for ; Thu, 21 Mar 2013 06:46:19 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so3119434oag.32 for ; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2ip52Yr96hR0pxxJDM3yrMgUPTz7RKJP5KuuXANjZgk=; b=WS7+JAR5PXsMuPcfhUVbsAU92VbwwYHyRGfkBWmb4K0xfM2rQ9caBZAoHLAquchtG1 6RLDOK+yP1HkZve/LArmmgXV7+jpfe5cPYXDqfa4AyANRRtSyf1PJpH7cC/wVeFqXyLy yfbWxLVNfpOhb1DEfsUszmxql9jQ5VesCj9tI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2ip52Yr96hR0pxxJDM3yrMgUPTz7RKJP5KuuXANjZgk=; b=kNBflFku2A1soPfgPGvs7J11McNv4QLsGDQnVAo5OKb/dCTkEFbmDN057+lWxln+Kt R7oPECS0DV5wbLuxedVpMrQnRT8OJRsFjAv0Y3FWz2CsOsFhhcirW/RbOoIfkgPczvkx Ryf3oUbgRsOi7eYWyvBCWE3Rjxl+ETEfh+8jh9XvR2zsXaaqAO9i37pzucqSlEH0JWzn hb7Nuzmp+bJseK4R2Z/Hywum8bBXXK10zqrpBPe7THn4ROV4C2ZywtMw83RHjJ1lO4fd BH5eIRH4NdWcOOZQCqnea0HExAp3ocRp9Hln+n4iSDZjwdp5qq4S5f86kZtk52jjU9zR msoQ== MIME-Version: 1.0 X-Received: by 10.60.29.72 with SMTP id i8mr6643636oeh.93.1363873571279; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Thu, 21 Mar 2013 06:46:11 -0700 (PDT) In-Reply-To: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> Date: Thu, 21 Mar 2013 13:46:11 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f806bc7f9604d86f8f96 X-Gm-Message-State: ALoCoQmLzmNNmZDyIdPMG9ksc4OvWyvM0L9j90cUQjv+Lkzha5R+mk6sq+jeROFTlLR4cIqN/35Y Cc: webfinger@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 21 Mar 2013 13:46:20 -0000 --e89a8fb1f806bc7f9604d86f8f96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21 Mar 2013 00:39, "Paul E. Jones" wrote: > > Dave, > > My apologies for the belated reply. Please see my comments below. > > > 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-appsawg-webfinger-11 > > Title: Webfinger > > Reviewer: Dave Cridland > > Review Date: 2013/03/11 > > IESG Telechat Date: 2013/03/28 > > Summary: Close to ready for publication as standards track; some > > comments which suggest a new version may be required and/or technical > > discussion needed. > > > > Minor Comments: > > > > 1) There's some suggestions that webfinger could be used for email > > autoconfig; I suspect this is at best going to cause confusion > > especially when there's a BOF tomorrow on the subject. This feels like > > text that doesn't need to be present. > > This particular example provides a useful illustration of the "properties= " > construct in the JRD format. It's there purely as an example and is not > otherwise adopted as a provisioning mechanism. Would this have presented > confusion if the aggsrv BoF had not been scheduled? I think there are some > good ideas in the aggsrv proposal, but I do not think that that work or this > example will cause confusion. In the end, the IETF will adopt some > mechanism for provision email servers and this small example in the WF > document should not be a source of confusion. > > So, I do think the text should be there, but if you really think it might > cause some confusion, perhaps we insert a note to make it clearer that this > is only an example and not the way client devices should be provisioned? > As stated elsewhere, I think this is very confusing, and already generating the confusion I'm concerned about, in relation to RFC 6186 rather than AggSrv, in fact. I'd strongly prefer this example were removed, and replaced with something else. > > Major Comments: > > > > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines and > > repeats RFC 5988's =A74; I think this should be deferred explicitly to = RFC > > 5988 in entirety, rather than specifically only for registered link > > relation types. > > > > The good news is that this should simplify the text rather a lot: > > > > """ > > The value of the "rel" member is a string containing a link relation > > type (see RFC 5988 [4]). Both registered and extended relation types ar= e > > permitted. > > """ > > I do not think we can simplify the text so much. There is an explicit > limitation in the WebFinger draft that a "rel" value must either be a single > absolute URI or a registered link relation type. RFC 5988 allows for > multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. RF= C > 5988 also allows URIs with fragments, but WebFinger does not. Valid URIs > must conform to Section 4.3 of RFC 3986 (Absolute URIs). These decisions > were intended to avoid ambiguity. Link relation types are a single one of those values, the ABNF production, as opposed to the rel, which contains a . I'm entirely with you on why you want to restrict your rel to a single link relation type. Worth calling it out the difference, but it's not a deviation from RFC 5988. However, if you're changing the definition of link relation types, then: a) I'm deeply concerned. Redefining a standards-track specification seems worryingly close to NIH. There's horrible confusion lurking when someone says "Link relation type" and then has to qualify which definition. b) You need to make this absolutely clear in the document; it reads like you're restating, not redefining. c) The only distinction you claim above that appears to me to be an actual distinction is that fragments are disallowed. Yet no such restriction exists in the current draft. > Much of the text you removed talks about the other members of the link > relation object, which include "type", "href", "titles", and "properties"= . > The value of the "rel" member dictates how the other members are interpreted > and so I think that text needs to remain. Yes, I've probably trimmed too much there. > > 2) The use of webfinger with arbitrary URIs is something I had not > > previously realised. This raises some concerns for me, as it's not clea= r > > whether this is either genuinely desirable or whether it introduces > > considerations (security and otherwise) beyond those discussed within > > the document. > > > > I would in general rather the mechanism were restricted to acct, http, > > https, and perhaps mailto. > > I don't think use of one URI scheme vs. another makes any difference in > terms of security. However, it was definitely the desire of the group to be > able to use any URI scheme, including some URIs like 'tel'. Use of 'tel' > would mean the exact resolution mechanism would have to be defined, but > people did not want to preclude its use. For others that have a domain > part, the desire is to be able to go to the server and request a JRD for > that URI. There may or may not be information available for a given URI, > but the procedures for one URI or another would be exactly the same. I did say "security and otherwise". I'm not saying that any given URI scheme should be discounted forever more, I am suggesting the document should limit the schemes which have a defined behaviour for now. I have no clue what the possible impacts of using webfinger on a message id URI might be, nor do I wish to even think about it. I'm pretty sure that mailto has some corner cases we've not yet thought about; it's not just an email address after all. > > 3) There is no use of SRV here; I would prefer an SRV resolution step > > for at least acct and mailto scheme URIs, and possibly http/https as > > well. My concern is that a corporate webserver is typically unlikely to > > be capable of providing webfinger services (being often externally > > hosted), and while this could be solved by handling redirects, or by > > reverse proxying, SRV feels like a more stable solution here. > > > > I'd be curious as to whether this has been discussed. > > This was discussed at length, yes. We also discussed the use of the URI > resource record type. > > SRV records will tell you what host to go to, but not what URI. > URI records will tell you more precisely what URI to query. > > However, both mechanisms build a dependency on DNS that will not work in web > browsers. One of the first uses of WebFinger (for which there are already a > few libraries available) is to query for information about people directl= y > from JavaScript in a browser. Thus, it was preferred to use a .well-know= n > location rooted at the given host. That sucks. It's a shame that browsers are holding back use of SRV and other decade-old technology for things like this. But I accept that this has been discussed and blocked by browser brokenness= . > Here's what I propose: > > ----------------- > 8.3 Abuse Potential > > Service providers should be mindful of the potential for abuse using > WebFinger. > > As one example, one might query a WebFinger server only to discover > whether a given URI is valid or not. With such a query, the person > may deduce that an email identifier is valid, for example. Such an > approach could help spammers maintain a current list of known email > addresses and to discover new ones. > > WebFinger could be used to associate a name or other personal > information with an email address, allowing spammers to craft more > convincing email messages. This might be of particular value in > phishing attempts. > ----------------- That seems sensible. Dave. --e89a8fb1f806bc7f9604d86f8f96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 21 Mar 2013 00:39, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Dave,
>
> My apologies for the belated reply. =A0Please see my comments below. >
> > Please resolve these comments along with any other Last Call comm= ents
> > you may receive. Please wait for direction from your document she= pherd
> > or AD before posting a new version of the draft. =A0Document:
> > draft-ietf-appsawg-webfinger-11
> > Title: Webfinger
> > Reviewer: Dave Cridland
> > Review Date: 2013/03/11
> > IESG Telechat Date: 2013/03/28
> > Summary: Close to ready for publication as standards track; some<= br> > > comments which suggest a new version may be required and/or techn= ical
> > discussion needed.
> >
> > Minor Comments:
> >
> > 1) There's some suggestions that webfinger could be used for = email
> > autoconfig; I suspect this is at best going to cause confusion > > especially when there's a BOF tomorrow on the subject. This f= eels like
> > text that doesn't need to be present.
>
> This particular example provides a useful illustration of the "pr= operties"
> construct in the JRD format. =A0It's there purely as an example an= d is not
> otherwise adopted as a provisioning mechanism. =A0Would this have pres= ented
> confusion if the aggsrv BoF had not been scheduled? =A0I think there a= re some
> good ideas in the aggsrv proposal, but I do not think that that work o= r this
> example will cause confusion. =A0In the end, the IETF will adopt some<= br> > mechanism for provision email servers and this small example in the WF=
> document should not be a source of confusion.
>
> So, I do think the text should be there, but if you really think it mi= ght
> cause some confusion, perhaps we insert a note to make it clearer that= this
> is only an example and not the way client devices should be provisione= d?
>

As stated elsewhere, I think this is very confusing, and alr= eady generating the confusion I'm concerned about, in relation to RFC 6= 186 rather than AggSrv, in fact.

I'd strongly prefer this example were removed, and repla= ced with something else.

> > Major Comments:
> >
> > 1) I note that =A74.4.4.1 describes a 'rel' such that it = redefines and
> > repeats RFC 5988's =A74; I think this should be deferred expl= icitly to RFC
> > 5988 in entirety, rather than specifically only for registered li= nk
> > relation types.
> >
> > The good news is that this should simplify the text rather a lot:=
> >
> > """
> > The value of the "rel" member is a string containing a = link relation
> > type (see RFC 5988 [4]). Both registered and extended relation ty= pes are
> > permitted.
> > =A0"""
>
> I do not think we can simplify the text so much. =A0There is an explic= it
> limitation in the WebFinger draft that a "rel" value must ei= ther be a single
> absolute URI or a registered link relation type. =A0RFC 5988 allows fo= r
> multiple values like 'rel=3D"shortcut icon"', but We= bFinger does not. =A0RFC
> 5988 also allows URIs with fragments, but WebFinger does not. =A0Valid= URIs
> must conform to Section 4.3 of RFC 3986 (Absolute URIs). =A0These deci= sions
> were intended to avoid ambiguity.

Link relation types are a single one of those values, the &l= t;relation-type> ABNF production, as opposed to the rel, which contains = a <relation-types>. I'm entirely with you on why you want to rest= rict your rel to a single link relation type. Worth calling it out the diff= erence, but it's not a deviation from RFC 5988.

However, if you're changing the definition of link relat= ion types, then:

a) I'm deeply concerned. Redefining a standards-track sp= ecification seems worryingly close to NIH. There's horrible confusion l= urking when someone says "Link relation type" and then has to qua= lify which definition.

b) You need to make this absolutely clear in the document; i= t reads like you're restating, not redefining.

c) The only distinction you claim above that appears to me t= o be an actual distinction is that fragments are disallowed. Yet no such re= striction exists in the current draft.

> Much of the text you removed talks about the other memb= ers of the link
> relation object, which include "type", "href", &qu= ot;titles", and "properties".
> The value of the "rel" member dictates how the other members= are interpreted
> and so I think that text needs to remain.

Yes, I've probably trimmed too much there.

> > 2) The use of webfinger with arbitrary URIs is som= ething I had not
> > previously realised. This raises some concerns for me, as it'= s not clear
> > whether this is either genuinely desirable or whether it introduc= es
> > considerations (security and otherwise) beyond those discussed wi= thin
> > the document.
> >
> > I would in general rather the mechanism were restricted to acct, = http,
> > https, and perhaps mailto.
>
> I don't think use of one URI scheme vs. another makes any differen= ce in
> terms of security. =A0However, it was definitely the desire of the gro= up to be
> able to use any URI scheme, including some URIs like 'tel'. = =A0Use of 'tel'
> would mean the exact resolution mechanism would have to be defined, bu= t
> people did not want to preclude its use. =A0For others that have a dom= ain
> part, the desire is to be able to go to the server and request a JRD f= or
> that URI. =A0There may or may not be information available for a given= URI,
> but the procedures for one URI or another would be exactly the same.

I did say "security and otherwise". I'm not sa= ying that any given URI scheme should be discounted forever more, I am sugg= esting the document should limit the schemes which have a defined behaviour= for now.

I have no clue what the possible impacts of using webfinger = on a message id URI might be, nor do I wish to even think about it.

I'm pretty sure that mailto has some corner cases we'= ;ve not yet thought about; it's not just an email address after all.

> > 3) There is no use of SRV here; I would prefer an = SRV resolution step
> > for at least acct and mailto scheme URIs, and possibly http/https= as
> > well. My concern is that a corporate webserver is typically unlik= ely to
> > be capable of providing webfinger services (being often externall= y
> > hosted), and while this could be solved by handling redirects, or= by
> > reverse proxying, SRV feels like a more stable solution here.
> >
> > I'd be curious as to whether this has been discussed.
>
> This was discussed at length, yes. =A0We also discussed the use of the= URI
> resource record type.
>
> SRV records will tell you what host to go to, but not what URI.
> URI records will tell you more precisely what URI to query.
>
> However, both mechanisms build a dependency on DNS that will not work = in web
> browsers. =A0One of the first uses of WebFinger (for which there are a= lready a
> few libraries available) is to query for information about people dire= ctly
> from JavaScript in a browser. =A0Thus, it was preferred to use a .well= -known
> location rooted at the given host.

That sucks.

It's a shame that browsers are holding back use of SRV a= nd other decade-old technology for things like this.

But I accept that this has been discussed and blocked by bro= wser brokenness.

> Here's what I propose:
>
> -----------------
> 8.3 Abuse Potential
>
> Service providers should be mindful of the potential for abuse using > WebFinger.
>
> As one example, one might query a WebFinger server only to discover > whether a given URI is valid or not. =A0With such a query, the person<= br> > may deduce that an email identifier is valid, for example. =A0Such an<= br> > approach could help spammers maintain a current list of known email > addresses and to discover new ones.
>
> WebFinger could be used to associate a name or other personal
> information with an email address, allowing spammers to craft more
> convincing email messages. =A0This might be of particular value in
> phishing attempts.
> -----------------

That seems sensible.

Dave.

--e89a8fb1f806bc7f9604d86f8f96-- From bill.wu@huawei.com Thu Mar 21 02:43:43 2013 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 DF59A21F902C for ; Thu, 21 Mar 2013 02:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=3.798, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 iEZi1xlKWL83 for ; Thu, 21 Mar 2013 02:43:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE1C21F9024 for ; Thu, 21 Mar 2013 02:43:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APP82078; Thu, 21 Mar 2013 09:43:29 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 09:43:21 +0000 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 09:43:05 +0000 Received: from w53375 (10.138.41.149) by szxeml415-hub.china.huawei.com (10.82.67.154) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 17:42:16 +0800 Message-ID: <0701D3EEF1184DF8A17EEC2B1049CA45@china.huawei.com> From: Qin Wu To: Enrico Marocco , References: <51488893.4080202@telecomitalia.it> Date: Thu, 21 Mar 2013 17:42:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 21 Mar 2013 10:19:49 -0700 Cc: draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-decodability-09 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, 21 Mar 2013 09:43:44 -0000 SGksRW5yaWNvOg0KVGhhbmsgZm9yIHlvdXIgdmFsdWFibGUgcmV2aWV3LiBQbGVhc2Ugc2VlIG15 IHJlcGx5IGlubGluZS4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQpGcm9tOiAiRW5yaWNvIE1hcm9jY28iIDxlbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0Pg0KVG86IDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+OyA84sB0b29scy5pZXRmLm9yZz4N ClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE5LCAyMDEzIDExOjQ3IFBNDQpTdWJqZWN0OiBBUFBTRElS IHJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxpdHktMDkNCg0K DQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgQXBwbGljYXRpb25zIEFyZWEgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yDQp0aGlzIGRyYWZ0IChmb3IgYmFja2dyb3VuZCBvbiBhcHBzZGlyLCBw bGVhc2Ugc2VlDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2FwcC90cmFjL3dpa2kv QXBwbGljYXRpb25zQXJlYURpcmVjdG9yYXRlICkuDQoNClBsZWFzZSByZXNvbHZlIHRoZXNlIGNv bW1lbnRzIGFsb25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cw0KeW91IG1heSBy ZWNlaXZlLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVw aGVyZA0Kb3IgQUQgYmVmb3JlIHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQoN CkRvY3VtZW50OiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxpdHktMDkNClRp dGxlOiBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgRXh0ZW5kZWQgUmVwb3J0IChYUikgQmxv Y2sgZm9yIE1QRUcyDQpUcmFuc3BvcnQgU3RyZWFtIChUUykgUHJvZ3JhbSBTcGVjaWZpYyBJbmZv cm1hdGlvbiAoUFNJKSBJbmRlcGVuZGVudA0KRGVjb2RhYmlsaXR5IFN0YXRpc3RpY3MgTWV0cmlj cyByZXBvcnRpbmcNClJldmlld2VyOiBFbnJpY28gTWFyb2Njbw0KUmV2aWV3IERhdGU6IDIwMTMt MDMtMTkNCklFVEYgTGFzdCBDYWxsIERhdGU6IFVua25vd24NCklFU0cgVGVsZWNoYXQgRGF0ZTog VW5rbm93bg0KDQpTdW1tYXJ5OiBUaGlzIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBh cyBhIFN0YW5kYXJkcyBUcmFjayBSRkMuDQpGcm9tIGFuIEFQUFMgcG9pbnQgb2YgdmlldyB0aGVy ZSBubyBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50LCBidXQgYQ0KYnVuY2ggb2Ygbml0cyB0aGUg UkZDIEVkaXRvciB3b3VsZCBoYXZlIHNwb3R0ZWQgYW55d2F5Lg0KDQpOaXRzOg0KDQpHZW5lcmFs IG5vdGU6IEVUU0kgVFIgMTAxIDI5MCBpcyBtZW50aW9uZWQgaW4gc2V2ZXJhbCBwbGFjZXMgdGhy b3VnaG91dA0KdGhlIGRvY3VtZW50LiBJdCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCB0aGUgYWN0 dWFsIHJlZmVyZW5jZSAoW0VUU0ldKS4NCg0KW1Fpbl06IE9rYXkuDQoNCkFic3RyYWN0OiBUaGUg bGFzdCBzZW50ZW5jZSBpcyByZWFsbHkgaGFyZCB0byByZWFkLiBJJ20gbm90IHN1cmUgSQ0KZW50 aXJlbHkgdW5kZXJzdGFuZCB3aGF0IGl0IG1lYW5zLCBzbyBJJ2xsIGxldCBpdCB1cCB0byB0aGUg YXV0aG9ycyB0bw0KcHJvcG9zZSBhIGJldHRlciB3b3JkaW5nLg0KDQpbUWluXTpIb3cgYWJvdXQg cmVwaHJhc2UgaXQgYXM6DQpPTEQgVEVYVDoNCiINClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBS VFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgRXh0ZW5kZWQgUmVwb3J0IChYUikgQmxvY2sNCnRo YXQgYWxsb3dzIHRoZSByZXBvcnRpbmcgb2YgTVBFRzIgVFMgUHJvZ3JhbSBTcGVjaWZpYyBJbmZv cm1hdGlvbg0KKFBTSSkgSW5kZXBlbmRlbnQgZGVjb2RhYmlsaXR5IHN0YXRpc3RpY3MgbWV0cmlj cyByZWxhdGVkIHRvDQogdHJhbnNtaXNzaW9ucyBvZiBNUEVHMiBUUyBvdmVyIFJUUC4NCg0KDQoi DQpORVcgVEVYVDoNCiINClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBSVFAgQ29udHJvbCBQcm90 b2NvbCAoUlRDUCkgRXh0ZW5kZWQgUmVwb3J0IChYUikgQmxvY2sNCg0KdGhhdCBhbGxvd3MgdGhl IHJlcG9ydGluZyBvZiBNUEVHMiBUUyBkZWNvZGFiaWxpdHkgc3RhdGlzdGljcyBtZXRyaWNzIHJl bGF0ZWQgdG8NCg0KdHJhbnNtaXNzaW9ucyBvZiBNUEVHMiBUUyBvdmVyIFJUUC4gVGhlIG1ldHJp Y3MgaW4gdGhlIFJUQ1AgWFIgQmxvY2sgYXJlIG5vdCBkZXBlbmRlbnQNCg0KIG9uIFByb2dyYW0g c3BlY2lmaWMgaW5mb3JtYXRpb24gKFBTSSkgY2FycmllZCBpbiBNUEVHIFRTLg0KDQoiDQoNClMu IDMsICJSZXNlcnZlZCIgZGVmaW5pdGlvbjogcy9zZW5kZXJzIGlnbm9yZWQvc2VuZGVycyBhbmQg aWdub3JlZC8NCg0KW1Fpbl06IEdvb2QgY2F0Y2guIFRoYW5rcy4NCg== From bill.wu@huawei.com Thu Mar 21 02:44:49 2013 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 8F23121F901B for ; Thu, 21 Mar 2013 02:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=1.526, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 Bq4FWoBoZAOC for ; Thu, 21 Mar 2013 02:44:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0FE521F8F3A for ; Thu, 21 Mar 2013 02:44:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APP82264; Thu, 21 Mar 2013 09:44:44 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 09:43:46 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 09:44:41 +0000 Received: from w53375 (10.138.41.149) by szxeml417-hub.china.huawei.com (10.82.67.156) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 17:44:29 +0800 Message-ID: From: Qin Wu To: , Date: Thu, 21 Mar 2013 17:44:28 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DD2_01CE265B.BC638040" 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.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 21 Mar 2013 10:20:04 -0700 Cc: draft-ietf-xrblock-rtcp-xr-decodability@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-xrblock-rtcp-xr-decodability-09 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, 21 Mar 2013 09:44:49 -0000 ------=_NextPart_000_0DD2_01CE265B.BC638040 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksRW5yaWNvOg0KVGhhbmsgZm9yIHlvdXIgdmFsdWFibGUgcmV2aWV3LCBzZWUgcmVwbHkgaW5s aW5lLg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJFbnJpY28gTWFyb2Nj byIgPGVucmljby5tYXJvY2NvQHRlbGVjb21pdGFsaWEuaXQ+DQpUbzogPGFwcHMtZGlzY3Vzc0Bp ZXRmLm9yZz47IDziwHRvb2xzLmlldGYub3JnPg0KU2VudDogVHVlc2RheSwgTWFyY2ggMTksIDIw MTMgMTE6NDcgUE0NClN1YmplY3Q6IEFQUFNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJibG9j ay1ydGNwLXhyLWRlY29kYWJpbGl0eS0wOQ0KDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRo ZSBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCnRoaXMgZHJhZnQg KGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBsZWFzZSBzZWUNCmh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUg KS4NCg0KUGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIg TGFzdCBDYWxsIGNvbW1lbnRzDQp5b3UgbWF5IHJlY2VpdmUuIFBsZWFzZSB3YWl0IGZvciBkaXJl Y3Rpb24gZnJvbSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkDQpvciBBRCBiZWZvcmUgcG9zdGluZyBh IG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYteHJibG9j ay1ydGNwLXhyLWRlY29kYWJpbGl0eS0wOQ0KVGl0bGU6IFJUUCBDb250cm9sIFByb3RvY29sIChS VENQKSBFeHRlbmRlZCBSZXBvcnQgKFhSKSBCbG9jayBmb3IgTVBFRzINClRyYW5zcG9ydCBTdHJl YW0gKFRTKSBQcm9ncmFtIFNwZWNpZmljIEluZm9ybWF0aW9uIChQU0kpIEluZGVwZW5kZW50DQpE ZWNvZGFiaWxpdHkgU3RhdGlzdGljcyBNZXRyaWNzIHJlcG9ydGluZw0KUmV2aWV3ZXI6IEVucmlj byBNYXJvY2NvDQpSZXZpZXcgRGF0ZTogMjAxMy0wMy0xOQ0KSUVURiBMYXN0IENhbGwgRGF0ZTog VW5rbm93bg0KSUVTRyBUZWxlY2hhdCBEYXRlOiBVbmtub3duDQoNClN1bW1hcnk6IFRoaXMgZHJh ZnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJGQy4NCkZy b20gYW4gQVBQUyBwb2ludCBvZiB2aWV3IHRoZXJlIG5vIGlzc3VlcyB3aXRoIHRoaXMgZG9jdW1l bnQsIGJ1dCBhDQpidW5jaCBvZiBuaXRzIHRoZSBSRkMgRWRpdG9yIHdvdWxkIGhhdmUgc3BvdHRl ZCBhbnl3YXkuDQoNCk5pdHM6DQoNCkdlbmVyYWwgbm90ZTogRVRTSSBUUiAxMDEgMjkwIGlzIG1l bnRpb25lZCBpbiBzZXZlcmFsIHBsYWNlcyB0aHJvdWdob3V0DQp0aGUgZG9jdW1lbnQuIEl0IHNo b3VsZCBiZSByZXBsYWNlZCB3aXRoIHRoZSBhY3R1YWwgcmVmZXJlbmNlIChbRVRTSV0pLg0KDQpb UWluXTogT2theS4NCg0KQWJzdHJhY3Q6IFRoZSBsYXN0IHNlbnRlbmNlIGlzIHJlYWxseSBoYXJk IHRvIHJlYWQuIEknbSBub3Qgc3VyZSBJDQplbnRpcmVseSB1bmRlcnN0YW5kIHdoYXQgaXQgbWVh bnMsIHNvIEknbGwgbGV0IGl0IHVwIHRvIHRoZSBhdXRob3JzIHRvDQpwcm9wb3NlIGEgYmV0dGVy IHdvcmRpbmcuDQoNCltRaW5dOkhvdyBhYm91dCByZXBocmFzZSBpdCBhczoNCk9MRCBURVhUOg0K Ig0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBF eHRlbmRlZCBSZXBvcnQgKFhSKSBCbG9jaw0KdGhhdCBhbGxvd3MgdGhlIHJlcG9ydGluZyBvZiBN UEVHMiBUUyBQcm9ncmFtIFNwZWNpZmljIEluZm9ybWF0aW9uDQooUFNJKSBJbmRlcGVuZGVudCBk ZWNvZGFiaWxpdHkgc3RhdGlzdGljcyBtZXRyaWNzIHJlbGF0ZWQgdG8NCiB0cmFuc21pc3Npb25z IG9mIE1QRUcyIFRTIG92ZXIgUlRQLg0KDQoNCiINCk5FVyBURVhUOg0KIg0KVGhpcyBkb2N1bWVu dCBkZWZpbmVzIGFuIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBFeHRlbmRlZCBSZXBvcnQg KFhSKSBCbG9jaw0KDQp0aGF0IGFsbG93cyB0aGUgcmVwb3J0aW5nIG9mIE1QRUcyIFRTIGRlY29k YWJpbGl0eSBzdGF0aXN0aWNzIG1ldHJpY3MgcmVsYXRlZCB0bw0KDQp0cmFuc21pc3Npb25zIG9m IE1QRUcyIFRTIG92ZXIgUlRQLiBUaGUgbWV0cmljcyBpbiB0aGUgUlRDUCBYUiBCbG9jayBhcmUg bm90IGRlcGVuZGVudA0KDQogb24gUHJvZ3JhbSBzcGVjaWZpYyBpbmZvcm1hdGlvbiAoUFNJKSBj YXJyaWVkIGluIE1QRUcgVFMuDQoNCiINCg0KDQpTLiAzLCAiUmVzZXJ2ZWQiIGRlZmluaXRpb246 IHMvc2VuZGVycyBpZ25vcmVkL3NlbmRlcnMgYW5kIGlnbm9yZWQvDQoNCltRaW5dT2theSBhbmQg d2lsbCBmaXggdGhpcy4NCg== ------=_NextPart_000_0DD2_01CE265B.BC638040 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE5Mzk0Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGksRW5yaWNvOjxCUj5U aGFuayBmb3IgeW91ciB2YWx1YWJsZSByZXZpZXcsIHNlZSByZXBseSANCmlubGluZS48QlI+LS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8QlI+RnJvbTogIkVucmljbyBNYXJvY2NvIiAmbHQ7 PEEgDQpocmVmPSJtYWlsdG86ZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdCI+ZW5yaWNv Lm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDwvQT4mZ3Q7PEJSPlRvOiANCiZsdDs8QSBocmVmPSJt YWlsdG86YXBwcy1kaXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8L0E+Jmd0 OzsgDQombHQ74sB0b29scy5pZXRmLm9yZyZndDs8QlI+U2VudDogVHVlc2RheSwgTWFyY2ggMTks IDIwMTMgMTE6NDcgUE08QlI+U3ViamVjdDogDQpBUFBTRElSIHJldmlldyBvZiBkcmFmdC1pZXRm LXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxpdHktMDk8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEJSPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRo ZSBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZpZXdlciANCmZvcjxCUj50aGlzIGRy YWZ0IChmb3IgYmFja2dyb3VuZCBvbiBhcHBzZGlyLCBwbGVhc2Ugc2VlPEJSPjxBIA0KaHJlZj0i aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9u c0FyZWFEaXJlY3RvcmF0ZSI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJh Yy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZTwvQT4gDQopLjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+UGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0 aCBhbnkgb3RoZXIgTGFzdCBDYWxsIA0KY29tbWVudHM8QlI+eW91IG1heSByZWNlaXZlLiBQbGVh c2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCANCnNoZXBoZXJkPEJSPm9y IEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+RG9jdW1lbnQ6IGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhy LWRlY29kYWJpbGl0eS0wOTxCUj5UaXRsZTogUlRQIENvbnRyb2wgDQpQcm90b2NvbCAoUlRDUCkg RXh0ZW5kZWQgUmVwb3J0IChYUikgQmxvY2sgZm9yIE1QRUcyPEJSPlRyYW5zcG9ydCBTdHJlYW0g KFRTKSANClByb2dyYW0gU3BlY2lmaWMgSW5mb3JtYXRpb24gKFBTSSkgSW5kZXBlbmRlbnQ8QlI+ RGVjb2RhYmlsaXR5IFN0YXRpc3RpY3MgDQpNZXRyaWNzIHJlcG9ydGluZzxCUj5SZXZpZXdlcjog RW5yaWNvIE1hcm9jY288QlI+UmV2aWV3IERhdGU6IDIwMTMtMDMtMTk8QlI+SUVURiANCkxhc3Qg Q2FsbCBEYXRlOiBVbmtub3duPEJSPklFU0cgVGVsZWNoYXQgRGF0ZTogVW5rbm93bjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+U3VtbWFyeTogVGhpcyBkcmFmdCBpcyByZWFkeSBmb3Ig cHVibGljYXRpb24gYXMgYSBTdGFuZGFyZHMgVHJhY2sgDQpSRkMuPEJSPkZyb20gYW4gQVBQUyBw b2ludCBvZiB2aWV3IHRoZXJlIG5vIGlzc3VlcyB3aXRoIHRoaXMgZG9jdW1lbnQsIGJ1dCANCmE8 QlI+YnVuY2ggb2Ygbml0cyB0aGUgUkZDIEVkaXRvciB3b3VsZCBoYXZlIHNwb3R0ZWQgYW55d2F5 LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Tml0czo8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPkdlbmVyYWwgbm90ZTogRVRTSSBUUiAxMDEgMjkwIGlzIG1lbnRpb25lZCBp biBzZXZlcmFsIHBsYWNlcyANCnRocm91Z2hvdXQ8QlI+dGhlIGRvY3VtZW50LiBJdCBzaG91bGQg YmUgcmVwbGFjZWQgd2l0aCB0aGUgYWN0dWFsIHJlZmVyZW5jZSANCihbRVRTSV0pLjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+W1Fpbl06IE9rYXkuPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5BYnN0cmFjdDogVGhlIGxhc3Qgc2VudGVuY2UgaXMgcmVhbGx5IGhhcmQgdG8g cmVhZC4gSSdtIG5vdCBzdXJlIA0KSTxCUj5lbnRpcmVseSB1bmRlcnN0YW5kIHdoYXQgaXQgbWVh bnMsIHNvIEknbGwgbGV0IGl0IHVwIHRvIHRoZSBhdXRob3JzIA0KdG88QlI+cHJvcG9zZSBhIGJl dHRlciB3b3JkaW5nLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+W1Fpbl06SG93IGFi b3V0IHJlcGhyYXNlIGl0IGFzOjxCUj5PTEQgVEVYVDo8QlI+IjxCUj5UaGlzIGRvY3VtZW50IGRl ZmluZXMgDQphbiBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgRXh0ZW5kZWQgUmVwb3J0IChY UikgQmxvY2s8QlI+dGhhdCBhbGxvd3MgdGhlIA0KcmVwb3J0aW5nIG9mIE1QRUcyIFRTIFByb2dy YW0gU3BlY2lmaWMgSW5mb3JtYXRpb248QlI+KFBTSSkgSW5kZXBlbmRlbnQgDQpkZWNvZGFiaWxp dHkgc3RhdGlzdGljcyBtZXRyaWNzIHJlbGF0ZWQgdG88QlI+Jm5ic3A7dHJhbnNtaXNzaW9ucyBv ZiBNUEVHMiBUUyANCm92ZXIgUlRQLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEJS PiI8QlI+TkVXIFRFWFQ6PEJSPiI8QlI+VGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIFJUUCBDb250 cm9sIFByb3RvY29sIA0KKFJUQ1ApIEV4dGVuZGVkIFJlcG9ydCAoWFIpIEJsb2NrPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj50aGF0IGFsbG93cyB0aGUgcmVwb3J0aW5nIG9mIE1QRUcy IFRTIGRlY29kYWJpbGl0eSBzdGF0aXN0aWNzIG1ldHJpY3MgDQpyZWxhdGVkIHRvPC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj50cmFuc21pc3Npb25zIG9mIE1QRUcyIFRTIG92ZXIgUlRQ LiBUaGUgbWV0cmljcyBpbiB0aGUgUlRDUCBYUiBCbG9jayBhcmUgDQpub3QgZGVwZW5kZW50PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDtvbiBQcm9ncmFtIHNwZWNpZmljIGlu Zm9ybWF0aW9uIChQU0kpIGNhcnJpZWQgaW4gTVBFRyBUUy48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPiI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj5TLiAzLCAiUmVz ZXJ2ZWQiIGRlZmluaXRpb246IHMvc2VuZGVycyBpZ25vcmVkL3NlbmRlcnMgYW5kIA0KaWdub3Jl ZC88L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPltRaW5dT2theSBhbmQgd2lsbCBmaXgg dGhpcy48QlI+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0DD2_01CE265B.BC638040-- From bill.wu@huawei.com Thu Mar 21 04:50:02 2013 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 E3D0A21F8F0C for ; Thu, 21 Mar 2013 04:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 08hrUhwvgVYw for ; Thu, 21 Mar 2013 04:50:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D45E21F8EE1 for ; Thu, 21 Mar 2013 04:50:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APP92980; Thu, 21 Mar 2013 11:49:58 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:49:57 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:49:56 +0000 Received: from w53375 (10.138.41.149) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 19:49:50 +0800 Message-ID: <93C0DF6839E740AF8AF4B4D9EF857985@china.huawei.com> From: Qin Wu To: Eric Burger , , References: Date: Thu, 21 Mar 2013 19:49:49 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EED_01CE266D.3F5A8230" 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.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 21 Mar 2013 10:20:16 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10 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, 21 Mar 2013 11:50:03 -0000 ------=_NextPart_000_0EED_01CE266D.3F5A8230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksRXJpYzoNClRoYW5rIGZvciB5b3VyIGNhcmVmdWwgcmV2aWV3Lg0KQm90aCBTZWN0aW9uIDEu MSBhbmQgU2VjdGlvbiAzLjMgb2YgdGhpcyBkcmFmdCBoYXZlIGFscmVhZHkgcmVmZXJyZWQgdGhl IHJlYWRlcnMgdG8gdGhlIHJlbGV2YW50IGRvY3VtZW50cyBieQ0KIHBvaW50aW5nIHRvIGRpc2Fy ZCBkcmFmdC4gQnVyc3QgZ2FwIGRpc2NhcmQgYW5kIGRpc2NhcmQgZG9uJ3QgbmVlZCB0byBiZSBj b3VwbGVkIHdpdGggUkxFIGRpc2NhcmQgZHJhZnQuIA0KU28gSSB0aGluayBpdCB3aWxsIGJlIG1v cmUgdXNlZnVsIHRvIGhhdmUgYSBzZXBhcmF0ZSByb2FkbWFwIGRvY3VtZW50IGFuZCBnbyBpbnRv IGRldGFpbHMgdG8gZGlzY3VzcyBob3cgdG8NCiBpbXBsZW1lbnQgdGhlbSBpbiBkaWZmZXJlbnQg dXNlIGNhc2VzLg0KDQpSZWdhcmRzDQotUWluDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQogIEZyb206IEVyaWMgQnVyZ2VyIA0KICBUbzogZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3At eHItYnVyc3QtZ2FwLWRpc2NhcmRAdG9vbHMuaWV0Zi5vcmcgOyB4cmJsb2NrLWNoYWlyc0B0b29s cy5pZXRmLm9yZyANCiAgQ2M6IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZyANCiAgU2VudDogTW9uZGF5 LCBNYXJjaCAxOCwgMjAxMyAxMDo1OSBQTQ0KICBTdWJqZWN0OiBBcHBzIFJldmlldyBvZiBkcmFm dC1pZXRmLXhyYmxvY2stcnRjcC14ci1idXJzdC1nYXAtZGlzY2FyZC0xMA0KDQoNCiAgSW4gZ2Vu ZXJhbCwgdGhpcyBkb2N1bWVudCBpcyByZWFkeSB0byBnby4gSSBoYXZlIG9uZSBlZGl0b3JpYWwg c3VnZ2VzdGlvbi4gSW4gb3JkZXIgdG8gdW5kZXJzdGFuZCB0aGlzIGRvY3VtZW50LCBJIGhhZCB0 byByZWFkIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRpc2NhcmQtMTEgYW5kIGRyYWZ0LWll dGYteHJibG9jay1ydGNwLXhyLWRpc2NhcmQtcmxlLW1ldHJpY3MtMDUgdG8gZmlndXJlIG91dCB3 aGVyZSB0aGlzIGRyYWZ0IGZpdHMgaW50byB0aGUgaml0dGVyIHJlcG9ydGluZyBlY29zeXN0ZW0u IEkgZ2V0IHdoeSB0aGVzZSBhcmUgYWxsIHNtYWxsLCBzZXBhcmF0ZSBkcmFmdHMuIEhvd2V2ZXIs IEkgY291bGQgbm90IGVhc2lseSBmaW5kIGFuIG92ZXJhcmNoaW5nIGRvY3VtZW50IHR5aW5nIHRo aW5ncyB0b2dldGhlci4gZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItZGlzY2FyZC1ybGUtbWV0 cmljcy0wNSBkb2VzIGEgZGVjZW50IGpvYiBpbiB0aGUgSW50cm9kdWN0aW9uIG9mIGRlc2NyaWJp bmcgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHhyLWJ1cnN0LWdhcC1kaXNjYXJkIGFuZCB4ci1k aXNjYXJkLiBIb3dldmVyLCB0aGF0IGlzIGluIHRoZSBjb250ZXh0IG9mIHdoeSB3ZSBoYXZlIGEg dGhpcmQgZHJhZnQgb24gd2hhdCBvbiBmaXJzdCByZWFkIGxvb2tzIGxpa2UgdGhlIHNhbWUgbWV0 cmljcy4NCg0KDQogIFRoZSB0aHJlZSBkcmFmdHMgY292ZXIgdGhyZWUgZmFjZXRzIG9mIGppdHRl ciBtZXRyaWNzLiBXaGF0IGlzIG1pc3NpbmcgaXMgYSByb2FkbWFwIGZvciBpbXBsZW1lbnRvcnMg dGhhdCBkb2VzIHR3byB0aGluZ3MuIFRoZSBmaXJzdCBpcyBpdCBtYWtlcyBpdCBjbGVhciB3aGVy ZSB0byBnbyB0byBkbyB3aGF0LiBJIGNhbiBlYXNpbHkgaW1hZ2luZSBhbiBpbXBsZW1lbnRvciB3 YW50aW5nIHRvIGRvIGppdHRlciBtZWFzdXJlbWVudHMsIGZpbmRpbmcganVzdCBvbmUgb2YgdGhl c2UgZHJhZnRzLCBhbmQgdGhpbmsgdGhleSBuZWVkIHRvIGRvIGEgcHJvcHJpZXRhcnkgZXh0ZW5z aW9uIGJlY2F1c2UgdGhlIElFVEYgJ2ZvcmdvdCcgdG8gaW5jbHVkZSBzb21ldGhpbmcgaW4gdGhl IGppdHRlciByZXBvcnRpbmcuIEFub3RoZXIgaXNzdWUgaXMgSSBmb3VuZCBteXNlbGYgcmVhZGlu ZyB4ci1kaXNjYXJkIGFuZCB4ci1idXJzdC1nYXAtZGlzY2FyZCBpbiBwYXJhbGxlbC4gVGhleSBt YWRlIGEgd2hvbGUgbG90IG1vcmUgc2Vuc2UgcmVhZGluZyB0aGVtIHRoYXQgd2F5IHRoYW4gb25l IGF0IGEgdGltZS4gTW9yZW92ZXIsIEkgZm91bmQgSSBoYWQgdG8gcmVhZCB0aGVtIGluIHBhcmFs bGVsIHRvIHVuZGVyc3RhbmQgeHItYnVyc3QtZ2FwLWRpc2NhcmQuIFRoZXJlZm9yZSwgaXQgd291 bGQgYmUgaGVscGZ1bCB0byBlaXRoZXIgaGF2ZSBhIHNlcGFyYXRlIHJvYWRtYXAgZG9jdW1lbnQg b3IgYSBwYXJhZ3JhcGggb3IgdHdvIGluIGVhY2ggZG9jdW1lbnQgcmVmZXJyaW5nIHRoZSByZWFk ZXIgdG8gdGhlIG90aGVyIGRvY3VtZW50cy4gVGhhdCB3YXkgdGhlIHJlYWRlciBrbm93cyB0aGV5 IGV4aXN0LCBrbm93cyB0aGVyZSBtYXkgYmUgYSBiZXR0ZXIgLyBtb3JlIGNvdmVyYWdlIGZvciBy ZXBvcnRpbmcgdGhhbiBhIHNpbmdsZSBkb2N1bWVudCBpbXBsaWVzLCBhbmQgdGhleSBjYW4gZmlu ZCB0aGUgb3RoZXIgZG9jdW1lbnRzLiBJIHdvdWxkIG9mZmVyIHRoaXMgd2lsbCBpbXByb3ZlIHRo ZSByZWFkYWJpbGl0eSBhbmQgdWx0aW1hdGUgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgcmVzdWx0 aW5nIGltcGxlbWVudGF0aW9ucy4= ------=_NextPart_000_0EED_01CE266D.3F5A8230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTM5NCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGRpcj1hdXRvIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGksRXJpYzo8L0RJVj4N CjxESVY+VGhhbmsgZm9yIHlvdXImbmJzcDtjYXJlZnVsIHJldmlldy48L0RJVj4NCjxESVY+Qm90 aCBTZWN0aW9uIDEuMSBhbmQgU2VjdGlvbiAzLjMgb2YgdGhpcyBkcmFmdCBoYXZlIGFscmVhZHkg cmVmZXJyZWQgdGhlIA0KcmVhZGVycyB0byB0aGUmbmJzcDtyZWxldmFudCBkb2N1bWVudHMgYnk8 L0RJVj4NCjxESVY+Jm5ic3A7cG9pbnRpbmcgdG8gZGlzYXJkIGRyYWZ0LiBCdXJzdCBnYXAgZGlz Y2FyZCBhbmQgZGlzY2FyZCZuYnNwO2Rvbid0IA0KbmVlZCB0byBiZSBjb3VwbGVkIHdpdGggUkxF IGRpc2NhcmQgZHJhZnQuJm5ic3A7PC9ESVY+DQo8RElWPlNvIEkgdGhpbmsmbmJzcDtpdCB3aWxs Jm5ic3A7YmUgbW9yZSB1c2VmdWwgdG8gaGF2ZSBhIHNlcGFyYXRlIHJvYWRtYXAgDQpkb2N1bWVu dCBhbmQgZ28gaW50byBkZXRhaWxzIHRvIGRpc2N1c3MgaG93IHRvPC9ESVY+DQo8RElWPiZuYnNw O2ltcGxlbWVudCB0aGVtIGluIGRpZmZlcmVudCB1c2UgY2FzZXMuPC9ESVY+DQo8RElWPjxGT05U IHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5S ZWdhcmRzPC9ESVY+DQo8RElWPi1RaW48L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRF Ui1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklH SFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8 L0I+IA0KICA8QSB0aXRsZT1lYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbSANCiAgaHJlZj0ibWFp bHRvOmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tIj5FcmljIEJ1cmdlcjwvQT4gPC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIA0K ICB0aXRsZT1kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1idXJzdC1nYXAtZGlzY2FyZEB0b29s cy5pZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWJ1 cnN0LWdhcC1kaXNjYXJkQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14 ci1idXJzdC1nYXAtZGlzY2FyZEB0b29scy5pZXRmLm9yZzwvQT4gDQogIDsgPEEgdGl0bGU9eHJi bG9jay1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzp4cmJsb2NrLWNoYWly c0B0b29scy5pZXRmLm9yZyI+eHJibG9jay1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L0E+IA0KICA8 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwv Qj4gPEEgdGl0bGU9YXBwcy1kaXNjdXNzQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86YXBwcy1k aXNjdXNzQGlldGYub3JnIj5hcHBzLWRpc2N1c3NAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IE1vbmRheSwg TWFyY2ggMTgsIDIwMTMgMTA6NTkgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBBcHBzIFJldmlldyBvZiANCiAgZHJhZnQt aWV0Zi14cmJsb2NrLXJ0Y3AteHItYnVyc3QtZ2FwLWRpc2NhcmQtMTA8L0RJVj4NCiAgPERJVj48 QlI+PC9ESVY+SW4gZ2VuZXJhbCwgdGhpcyBkb2N1bWVudCBpcyByZWFkeSB0byBnby4gSSBoYXZl IG9uZSBlZGl0b3JpYWwgDQogIHN1Z2dlc3Rpb24uIEluIG9yZGVyIHRvIHVuZGVyc3RhbmQgdGhp cyBkb2N1bWVudCwgSSBoYWQgdG8gDQogIHJlYWQmbmJzcDs8U1BBTj5kcmFmdC1pZXRmLXhyYmxv Y2stcnRjcC14ci1kaXNjYXJkLTExIA0KICBhbmQmbmJzcDtkcmFmdC1pZXRmLXhyYmxvY2stcnRj cC14ci1kaXNjYXJkLXJsZS1tZXRyaWNzLTA1PC9TUEFOPjxTUEFOIA0KICBzdHlsZT0iLXdlYmtp dC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdlYmtp dC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsg LXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMw NDY5KTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvIj4mbmJzcDt0byANCiAgZmlndXJl IG91dCB3aGVyZSB0aGlzIGRyYWZ0IGZpdHMgaW50byB0aGUgaml0dGVyIHJlcG9ydGluZyBlY29z eXN0ZW0uIEkgZ2V0IA0KICB3aHkgdGhlc2UgYXJlIGFsbCBzbWFsbCwgc2VwYXJhdGUgZHJhZnRz LiBIb3dldmVyLCBJIGNvdWxkIG5vdCBlYXNpbHkgZmluZCBhbiANCiAgb3ZlcmFyY2hpbmcgZG9j dW1lbnQgdHlpbmcgdGhpbmdzIA0KICB0b2dldGhlci4mbmJzcDs8L1NQQU4+PFNQQU4+ZHJhZnQt aWV0Zi14cmJsb2NrLXJ0Y3AteHItZGlzY2FyZC1ybGUtbWV0cmljcy0wNSANCiAgZG9lcyBhIGRl Y2VudCBqb2IgaW4gdGhlIEludHJvZHVjdGlvbiBvZiBkZXNjcmliaW5nIHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiANCiAgeHItYnVyc3QtZ2FwLWRpc2NhcmQgYW5kIHhyLWRpc2NhcmQuIEhvd2V2 ZXIsIHRoYXQgaXMgaW4gdGhlIGNvbnRleHQgb2Ygd2h5IHdlIA0KICBoYXZlIGEgdGhpcmQgZHJh ZnQgb24gd2hhdCBvbiBmaXJzdCByZWFkIGxvb2tzIGxpa2UgdGhlIHNhbWUgbWV0cmljcy48L1NQ QU4+DQogIDxESVY+PFNQQU4+PEJSPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTj5UaGUgdGhy ZWUgZHJhZnRzIGNvdmVyIHRocmVlIGZhY2V0cyBvZiBqaXR0ZXIgbWV0cmljcy4gV2hhdCBpcyAN CiAgbWlzc2luZyBpcyBhIHJvYWRtYXAgZm9yIGltcGxlbWVudG9ycyB0aGF0IGRvZXMgdHdvIHRo aW5ncy4gVGhlIGZpcnN0IGlzIGl0IA0KICBtYWtlcyBpdCBjbGVhciB3aGVyZSB0byBnbyB0byBk byB3aGF0LiBJIGNhbiBlYXNpbHkgaW1hZ2luZSBhbiBpbXBsZW1lbnRvciANCiAgd2FudGluZyB0 byBkbyBqaXR0ZXIgbWVhc3VyZW1lbnRzLCBmaW5kaW5nIGp1c3Qgb25lIG9mIHRoZXNlIGRyYWZ0 cywgYW5kIHRoaW5rIA0KICB0aGV5IG5lZWQgdG8gZG8gYSBwcm9wcmlldGFyeSBleHRlbnNpb24g YmVjYXVzZSB0aGUgSUVURiAnZm9yZ290JyB0byBpbmNsdWRlIA0KICBzb21ldGhpbmcgaW4gdGhl IGppdHRlciByZXBvcnRpbmcuIEFub3RoZXIgaXNzdWUgaXMgSSBmb3VuZCBteXNlbGYgcmVhZGlu ZyANCiAgeHItZGlzY2FyZCBhbmQgeHItYnVyc3QtZ2FwLWRpc2NhcmQgaW4gcGFyYWxsZWwuIFRo ZXkgbWFkZSBhIHdob2xlIGxvdCBtb3JlIA0KICBzZW5zZSByZWFkaW5nIHRoZW0gdGhhdCB3YXkg dGhhbiBvbmUgYXQgYSB0aW1lLiBNb3Jlb3ZlciwgSSBmb3VuZCBJIA0KICA8Qj5oYWQ8L0I+Jm5i c3A7dG8gcmVhZCB0aGVtIGluIHBhcmFsbGVsIHRvIHVuZGVyc3RhbmQgeHItYnVyc3QtZ2FwLWRp c2NhcmQuIA0KICBUaGVyZWZvcmUsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gZWl0aGVyIGhhdmUg YSBzZXBhcmF0ZSByb2FkbWFwIGRvY3VtZW50IG9yIGEgDQogIHBhcmFncmFwaCBvciB0d28gaW4g ZWFjaCBkb2N1bWVudCByZWZlcnJpbmcgdGhlIHJlYWRlciB0byB0aGUgb3RoZXIgZG9jdW1lbnRz LiANCiAgVGhhdCB3YXkgdGhlIHJlYWRlciBrbm93cyB0aGV5IGV4aXN0LCBrbm93cyB0aGVyZSBt YXkgYmUgYSBiZXR0ZXIgLyBtb3JlIA0KICBjb3ZlcmFnZSBmb3IgcmVwb3J0aW5nIHRoYW4gYSBz aW5nbGUgZG9jdW1lbnQgaW1wbGllcywgYW5kIHRoZXkgY2FuIGZpbmQgdGhlIA0KICBvdGhlciBk b2N1bWVudHMuIEkgd291bGQgb2ZmZXIgdGhpcyB3aWxsIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5 IGFuZCB1bHRpbWF0ZSANCiAgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgcmVzdWx0aW5nIA0KaW1w bGVtZW50YXRpb25zLjwvU1BBTj48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0EED_01CE266D.3F5A8230-- From paulej@packetizer.com Thu Mar 21 19:08:32 2013 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 7EBE421F86F0; Thu, 21 Mar 2013 19:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGTrfYS6wHHz; Thu, 21 Mar 2013 19:08:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19C21F86E6; Thu, 21 Mar 2013 19:08:31 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2M28CVH005306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 22:08:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363918094; bh=bc15GVl2xaDMJW/1FawH8hpFk6YTLJ0bIZ4Il1mluAw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OuwrAyv1pVFP3rfmOFuvqg4kJI7YAwFWz99H4Fh45xxHS0pQ92vueqGm+v6EqLk9t Ae5yyApRyx0baosXXeTmcbvEhG3wXhEJ+VSsvsj/bvtk4or4l8WOcMw1ZFnovPKfGb M4boRJB4lAPMwLUAFvQ2IMzUQkUV082iET/RxdLE= From: "Paul E. Jones" To: "'Alissa Cooper'" References: <20130304202424.31062.61240.idtracker@ietfa.amsl.com> <055401ce25d3$5566f120$0034d360$@packetizer.com> <8E7B73F6-808B-4D8B-BE42-73A56C475C06@cdt.org> In-Reply-To: <8E7B73F6-808B-4D8B-BE42-73A56C475C06@cdt.org> Date: Thu, 21 Mar 2013 22:08:31 -0400 Message-ID: <010f01ce26a2$2804e550$780eaff0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKDaKO5ldokcAP290Gb0nohuKjS1AOIlQ8RAuxRp2gCurAmypb89gJw Content-Language: en-us Cc: webfinger@ietf.org, ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (WebFinger) 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: Fri, 22 Mar 2013 02:08:32 -0000 Got it. Thanks! I'll make that change. Paul > -----Original Message----- > From: Alissa Cooper [mailto:acooper@cdt.org] > Sent: Thursday, March 21, 2013 9:45 AM > To: Paul E. Jones > Cc: ietf@ietf.org; apps-discuss@ietf.org; webfinger@ietf.org > Subject: Re: [apps-discuss] Last Call: 10.txt> (WebFinger) to Proposed Standard > > I suggest adding the sentence without the word "implicitly." The result > would be: > > "Further, WebFinger MUST NOT be used to provide any personal information > to any party unless explicitly authorized by the person whose > information is being shared. Publishing one's personal data within an > access-controlled or otherwise limited environment on the Internet does > not equate to providing authorization of further publication of that > data via WebFinger." > > Thanks, > Alissa > > On Mar 20, 2013, at 9:28 PM, Paul E. Jones wrote: > > > Alissa, > > > > It was suggested that we remove the word "implicit". I'm OK with > > removing it. If we did that, would you want to add this new sentence > > or a modified version of it? > > > > Paul > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > >> bounces@ietf.org] On Behalf Of Alissa Cooper > >> Sent: Monday, March 18, 2013 11:31 AM > >> To: ietf@ietf.org > >> Cc: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Last Call: >> 10.txt> (WebFinger) to Proposed Standard > >> > >> Given how little control Internet users already have over which > >> information about them appears in which context, I do not have a lot > >> of confidence that the claimed discoverability benefits of WebFinger > >> outweigh its potential to further degrade users' ability to keep > >> particular information about themselves within specific silos. > >> However, I'm coming quite late to this document, so perhaps that > >> balancing has already been discussed, and it strikes me as > >> unreasonable to try to stand in the way of publication at this point. > >> > >> Two suggestions in section 8: > >> > >> s/personal information/personal data/ (see > >> http://tools.ietf.org/html/draft-iab-privacy-considerations- > >> 06#section-2.2 -- personal data is a more widely accepted term and > >> covers a larger range of information about people) > >> > >> The normative prohibition against using WebFinger to publish personal > >> data without authorization is good, but the notion of implicit > >> authorization leaves much uncertainty about what I imagine will be a > >> use case of interest: taking information out of a controlled context > >> and making it more widely available. To make it obvious that this has > >> been considered, I would suggest adding one more sentence to the end > >> of the fourth paragraph: > >> > >> "Publishing one's personal data within an access-controlled or > >> otherwise limited environment on the Internet does not equate to > >> providing implicit authorization of further publication of that data > >> via WebFinger." > >> > >> Alissa > >> > >> On Mar 4, 2013, at 3:24 PM, The IESG wrote: > >> > >>> > >>> The IESG has received a request from the Applications Area Working > >>> Group WG (appsawg) to consider the following document: > >>> - 'WebFinger' > >>> as Proposed Standard > >>> > >>> 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 2013-03-18. > >>> 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 specification defines the WebFinger protocol, which can be > >>> used to discover information about people or other entities on the > >>> Internet using standard HTTP methods. WebFinger discovers > >>> information for a URI that might not be usable as a locator > >>> otherwise, such as account or email URIs. > >>> > >>> > >>> > >>> > >>> The file can be obtained via > >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ > >>> > >>> IESG discussion can be tracked via > >>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/ > >>> > >>> > >>> No IPR declarations have been submitted directly on this I-D. > >>> > >>> > >>> _______________________________________________ > >>> 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 paulej@packetizer.com Thu Mar 21 19:50:30 2013 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 CF39621F8F3A; Thu, 21 Mar 2013 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Em1En0uifGOX; Thu, 21 Mar 2013 19:50:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 812B721F8E65; Thu, 21 Mar 2013 19:50:28 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2M2oMMP007316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Mar 2013 22:50:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363920627; bh=pkvIqZ4sMbKUGFIjl07Opu7S/+5Mb6ODX63RVtP9Nys=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U0A+vy8Db6tSedazaoJ73jTukGM2OSE8dPFu0iuv1wzmi9QNVBrTNT0VjskkJj0NN A18MRcJ5HXTOB12Dsh30WZh7rpY90rarm+4qooiyrS0dZFkesaPFm8LLpfsWCprs4C qvx171SSjqFOhbw5OqB23Z7HqpMDiVcWrce+dpW8= From: "Paul E. Jones" To: "'Dave Cridland'" References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> In-Reply-To: Date: Thu, 21 Mar 2013 22:50:41 -0400 Message-ID: <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQEse7f/Af/Bk0eXvlbvIA== Content-Language: en-us Cc: webfinger@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 22 Mar 2013 02:50:30 -0000 Dave, > > > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines = and > > > repeats RFC 5988's =A74; I think this should be deferred = explicitly to RFC > > > 5988 in entirety, rather than specifically only for registered = link > > > relation types. > > > > > > The good news is that this should simplify the text rather a lot: > > > > > > """ > > > The value of the "rel" member is a string containing a link = relation > > > type (see RFC 5988 [4]). Both registered and extended relation = types are > > > permitted. > > > """ > > > > I do not think we can simplify the text so much. There is an = explicit > > limitation in the WebFinger draft that a "rel" value must either be = a single > > absolute URI or a registered link relation type. RFC 5988 allows = for > > multiple values like 'rel=3D"shortcut icon"', but WebFinger does = not. RFC > > 5988 also allows URIs with fragments, but WebFinger does not. Valid URIs > > must conform to Section 4.3 of RFC 3986 (Absolute URIs). These decisions > > were intended to avoid ambiguity. >=20 > Link relation types are a single one of those values, the > ABNF production, as opposed to the rel, which contains = a > . I'm entirely with you on why you want to restrict = your > rel to a single link relation type. Worth calling it out the = difference, > but it's not a deviation from RFC 5988. So, you are OK with the restriction? =20 > However, if you're changing the definition of link relation types, = then: > > a) I'm deeply concerned. Redefining a standards-track specification > seems worryingly close to NIH. There's horrible confusion lurking when > someone says "Link relation type" and then has to qualify which > definition. > > b) You need to make this absolutely clear in the document; it reads = like > you're restating, not redefining. >=20 > c) The only distinction you claim above that appears to me to be an > actual distinction is that fragments are disallowed. Yet no such > restriction exists in the current draft. I'm still missing something. How are we changing the definition of a = link relation type, aside from restricting rel to having a single value that = is either an absolute URI or a single link relation type? Perhaps what might be confusing is the part that starts with "The other members of the object have meaning only..." probably should be a = separate paragraph. The whole focus of the rest of the paragraph is to explain = that the other members of the "link relation object" can only be interpreted = once the link relation type is understood. We had no intention of changing the definition of a link relation type, though we do have the stated restrictions in 4.4.4.1: "rel" is exactly = one of either an absolute URI or a registered relation type. > > Much of the text you removed talks about the other members of the = link > > relation object, which include "type", "href", "titles", and "properties". > > The value of the "rel" member dictates how the other members are interpreted > > and so I think that text needs to remain. > Yes, I've probably trimmed too much there. > > > 2) The use of webfinger with arbitrary URIs is something I had not > > > previously realised. This raises some concerns for me, as it's not clear > > > whether this is either genuinely desirable or whether it = introduces > > > considerations (security and otherwise) beyond those discussed = within > > > the document. > > > > > > I would in general rather the mechanism were restricted to acct, = http, > > > https, and perhaps mailto. > > > > I don't think use of one URI scheme vs. another makes any difference = in > > terms of security. However, it was definitely the desire of the = group to be > > able to use any URI scheme, including some URIs like 'tel'. Use of 'tel' > > would mean the exact resolution mechanism would have to be defined, = but > > people did not want to preclude its use. For others that have a = domain > > part, the desire is to be able to go to the server and request a JRD = for > > that URI. There may or may not be information available for a given URI, > > but the procedures for one URI or another would be exactly the same. >=20 > I did say "security and otherwise". I'm not saying that any given URI > scheme should be discounted forever more, I am suggesting the document > should limit the schemes which have a defined behaviour for now. All URIs have the same defined behavior. You ask the server if it has = any information about X and it replies with a JRD if it does or 404 if it = does not. There is no difference in behavior between = acct:paulej@packetizer.com or h323:paulej@packetizer.com. Both are requesting information about = the person or thing associated with the URI. As you can see, you'll get the same answer: $ curl https://packetizer.com/.well-known/webfinger?resource=3Dacct:paulej@packe= tizer .com $ curl https://packetizer.com/.well-known/webfinger?resource=3Dh323:paulej@packe= tizer .com (Except that the aliases array is modified.) =20 > I have no clue what the possible impacts of using webfinger on a = message > id URI might be, nor do I wish to even think about it. Likely a 404. =20 > I'm pretty sure that mailto has some corner cases we've not yet = thought > about; it's not just an email address after all. On my server, that returns a JRD in the form of the example you do not = like so much. :-) It would be entirely reasonable to also return the same JRD as the acct: URI. We struggled several years with whether to use mailto or acct. = Given that some services do not have email (notably, Twitter), there were a = push for acct. That's fairly well adopted at this point, but I would not = dismiss the use of mailto if that is the identifier one has in hand. It might also be that aggsrv uses mailto to query for a JRD that has = links pointing to aggsrv documents. I outlined two ways WF could be used to = make that happen during the BoF. (But I did it with lightning speed due to = time constraints, so people might have blinked and missed it.) > > > 3) There is no use of SRV here; I would prefer an SRV resolution = step > > > for at least acct and mailto scheme URIs, and possibly http/https = as > > > well. My concern is that a corporate webserver is typically = unlikely to > > > be capable of providing webfinger services (being often externally > > > hosted), and while this could be solved by handling redirects, or = by > > > reverse proxying, SRV feels like a more stable solution here. > > > > > > I'd be curious as to whether this has been discussed. > > > > This was discussed at length, yes. We also discussed the use of the = URI > > resource record type. > > > > SRV records will tell you what host to go to, but not what URI. > > URI records will tell you more precisely what URI to query. > > > > However, both mechanisms build a dependency on DNS that will not = work in web > > browsers. One of the first uses of WebFinger (for which there are already a > > few libraries available) is to query for information about people directly > > from JavaScript in a browser. Thus, it was preferred to use a .well-known > > location rooted at the given host. >=20 > That sucks. > > It's a shame that browsers are holding back use of SRV and other > decade-old technology for things like this. But I accept that this = has > been discussed and blocked by browser brokenness. I agree. Folks have some security concerns with the prospect, though. = I'm not sure exactly what those concerns are, but it would be nice if there = was a secure was to do SRV or URI record lookups from the browser. Paul From dave@cridland.net Fri Mar 22 02:32:13 2013 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 DA99421F901C for ; Fri, 22 Mar 2013 02:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 Cy7swYFfitJ9 for ; Fri, 22 Mar 2013 02:32:10 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 216B321F8589 for ; Fri, 22 Mar 2013 02:32:10 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so4144674oag.18 for ; Fri, 22 Mar 2013 02:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eH+Ez5Rj8UiIvvZzTXcZ/BN+hif1ZGsCl89tpDr1G9M=; b=cBtHth8OVwCi17l62Wd6zUUxhlkkfZuH1tDF170gSUYh6/PspZYRm9vM2CaqJy7pty JoPegZTBVgiFR7gLoZvD/8Crss8yN7+v/qbIG0ikAtJjmQ7HIcZqbQdg2odVud2cnpqb JRMv+zeRtmfoK1qO94273k5NnLTps8zXdJsno= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=eH+Ez5Rj8UiIvvZzTXcZ/BN+hif1ZGsCl89tpDr1G9M=; b=JXeEPymE40wB8mIzJAJebB/cXYt2c1HTTmx8NiXYNiCIRbErWBOO3r3ZYvL2pZreAs 68IgDbHgAjKfPETplnRPe3aHBkmnEgjh1FC+SCjOgLUsjL81rnx2AOwNI8Mrrld64JTU Dea/qhaDLEe4VgVI64EDqGaV3yVuBzbpdKHpxra/q9OHMxzu2b781JZceioRYTwXe0GW NY82iI09qzSz0HGnk5ZUpvjqu0JdCRC+M6NGz7YabDvKlbtpDvjuzDqitRop/knOapZ7 yjf5QzbedndqOMrN3Ep9HRCNmtuVUzIFmvKsEYlzUb6bpO1ahaREX6VHyXi5j5rjE+El YjFw== MIME-Version: 1.0 X-Received: by 10.60.29.72 with SMTP id i8mr935534oeh.93.1363944729377; Fri, 22 Mar 2013 02:32:09 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 02:32:09 -0700 (PDT) In-Reply-To: <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> Date: Fri, 22 Mar 2013 09:32:09 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f80616e36004d88021be X-Gm-Message-State: ALoCoQmG+iOrIMPaG4/ImBaRsIkPA3HsuVi9XxlLU5h6jXugeNPI3vwH8MEBMPtw5jfPGqcFn3w3 Cc: webfinger@ietf.org, iesg@ietf.org, "apps-discuss@ietf.org" , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 22 Mar 2013 09:32:14 -0000 --e89a8fb1f80616e36004d88021be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 22, 2013 at 2:50 AM, Paul E. Jones wrote: > > Dave, > > > > > 1) I note that =A74.4.4.1 describes a 'rel' such that it redefines = and > > > > repeats RFC 5988's =A74; I think this should be deferred explicitly= to > RFC > > > > 5988 in entirety, rather than specifically only for registered link > > > > relation types. > > > > > > > > The good news is that this should simplify the text rather a lot: > > > > > > > > """ > > > > The value of the "rel" member is a string containing a link relatio= n > > > > type (see RFC 5988 [4]). Both registered and extended relation type= s > are > > > > permitted. > > > > """ > > > > > > I do not think we can simplify the text so much. There is an explici= t > > > limitation in the WebFinger draft that a "rel" value must either be a > single > > > absolute URI or a registered link relation type. RFC 5988 allows for > > > multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. RFC > > > 5988 also allows URIs with fragments, but WebFinger does not. Valid > URIs > > > must conform to Section 4.3 of RFC 3986 (Absolute URIs). These > decisions > > > were intended to avoid ambiguity. > > > > Link relation types are a single one of those values, the > > ABNF production, as opposed to the rel, which contains = a > > . I'm entirely with you on why you want to restrict you= r > > rel to a single link relation type. Worth calling it out the difference= , > > but it's not a deviation from RFC 5988. > > So, you are OK with the restriction? > Restricting it to a single link relation type (as defined by RFC 5988, and the ABNF production therein) is perfectly fine. > > > However, if you're changing the definition of link relation types, then= : > > > > a) I'm deeply concerned. Redefining a standards-track specification > > seems worryingly close to NIH. There's horrible confusion lurking when > > someone says "Link relation type" and then has to qualify which > > definition. > > > > b) You need to make this absolutely clear in the document; it reads lik= e > > you're restating, not redefining. > > > > c) The only distinction you claim above that appears to me to be an > > actual distinction is that fragments are disallowed. Yet no such > > restriction exists in the current draft. > > I'm still missing something. How are we changing the definition of a lin= k > relation type, aside from restricting rel to having a single value that i= s > either an absolute URI or a single link relation type? > So, you said, broken apart for readability: >>> RFC 5988 allows for multiple values like 'rel=3D"shortcut icon"', but WebFinger does not. I see that RFC 5988 allows its 'rel' parameter to hold multiple Link Relation Types, yes. I agree that restricting this is reasonable. (I have no view on whether it's sensible). However, that's referring to the RFC 5988 "rel" parameter (or attribute), and absolutely not the definition of Link Relation Type, which is always a single registered token or an absolute URI (which itself SHOULD be lowercased). >>> RFC 5988 also allows URIs with fragments, but WebFinger does not. Your current draft makes no restriction on whether a Link Relation Type may have a fragment or not. It stipulates an absolute URI, which in RFC 3986 may have a fragment; therefore this restriction is not in the draft as written. Neither is it in RFC 5988; however if you do intend adding this restriction then this represents a deviation. >>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs). I'm not sure if you considered this a difference or not; as far as I can tell RFC 5988 only allows absolute URIs (of the extended relation types), though it explicitly calls out this requirement for the Link header itself. Either way this seems reasonable, and not a deviation. > > We had no intention of changing the definition of a link relation type, > though we do have the stated restrictions in 4.4.4.1: "rel" is exactly on= e > of either an absolute URI or a registered relation type. > Right, which is a Link Relation Type as defined in RFC 5988. Either you have changed the definition (or at least, rel doesn't hold a link relation type), in which case my opinion remains that this is a bad thing, but in any case needs to be made abundantly clear in the document... ... or you haven't, in which case I don't understand why you won't simply reference RFC 5988 instead of referencing it piecemeal. > > > I have no clue what the possible impacts of using webfinger on a messag= e > > id URI might be, nor do I wish to even think about it. > > Likely a 404. > I don't think whether it works is the sole consideration. > > > I'm pretty sure that mailto has some corner cases we've not yet thought > > about; it's not just an email address after all. > > On my server, that returns a JRD in the form of the example you do not like > so much. :-) > I said corner cases. Please read RFC 6068; you appear to be labouring under the assumption that a mailto URI is identical to an acct URI except for the scheme. > > It would be entirely reasonable to also return the same JRD as the acct: > URI. We struggled several years with whether to use mailto or acct. Given > that some services do not have email (notably, Twitter), there were a pus= h > for acct. That's fairly well adopted at this point, but I would not dismiss > the use of mailto if that is the identifier one has in hand. > I don't think mailto is nearly as simple as you seem to think it is. I don't know enough about other URI schemes to know whether other schemes have the same problem. My issue here is not a matter of the good things that might reasonably happen from careful use of simple URIs with arbitrary schemes; my concern is that there may be bad things with odd cases and there's no evidence that these have been thought through. So for mailto, for example, I'd think you want to restrict the URI form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid any other forms. What I don't know - and given the way URIs can have entertaining corner cases like this, what worries me - is not only whether the whole thing works if you have an odd URI construct (mailto or no), but whether it's safe. I think as you look deeply into various URI schemes, there'll be cans of worms in a number of places, and the safer thing to do is to restrict the schemes and URI forms that are - currently - allowed. Look on the bright side, you'll have the fun of specifying what a telnet URI should give you back from WF. At the very least, I'd suggest that you add a security consideration > > It might also be that aggsrv uses mailto to query for a JRD that has link= s > pointing to aggsrv documents. I outlined two ways WF could be used to make > that happen during the BoF. (But I did it with lightning speed due to time > constraints, so people might have blinked and missed it.) > I listened to your presentation with interest, I've not yet formed a view on how aggsrv ought to work, and I've personally not ruled out that WebFinger ought to play a role in it. I've no "anti WF" axe to grind here; in fact I'd have unequivocally supported using WF if it weren't for the lack of SRV, which leaves me undecided. I'm just concerned that this has the potential to be sidestepping the standardization process inadvertently. Dave. --e89a8fb1f80616e36004d88021be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 22, 2013 at 2:50 AM, Paul E. Jones <paulej@packetizer.com> wrote:
&= gt;
> Dave,
>
> > > > 1) I note that =A74.4.4.1 = describes a 'rel' such that it redefines and
> > > > repeats RFC 5988's =A74; I think this should be def= erred explicitly to
> RFC
> > > > 5988 in entirety, ra= ther than specifically only for registered link
> > > > rela= tion types.
> > > >
> > > > The good news is that this shoul= d simplify the text rather a lot:
> > > >
> > > = > """
> > > > The value of the "rel&q= uot; member is a string containing a link relation
> > > > type (see RFC 5988 [4]). Both registered and extended r= elation types
> are
> > > > permitted.
> > &g= t; > =A0"""
> > >
> > > I do not = think we can simplify the text so much. =A0There is an explicit
> > > limitation in the WebFinger draft that a "rel" val= ue must either be a
> single
> > > absolute URI or a regi= stered link relation type. =A0RFC 5988 allows for
> > > multipl= e values like 'rel=3D"shortcut icon"', but WebFinger does= not. =A0RFC
> > > 5988 also allows URIs with fragments, but WebFinger does not= . =A0Valid
> URIs
> > > must conform to Section 4.3 of RF= C 3986 (Absolute URIs). =A0These
> decisions
> > > were i= ntended to avoid ambiguity.
> >
> > Link relation types are a single one of those values= , the
> > <relation-type> ABNF production, as opposed to the= rel, which contains a
> > <relation-types>. I'm entirel= y with you on why you want to restrict your
> > rel to a single link relation type. Worth calling it out the diff= erence,
> > but it's not a deviation from RFC 5988.
>> So, you are OK with the restriction?
>

Restricting it to= a single link relation type (as defined by RFC 5988, and the <relation-= type> ABNF production therein) is perfectly fine.
=A0
>
> > However, if you're changing the definition of = link relation types, then:
> >
> > a) I'm deeply conc= erned. Redefining a standards-track specification
> > seems worryi= ngly close to NIH. There's horrible confusion lurking when
> > someone says "Link relation type" and then has to quali= fy which
> > definition.
> >
> > b) You need to = make this absolutely clear in the document; it reads like
> > you&= #39;re restating, not redefining.
> >
> > c) The only distinction you claim above that appears= to me to be an
> > actual distinction is that fragments are disal= lowed. Yet no such
> > restriction exists in the current draft. >
> I'm still missing something. =A0How are we changing the de= finition of a link
> relation type, aside from restricting rel to hav= ing a single value that is
> either an absolute URI or a single link = relation type?
>

So, you said, broken apart for readability:

>>>= RFC 5988 allows for multiple values like 'rel=3D"shortcut icon&qu= ot;', but WebFinger does not.

I see that RFC 5988 allows its = 9;rel' parameter to hold multiple Link Relation Types, yes. I agree tha= t restricting this is reasonable. (I have no view on whether it's sensi= ble). However, that's referring to the RFC 5988 "rel" paramet= er (or attribute), and absolutely not the definition of Link Relation Type,= which is always a single registered token or an absolute URI (which itself= SHOULD be lowercased).

>>> RFC 5988 also allows URIs with fragments, but WebFinger do= es not.

Your current draft makes no restriction on whether a Link Re= lation Type may have a fragment or not. It stipulates an absolute URI, whic= h in RFC 3986 may have a fragment; therefore this restriction is not in the= draft as written. Neither is it in RFC 5988; however if you do intend addi= ng this restriction then this represents a deviation.

>>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolu= te URIs).

I'm not sure if you considered this a difference or no= t; as far as I can tell RFC 5988 only allows absolute URIs (of the extended= relation types), though it explicitly calls out this requirement for the L= ink header itself. Either way this seems reasonable, and not a deviation. =A0
>
> We had no intention of changing the definition of a lin= k relation type,
> though we do have the stated restrictions in 4.4.4.1: "rel" is exactly one
> o= f either an absolute URI or a registered relation type.
>

Right, which is a Link Relation Type as defined in RFC 5988.
Either you have changed the definition (or at least, rel doesn't h= old a link relation type), in which case my opinion remains that this is a = bad thing, but in any case needs to be made abundantly clear in the documen= t...

... or you haven't, in which case I don't understand why you wo= n't simply reference RFC 5988 instead of referencing it piecemeal.
= =A0
>
> > I have no clue what the possible impacts of using = webfinger on a message
> > id URI might be, nor do I wish to even think about it.
>> Likely a 404.
>

I don't think whether it works is th= e sole consideration.
=A0
>
> > I'm pretty sure that = mailto has some corner cases we've not yet thought
> > about; it's not just an email address after all.
>
&= gt; On my server, that returns a JRD in the form of the example you do not = like
> so much. :-)
>

I said corner cases. Please read R= FC 6068; you appear to be labouring under the assumption that a mailto URI = is identical to an acct URI except for the scheme.
=A0
>
> It would be entirely reasonable to also return the same= JRD as the acct:
> URI. =A0We struggled several years with whether t= o use mailto or acct. =A0Given
> that some services do not have email= (notably, Twitter), there were a push
> for acct. =A0That's fairly well adopted at this point, but I would= not dismiss
> the use of mailto if that is the identifier one has in= hand.
>

I don't think mailto is nearly as simple as you s= eem to think it is. I don't know enough about other URI schemes to know= whether other schemes have the same problem.

My issue here is not a matter of the good things that might reasonably = happen from careful use of simple URIs with arbitrary schemes; my concern i= s that there may be bad things with odd cases and there's no evidence t= hat these have been thought through.

So for mailto, for example, I'd think you want to restrict the URI = form used to being, using RFC 6068's ABNF, '"mailto:" to&= #39;, and avoid any other forms. What I don't know - and given the way = URIs can have entertaining corner cases like this, what worries me - is not= only whether the whole thing works if you have an odd URI construct (mailt= o or no), but whether it's safe.

I think as you look deeply into various URI schemes, there'll be ca= ns of worms in a number of places, and the safer thing to do is to restrict= the schemes and URI forms that are - currently - allowed. Look on the brig= ht side, you'll have the fun of specifying what a telnet URI should giv= e you back from WF.

At the very least, I'd suggest that you add a security consideratio= n
=A0
>
> It might also be that aggsrv uses mailto to query= for a JRD that has links
> pointing to aggsrv documents. =A0I outlin= ed two ways WF could be used to make
> that happen during the BoF. =A0(But I did it with lightning speed due = to time
> constraints, so people might have blinked and missed it.)>

I listened to your presentation with interest, I've not y= et formed a view on how aggsrv ought to work, and I've personally not r= uled out that WebFinger ought to play a role in it. I've no "anti = WF" axe to grind here; in fact I'd have unequivocally supported us= ing WF if it weren't for the lack of SRV, which leaves me undecided.
I'm just concerned that this has the potential to be sidestepping t= he standardization process inadvertently.

Dave.
--e89a8fb1f80616e36004d88021be-- From mike5guo@gmail.com Fri Mar 22 07:53:35 2013 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 83B5821F8696 for ; Fri, 22 Mar 2013 07:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 1ljjM3mc-uDw for ; Fri, 22 Mar 2013 07:53:34 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id AABFE21F867D for ; Fri, 22 Mar 2013 07:53:34 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id k1so4410214oag.5 for ; Fri, 22 Mar 2013 07:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=24W5cP43TDX0LLMlmUiQ/HuJIAnc5aHCKF+v/i7f2HI=; b=IgCLHaEWmZNeFUEsKyB325Ci0D2j6tulVCoXZ15clvOOBzPH5n2bPaTNKwXlv+jOuP /UN0IXK+HKodK9XSVpB5k+2DPNuUzeOCF6JrBktfs1h6DDgOtjD2dJdP8YKIpxO1jrLy adECkxDCzJYqP25KZNJBRSqc+GDn4+9jmPv7eJuW1rqju/ehATnBHUPYQWJIqEqN5lK7 E9tkcQ8hy7BJzbkCN4PTYkFLaqCP1lhFqrk8e8jdGXo7ZTJZMqeG6OqrzvKNthX4eeWl /nseWMd6uU/+0/3K+TwDypKOWNljf50S70IdcS5tkb613COE5o5fD2bExaP4cIF/9iYm 9AGw== MIME-Version: 1.0 X-Received: by 10.60.21.104 with SMTP id u8mr1999844oee.99.1363964014287; Fri, 22 Mar 2013 07:53:34 -0700 (PDT) Received: by 10.182.81.164 with HTTP; Fri, 22 Mar 2013 07:53:33 -0700 (PDT) Date: Fri, 22 Mar 2013 22:53:33 +0800 Message-ID: From: Zhun Guo To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c6d68ee1b504d8849eec Subject: [apps-discuss] The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format 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, 22 Mar 2013 14:53:35 -0000 --e89a8ff1c6d68ee1b504d8849eec Content-Type: text/plain; charset=ISO-8859-1 Dear All: I submitted a I-D ,please give me more help! Thanks! Best Regards! Zhun Guo A new version of I-D, draft-guo-idoca-with-the-html-file-format-00.txt has been successfully submitted by Zhun Guo and posted to the IETF repository. Filename: draft-guo-idoca-with-the-html-file-format Revision: 00 Title: The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format Creation date: 2013-03-22 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-guo-idoca-with-the-html-file-format-00.txt Status: http://datatracker.ietf.org/doc/draft-guo-idoca-with-the-html-file-format Htmlized: http://tools.ietf.org/html/draft-guo-idoca-with-the-html-file-format-00 --e89a8ff1c6d68ee1b504d8849eec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All:
=A0 =A0 =A0I submitted a I-D ,please give me more help! Thank= s!
Best Regards!

Zhun Guo

=
A new version of I-D, dra= ft-guo-idoca-with-the-html-fi= le-format-00.txt
has been successfully submitted by Z= hun Guo and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-guo-idoca-with-the-html-file-format
Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 The Inter= connection and Interoperability of Different Cloud-office Applications (IDC= OA) with the HTML File Format
Creation date: =A0 2013-03-22=
Group: =A0 =A0 =A0 =A0 =A0 Individua= l Submission
Number of pages: 5
URL: =A0 =A0 =A0 =A0 =A0 =A0=A0http://www.ietf.org/internet-drafts/draft-guo-idoca-with-the-html-file-for= mat-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatra= cker.ietf.org/doc/draft-guo-idoca-with-the-html-file-format
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.= org/html/draft-guo-idoca-with-the-html-file-format-00
--e89a8ff1c6d68ee1b504d8849eec-- From paulej@packetizer.com Fri Mar 22 08:16:32 2013 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 072B921F8F01; Fri, 22 Mar 2013 08:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 u3z2TTbgirUs; Fri, 22 Mar 2013 08:16:26 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ECD0321F8EF1; Fri, 22 Mar 2013 08:16:25 -0700 (PDT) Received: from [192.168.1.19] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2MFGNi3015976 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 11:16:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1363965384; bh=7a83uDr5EDTG9Kf9emd+v/AFsvvVP7O6azmaWPqeoc8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=skaBayv5WATam/Uy5VKln3LoiQqaUCtbkgc9aeq9ScDMzokNeJ/QX8J3E8HVrKiBp Pr2UwBUNpUspwkw9px4SIYi0DEm0LQ34mSYkkXN7cE/FP6qJ9G/4TkdU7ViZsXBL91 plB0+xRxstjQs9z2I1J9Kk0ybX3JGwKXAuJ+go8o= Message-ID: <514C75C2.8050004@packetizer.com> Date: Fri, 22 Mar 2013 11:16:18 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Dave Cridland References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000203060508040002010601" Cc: webfinger@ietf.org, iesg@ietf.org, "apps-discuss@ietf.org" , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 22 Mar 2013 15:16:32 -0000 This is a multi-part message in MIME format. --------------000203060508040002010601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dave, On 3/22/2013 5:32 AM, Dave Cridland wrote: > > > > So, you are OK with the restriction? > > > > Restricting it to a single link relation type (as defined by RFC 5988, > and the ABNF production therein) is perfectly fine. OK > > > > > > However, if you're changing the definition of link relation types, > then: > > > > > > a) I'm deeply concerned. Redefining a standards-track specification > > > seems worryingly close to NIH. There's horrible confusion lurking when > > > someone says "Link relation type" and then has to qualify which > > > definition. > > > > > > b) You need to make this absolutely clear in the document; it > reads like > > > you're restating, not redefining. > > > > > > c) The only distinction you claim above that appears to me to be an > > > actual distinction is that fragments are disallowed. Yet no such > > > restriction exists in the current draft. > > > > I'm still missing something. How are we changing the definition of > a link > > relation type, aside from restricting rel to having a single value > that is > > either an absolute URI or a single link relation type? > > > > So, you said, broken apart for readability: > > >>> RFC 5988 allows for multiple values like 'rel="shortcut icon"', > but WebFinger does not. > > I see that RFC 5988 allows its 'rel' parameter to hold multiple Link > Relation Types, yes. I agree that restricting this is reasonable. (I > have no view on whether it's sensible). However, that's referring to > the RFC 5988 "rel" parameter (or attribute), and absolutely not the > definition of Link Relation Type, which is always a single registered > token or an absolute URI (which itself SHOULD be lowercased). RFC 5988 says that "extension relation types are REQUIRED to be absolute URIs in Link headers". However, we cannot simply assume that "Link Headers" also means "Link Relation Objects" in WebFinger. That's why we make it clear: 'The value of the "rel" member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]).' So, I don't see an issue with that sentence. The rest of the first paragraph in the WF spec (up to the point where I'm proposing the paragraph break) would then read: "The value of the "rel" member MUST contain exactly one URI or registered relation type. The URI or registered relation type identifies the type of the link relation." Any concern with this part? > >>> RFC 5988 also allows URIs with fragments, but WebFinger does not. > > Your current draft makes no restriction on whether a Link Relation > Type may have a fragment or not. It stipulates an absolute URI, which > in RFC 3986 may have a fragment; therefore this restriction is not in > the draft as written. Neither is it in RFC 5988; however if you do > intend adding this restriction then this represents a deviation. The WF spec says link relation types MUST be either absolute URIs or registered a registered relation type. Per RFC 3986, absolute URIs do not have fragments (See Section 4.3). RFC 5988 also requires use of absolute URIs when used in Link Headers. Perhaps the intent was to always require absolute URIs? I don't know, since the text limits the statement to "Link Headers". WebFinger wants the same restriction, so we inserted an explicit statement. > >>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs). > > I'm not sure if you considered this a difference or not; as far as I > can tell RFC 5988 only allows absolute URIs (of the extended relation > types), though it explicitly calls out this requirement for the Link > header itself. Either way this seems reasonable, and not a deviation. It does, but the document is scoped for HTTP headers. We need an explicit statement for WEbFinger, since it's not HTTP headers and RFC 5988 limits the absolute URI wording to Link headers. > > > > > We had no intention of changing the definition of a link relation type, > > though we do have the stated restrictions in 4.4.4.1 > : "rel" is exactly one > > of either an absolute URI or a registered relation type. > > > > Right, which is a Link Relation Type as defined in RFC 5988. > > Either you have changed the definition (or at least, rel doesn't hold > a link relation type), in which case my opinion remains that this is a > bad thing, but in any case needs to be made abundantly clear in the > document... > > ... or you haven't, in which case I don't understand why you won't > simply reference RFC 5988 instead of referencing it piecemeal. We tried referencing RFC 5988 as much as we could. But, since that text speaks explicitly of HTTP Link Headers and places restrictions only there in the text, while the ABNF is more relaxes, we felt it was necessary to state more-or-less the same "absolute URI" requirement in WebFinger. I don't see this as a re-definition. I do think it's valuable, as it makes it clear. So, we have these two paragraphs now in that section: The value of the "rel" member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]). The value of the "rel" member MUST contain exactly one URI or registered relation type. The URI or registered relation type identifies the type of the link relation. The other members of the object have meaning only once the type of link relation is understood. In some instances, the link relation will have associated semantics enabling the client to query for other resources on the Internet. In other instances, the link relation will have associated semantics enabling the client to utilize the other members of the link relation object without fetching additional external resources. The first paragraph has to do with the "rel" values, leaning on RFC 5988, but being explicit in applying the same "absolute URI" requirement. It does add the restriction of not allowing more than one value inside "rel" (whereas RFC 5988 allow for an unlimited number). The second paragraph as WF-specific, talking about the other members of the "link relation object", which is something specific to WF. > > > > > I have no clue what the possible impacts of using webfinger on a > message > > > id URI might be, nor do I wish to even think about it. > > > > Likely a 404. > > > > I don't think whether it works is the sole consideration. > Agreed. > > > > > I'm pretty sure that mailto has some corner cases we've not yet > thought > > > about; it's not just an email address after all. > > > > On my server, that returns a JRD in the form of the example you do > not like > > so much. :-) > > > > I said corner cases. Please read RFC 6068; you appear to be labouring > under the assumption that a mailto URI is identical to an acct URI > except for the scheme. > I make no assumption. With WF, a URI of any form is just a "resource" identifier. Given that identifier, one gets back a JRD. > > > > It would be entirely reasonable to also return the same JRD as the acct: > > URI. We struggled several years with whether to use mailto or acct. > Given > > that some services do not have email (notably, Twitter), there were > a push > > for acct. That's fairly well adopted at this point, but I would not > dismiss > > the use of mailto if that is the identifier one has in hand. > > > > I don't think mailto is nearly as simple as you seem to think it is. I > don't know enough about other URI schemes to know whether other > schemes have the same problem. I'm quite familiar with mailto URIs and recognize that they're complex, or can be. > > My issue here is not a matter of the good things that might reasonably > happen from careful use of simple URIs with arbitrary schemes; my > concern is that there may be bad things with odd cases and there's no > evidence that these have been thought through. Nothing "bad" can happen. Either a WF query returns useful information or it does not. Use of any particular URI scheme will come about either through common usage or through standardization efforts. > > So for mailto, for example, I'd think you want to restrict the URI > form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid > any other forms. What I don't know - and given the way URIs can have > entertaining corner cases like this, what worries me - is not only > whether the whole thing works if you have an odd URI construct (mailto > or no), but whether it's safe. > > I think as you look deeply into various URI schemes, there'll be cans > of worms in a number of places, and the safer thing to do is to > restrict the schemes and URI forms that are - currently - allowed. > Look on the bright side, you'll have the fun of specifying what a > telnet URI should give you back from WF. URI schemes can have many forms, have parameters, etc. They range from simple to complex. However, a WF server that accepts any given URI scheme will understand that URI scheme and will return useful information. If it does not understand the scheme (or does not have information for the particular URI), it will return a 404. I strongly believe we should allow use of any URI scheme. Any complexities that arise will either be addressed through common usage or as part of a standardization effort. > > At the very least, I'd suggest that you add a security consideration What should we add? I'm not seeing any new or different security issues arising from use of any particular URI scheme. Every URI returns either a JRD or it does not. What would be different with mailto, http, sip, tel, gopher, or any other scheme? Paul --------------000203060508040002010601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dave,

On 3/22/2013 5:32 AM, Dave Cridland wrote:
>
> So, you are OK with the restriction?
>

Restricting it to a single link relation type (as defined by RFC 5988, and the <relation-type> ABNF production therein) is perfectly fine.

OK


>
> > However, if you're changing the definition of link relation types, then:
> >
> > a) I'm deeply concerned. Redefining a standards-track specification
> > seems worryingly close to NIH. There's horrible confusion lurking when
> > someone says "Link relation type" and then has to qualify which
> > definition.
> >
> > b) You need to make this absolutely clear in the document; it reads like
> > you're restating, not redefining.
> >
> > c) The only distinction you claim above that appears to me to be an
> > actual distinction is that fragments are disallowed. Yet no such
> > restriction exists in the current draft.
>
> I'm still missing something.  How are we changing the definition of a link
> relation type, aside from restricting rel to having a single value that is
> either an absolute URI or a single link relation type?
>

So, you said, broken apart for readability:

>>> RFC 5988 allows for multiple values like 'rel="shortcut icon"', but WebFinger does not.

I see that RFC 5988 allows its 'rel' parameter to hold multiple Link Relation Types, yes. I agree that restricting this is reasonable. (I have no view on whether it's sensible). However, that's referring to the RFC 5988 "rel" parameter (or attribute), and absolutely not the definition of Link Relation Type, which is always a single registered token or an absolute URI (which itself SHOULD be lowercased).

RFC 5988 says that "extension relation types are REQUIRED to be absolute URIs in Link headers".  However, we cannot simply assume that "Link Headers" also means "Link Relation Objects" in WebFinger.

That's why we make it clear:

'The value of the "rel" member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]).'

So, I don't see an issue with that sentence.  The rest of the first paragraph in the WF spec (up to the point where I'm proposing the paragraph break) would then read:

"The value of the “rel” member MUST contain exactly one URI or registered relation type.  The URI or registered relation type identifies the type of the link relation."

Any concern with this part?

>>> RFC 5988 also allows URIs with fragments, but WebFinger does not.

Your current draft makes no restriction on whether a Link Relation Type may have a fragment or not. It stipulates an absolute URI, which in RFC 3986 may have a fragment; therefore this restriction is not in the draft as written. Neither is it in RFC 5988; however if you do intend adding this restriction then this represents a deviation.

The WF spec says link relation types MUST be either absolute URIs or registered a registered relation type.  Per RFC 3986, absolute URIs do not have fragments (See Section 4.3).  RFC 5988 also requires use of absolute URIs when used in Link Headers.  Perhaps the intent was to always require absolute URIs?  I don't know, since the text limits the statement to "Link Headers".  WebFinger wants the same restriction, so we inserted an explicit statement.

>>> Valid URIs must conform to Section 4.3 of RFC 3986 (Absolute URIs).

I'm not sure if you considered this a difference or not; as far as I can tell RFC 5988 only allows absolute URIs (of the extended relation types), though it explicitly calls out this requirement for the Link header itself. Either way this seems reasonable, and not a deviation.

It does, but the document is scoped for HTTP headers.  We need an explicit statement for WEbFinger, since it's not HTTP headers and RFC 5988 limits the absolute URI wording to Link headers.

 
>
> We had no intention of changing the definition of a link relation type,
> though we do have the stated restrictions in 4.4.4.1: "rel" is exactly one
> of either an absolute URI or a registered relation type.
>

Right, which is a Link Relation Type as defined in RFC 5988.

Either you have changed the definition (or at least, rel doesn't hold a link relation type), in which case my opinion remains that this is a bad thing, but in any case needs to be made abundantly clear in the document...

... or you haven't, in which case I don't understand why you won't simply reference RFC 5988 instead of referencing it piecemeal.

We tried referencing RFC 5988 as much as we could.  But, since that text speaks explicitly of HTTP Link Headers and places restrictions only there in the text, while the ABNF is more relaxes, we felt it was necessary to state more-or-less the same "absolute URI" requirement in WebFinger.

I don't see this as a re-definition.  I do think it's valuable, as it makes it clear.

So, we have these two paragraphs now in that section:

The value of the “rel” member is a string that is either an absolute URI or a registered relation type [10] (see RFC 5988 [4]).  The value of the “rel” member MUST contain exactly one URI or registered relation type.  The URI or registered relation type identifies the type of the link relation. 

The other members of the object have meaning only once the type of link relation is understood.  In some instances, the link relation will have associated semantics enabling the client to query for other resources on the Internet.  In other instances, the link relation will have associated semantics enabling the client to utilize the other members of the link relation object without fetching additional external resources.

The first paragraph has to do with the "rel" values, leaning on RFC 5988, but being explicit in applying the same "absolute URI" requirement.  It does add the restriction of not allowing more than one value inside "rel" (whereas RFC 5988 allow for an unlimited number).  The second paragraph as WF-specific, talking about the other members of the "link relation object", which is something specific to WF.

>
> > I have no clue what the possible impacts of using webfinger on a message
> > id URI might be, nor do I wish to even think about it.
>
> Likely a 404.
>

I don't think whether it works is the sole consideration.
 

Agreed.

>
> > I'm pretty sure that mailto has some corner cases we've not yet thought
> > about; it's not just an email address after all.
>
> On my server, that returns a JRD in the form of the example you do not like
> so much. :-)
>

I said corner cases. Please read RFC 6068; you appear to be labouring under the assumption that a mailto URI is identical to an acct URI except for the scheme.
 

I make no assumption.  With WF, a URI of any form is just a "resource" identifier.  Given that identifier, one gets back a JRD.

>
> It would be entirely reasonable to also return the same JRD as the acct:
> URI.  We struggled several years with whether to use mailto or acct.  Given
> that some services do not have email (notably, Twitter), there were a push
> for acct.  That's fairly well adopted at this point, but I would not dismiss
> the use of mailto if that is the identifier one has in hand.
>

I don't think mailto is nearly as simple as you seem to think it is. I don't know enough about other URI schemes to know whether other schemes have the same problem.

I'm quite familiar with mailto URIs and recognize that they're complex, or can be.


My issue here is not a matter of the good things that might reasonably happen from careful use of simple URIs with arbitrary schemes; my concern is that there may be bad things with odd cases and there's no evidence that these have been thought through.

Nothing "bad" can happen.  Either a WF query returns useful information or it does not.  Use of any particular URI scheme will come about either through common usage or through standardization efforts.


So for mailto, for example, I'd think you want to restrict the URI form used to being, using RFC 6068's ABNF, '"mailto:" to', and avoid any other forms. What I don't know - and given the way URIs can have entertaining corner cases like this, what worries me - is not only whether the whole thing works if you have an odd URI construct (mailto or no), but whether it's safe.

I think as you look deeply into various URI schemes, there'll be cans of worms in a number of places, and the safer thing to do is to restrict the schemes and URI forms that are - currently - allowed. Look on the bright side, you'll have the fun of specifying what a telnet URI should give you back from WF.

URI schemes can have many forms, have parameters, etc.  They range from simple to complex.  However, a WF server that accepts any given URI scheme will understand that URI scheme and will return useful information.  If it does not understand the scheme (or does not have information for the particular URI), it will return a 404.

I strongly believe we should allow use of any URI scheme.  Any complexities that arise will either be addressed through common usage or as part of a standardization effort.


At the very least, I'd suggest that you add a security consideration

What should we add?  I'm not seeing any new or different security issues arising from use of any particular URI scheme.  Every URI returns either a JRD or it does not.  What would be different with mailto, http, sip, tel, gopher, or any other scheme?

Paul

--------------000203060508040002010601-- From rjsparks@nostrum.com Fri Mar 22 08:59:31 2013 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 70A7621F8E72 for ; Fri, 22 Mar 2013 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, SPF_PASS=-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 LwBiqn2bUiKF for ; Fri, 22 Mar 2013 08:59:31 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A79F421F8E6B for ; Fri, 22 Mar 2013 08:59:30 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2MFxU2S028076 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 10:59:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <514C7FE2.9020405@nostrum.com> Date: Fri, 22 Mar 2013 10:59:30 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org, "rai-ads@tools.ietf.org" References: <5124D91C.1000703@berkeley.edu> <000901ce1023$3c4b7140$4001a8c0@gateway.2wire.net> <51263634.7040906@berkeley.edu> <015e01ce1052$3098b540$4001a8c0@gateway.2wire.net> <5128ED20.6030502@berkeley.edu> <512E1574.50504@berkeley.edu> <015c01ce15c9$17585dc0$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [apps-discuss] draft-wilde-xml-patch and updates to RFC 5261 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, 22 Mar 2013 15:59:31 -0000 On 2/28/13 9:51 AM, Barry Leiba wrote: >> You posted errata against RFC5261, an RFC which was produced by simple. >> Therefore notification of the errata went to the simple WG mailing list >> which was shut down two days ago so your good work has found a very >> effective black hole. > ... >> Normally, the AD picks up an erratum and runs with it but since the WG >> has shut down, doubtless the ADs have as well, so you will need to find >> a friendly AD elsewhere > This is nonsensical. > > Errata are associated with the area that the document was produced > in.[1] Even if the RFC came from an individual submission (no WG) or > from a WG that has closed (recently, or years ago), the ADs for the > area the report is assigned to will see it, and will eventually deal > with it. The IESG has been putting more emphasis, over the past > couple of years, on handling errata and keeping the number left at > "Reported" to an absolute minimum. > > The RAI ADs will deal with this one, I'm sure. Just to confirm - these have not gone into a black hole. > > Barry > > > [1] Errata against very old RFCs can get into a sort of "black hole" > situation if they are not assigned to an area. That's not an issue in > this case. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From superuser@gmail.com Fri Mar 22 09:48:03 2013 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 BAAF521F8DCF for ; Fri, 22 Mar 2013 09:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BIpM2lxNWm0D for ; Fri, 22 Mar 2013 09:48:03 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 111AA21F8928 for ; Fri, 22 Mar 2013 09:48:02 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t11so1345250wey.34 for ; Fri, 22 Mar 2013 09:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=it1eMCd4L1I8WXeioeB1gHKQJG9MmGPtfLHdtkL2eCE=; b=Fpt0t4Q8LmlcmxvNvjP2vcMJRHD5D6Sd7Babo8JqoY3NzHJNb4I/5RlvMjdWsTIVOr A0PXpvEppZexK376GUXmAVVDeWdbbrAOHr21RSdHAUSubt047dvQGkRqqbeANGq7yDE9 meoKPi+lzQB/EAoOjBEs3U8yHta9o/yJ6rEMsdl5YQkjh+XiqS2JmpZCypCy/dX8i2cZ 6dpnIpVoJENodXxTufsjoGBCduGgz5Jd+/fgPvlewyfTwBrs/WrrsnBMYZVGALQAxvKQ 7Hb8oFdG/Ly32sNCAch6tw2VVSz463uHywkUb8mpxSu58owUXMVX0idWxdOui99DsCxl cLWA== MIME-Version: 1.0 X-Received: by 10.180.187.129 with SMTP id fs1mr4353314wic.5.1363970882120; Fri, 22 Mar 2013 09:48:02 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 22 Mar 2013 09:48:01 -0700 (PDT) Date: Fri, 22 Mar 2013 09:48:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c26722e9b3b004d88637dd Subject: [apps-discuss] Authentication-Results 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, 22 Mar 2013 16:48:03 -0000 --001a11c26722e9b3b004d88637dd Content-Type: text/plain; charset=ISO-8859-1 Colleagues, As you've seen already, I'm working on a revision to RFC5451. Thanks to Alessandro Vesely and Dave Cridland for their reviews and comments; I'll have a revision out shortly that addresses these. A Proposed Standard "bis" effort always benefits from describing extant implementations. I know about the ones I've written, and about some very public uses of it (Gmail, Yahoo, for example). If there's anyone in this audience that knows of others, I'd love to hear about it. Finally, are there any objections to processing this through APPSAWG? I can't shepherd it as I'm editing, so either Salvatore will, or we'll find a volunteer to do so. Thanks, -MSK --001a11c26722e9b3b004d88637dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<participant>

Colleagues,

As you've seen already, I'm working o= n a revision to RFC5451.=A0 Thanks to Alessandro Vesely and Dave Cridland f= or their reviews and comments; I'll have a revision out shortly that ad= dresses these.

A Proposed Standard "bis" effort always benefits from d= escribing extant implementations.=A0 I know about the ones I've written= , and about some very public uses of it (Gmail, Yahoo, for example).=A0 If = there's anyone in this audience that knows of others, I'd love to h= ear about it.

Finally, are there any objections to processing this through= APPSAWG?=A0 I can't shepherd it as I'm editing, so either Salvator= e will, or we'll find a volunteer to do so.

Thanks,
-MSK

</participant>
--001a11c26722e9b3b004d88637dd-- From dave@cridland.net Fri Mar 22 09:53:37 2013 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 F1CF921F8928 for ; Fri, 22 Mar 2013 09:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 FAxvMKFCA5lc for ; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id B02BC21F8733 for ; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id g12so1209463oah.10 for ; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=M1KVtgfd7bkCUJOiKzNcsVOKNz+0LIb8nz5Ad4cyHuA=; b=P5QapScq/PlI3VZVayp2i2lPrQtvy/vgFLaedVYgQEk1tWjOejznQxFXgb3BVATBqj Rrk3TjxKOBRh5DVrwc+jRAbg3DHtwUHVfPfubf+LMpfDPdnUZ1jjMfs6reL1jorIY9LU 5BkRqK5dX4P3H4L3caHQu2mT4kjkMi51gW0qU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=M1KVtgfd7bkCUJOiKzNcsVOKNz+0LIb8nz5Ad4cyHuA=; b=DXayR7TIIspZ/o8sLLHOolnyIKNdLmPMrB6avmDSHsWyAYD3JBPeR7Lc55sbcaATAx sdj97CILA7DeVkDgD3YQ9xQIAvqRI6nW91RMW1cMleplKWYH630eg+NG0C8E9mp2+JvQ 7aorsZZVjl1r3laTsKmAe+LyaFca/31/7CPTxSxg8yX2vcSPnSX6ZW3hPaqASzYX4XDe O1RH7ILptRFRpbNTu7V9XBLGbYxoU8LZXl81cVOCE7gTUZouINlUZBMusMf1hwcomuzE YWdVv9MD2OrOjEpXOFyG9uvzN0q6/xyw9y+gkbyEjuSVvnsH/Bx+hKN8f4cQJWpDoV3z kXLA== MIME-Version: 1.0 X-Received: by 10.60.26.231 with SMTP id o7mr2511039oeg.107.1363971215239; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Fri, 22 Mar 2013 09:53:35 -0700 (PDT) In-Reply-To: <514C75C2.8050004@packetizer.com> References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> <514C75C2.8050004@packetizer.com> Date: Fri, 22 Mar 2013 16:53:35 +0000 Message-ID: From: Dave Cridland To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1f4c4c4c60e04d8864b06 X-Gm-Message-State: ALoCoQl64c7fJCPrXzsZpMpX13eqgrzQHULTosqDx2F9XtWVR8H2Dddt+/3ItdPZoGQzNFObNfTM Cc: webfinger@ietf.org, iesg@ietf.org, "apps-discuss@ietf.org" , draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 22 Mar 2013 16:53:37 -0000 --e89a8fb1f4c4c4c60e04d8864b06 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 22, 2013 at 3:16 PM, Paul E. Jones wrote: > Dave, > > > On 3/22/2013 5:32 AM, Dave Cridland wrote: > > >>> RFC 5988 also allows URIs with fragments, but WebFinger does not. > > Your current draft makes no restriction on whether a Link Relation Type > may have a fragment or not. It stipulates an absolute URI, which in RFC > 3986 may have a fragment; therefore this restriction is not in the draft as > written. Neither is it in RFC 5988; however if you do intend adding this > restriction then this represents a deviation. > > > The WF spec says link relation types MUST be either absolute URIs or > registered a registered relation type. Per RFC 3986, absolute URIs do not > have fragments (See Section 4.3). RFC 5988 also requires use of absolute > URIs when used in Link Headers. Perhaps the intent was to always require > absolute URIs? I don't know, since the text limits the statement to "Link > Headers". WebFinger wants the same restriction, so we inserted an explicit > statement. > > Ah, there's my error, then - I'd made the mistake of assuming "absolute" meant the same as "not relative". I still think that first sentence might be reworded, but it's good enough as is. > My issue here is not a matter of the good things that might reasonably > happen from careful use of simple URIs with arbitrary schemes; my concern > is that there may be bad things with odd cases and there's no evidence that > these have been thought through. > > > Nothing "bad" can happen. > Oh, well that's OK, then. :-) > At the very least, I'd suggest that you add a security consideration > > > What should we add? I'm not seeing any new or different security issues > arising from use of any particular URI scheme. Every URI returns either a > JRD or it does not. What would be different with mailto, http, sip, tel, > gopher, or any other scheme? > sip, simple mailto, acct, xmpp, and so on - those URIs which refer explicitly to an individual - are, I think, adequately considered in the specification. http seems to be considered only when referring to a person. However, in general http resources can have links anyway, so I'm not concerned about these - however I'm not sure that the fragment identifier needs to be sent. I'm entirely willing to believe you've considered these considerably more than that, however there's no evidence of it in the specification as written. I've spent very little time considering what might happen (beyond a 404) with arbitrary URI schemes. Should a client ever send a file: URI, for example? I'm not concerned with what information in the JRD it might be expecting, or whether or not the WF server understands it, but what information transfer has occurred and whether this is safe and can reasonably be expected to be interoperable. For example, I'd expect a sensible WF client to only ever send a simple mailto:local-part@domain URI to a server, and if the initial input was one of the deliciously complex forms, to strip away the header fields and body and extract (if needed) the To field value. I have no clue what a WF server might usefully do with a subject line, mind, whether it's malicious or not - I just think it doesn't need to have it. I'd suggest simply stating that the security considerations and protocol are scoped to consider only URIs identifying an individual entity, (perhaps give some simple examples), and that use beyond that may involve further security considerations. Then everyone's happy. Dave. --e89a8fb1f4c4c4c60e04d8864b06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 22, 2013 at 3:16 PM, Paul E. Jones <pau= lej@packetizer.com> wrote:
=20 =20 =20
Dave,


On 3/22/2013 5:32 AM, Dave Cridland wrote:

>>> RFC 5988 also allows URIs with fragments, but WebFinger does not.

Your current draft makes no restriction on whether a Link Relation Type may have a fragment or not. It stipulates an absolute URI, which in RFC 3986 may have a fragment; therefore this restriction is not in the draft as written. Neither is it in RFC 5988; however if you do intend adding this restriction then this represents a deviation.

The WF spec says link relation types MUST be either absolute URIs or registered a registered relation type.=A0 Per RFC 3986, absolute URIs do not have fragments (See Section 4.3).=A0 RFC 5988 also requires use of absolute URIs when used in Link Headers.=A0 Perhaps the intent was to always require absolute URIs?=A0 I don't know, since the text limits the statement to "Link Headers".=A0 WebFinger wants th= e same restriction, so we inserted an explicit statement.

Ah, there's my erro= r, then - I'd made the mistake of assuming "absolute" meant t= he same as "not relative".

I still think that first sentence might be = reworded, but it's good enough as is.
My issue here is not a matter of the good thing= s that might reasonably happen from careful use of simple URIs with arbitrary schemes; my concern is that there may be bad things with odd cases and there's no evidence that these have been thought through.

Nothing "bad" can happen.=A0

Oh, well that's OK, then. :-)
At the very least, I'd suggest that you add= a security consideration

What should we add?=A0 I'm not seeing any new or different security issues arising from use of any particular URI scheme.=A0 Every URI returns either a JRD or it does not.=A0 What would be different with mailto, http, sip, tel, gopher, or any other scheme?
=

sip, simple mailto, acct, xmpp, and so on - those= URIs which refer explicitly to an individual - are, I think, adequately co= nsidered in the specification.

http seems to be considered only when refer= ring to a person. However, in general http resources can have links anyway,= so I'm not concerned about these - however I'm not sure that the f= ragment identifier needs to be sent.

I'm entirely willing to believe you'= ;ve considered these considerably more than that, however there's no ev= idence of it in the specification as written.

I've spent very little time considering what might happen (b= eyond a 404) with arbitrary URI schemes. Should a client ever send a file: = URI, for example? I'm not concerned with what information in the JRD it= might be expecting, or whether or not the WF server understands it, but wh= at information transfer has occurred and whether this is safe and can reaso= nably be expected to be interoperable.

For example, I'd expect a sensible WF c= lient to only ever send a simple mailto:local-part@domain URI to a server, and if the initial input was one o= f the deliciously complex forms, to strip away the header fields and body a= nd extract (if needed) the To field value. I have no clue what a WF server = might usefully do with a subject line, mind, whether it's malicious or = not - I just think it doesn't need to have it.

I'd suggest simply stating that the sec= urity considerations and protocol are scoped to consider only URIs identify= ing an individual entity, (perhaps give some simple examples), and that use= beyond that may involve further security considerations. Then everyone'= ;s happy.

Dave.
--e89a8fb1f4c4c4c60e04d8864b06-- From superuser@gmail.com Fri Mar 22 12:21:25 2013 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 A179321F9021 for ; Fri, 22 Mar 2013 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pxYukPuRzyDM for ; Fri, 22 Mar 2013 12:21:24 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7121F9019 for ; Fri, 22 Mar 2013 12:21:23 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p43so3588816wea.40 for ; Fri, 22 Mar 2013 12:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=alyKuNajeZCXFbqvIiTiEGRC2NYbbwJMv7bKyje9NkA=; b=GtoLucK0e29eutiBc8FgQtHX+ZZUYX6XuTi693bq6vI5soK6+VG6TwhNLe8OqtVyhb 6c8fQ/WkkRDXxejaDWl9OVMFf58wK0kzWM0r9NB5HdM+5rjRWjIeIgj9onxWqmFE9Rrb ffgvI+8A0JrAzLtRa5eReikX+MGzEbGlSuO8QMBw2gHQIx0duMz2QK0BSzJYfVIIrcRO xkgv8k5edDlf84H6djUcV0bUnb4rICeLdz5J79cE4fIILZCPXKIi0xqWVgPsWpQSplWV W6o+FCFNwDWuM5FCDavuD7z4tM/VbkZ17thlMR5PDygd3xLfJ8I8ruGrRODx4AoCq6P1 6v6w== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr5229687wjc.39.1363980082053; Fri, 22 Mar 2013 12:21:22 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 22 Mar 2013 12:21:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 12:21:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Cridland Content-Type: multipart/alternative; boundary=089e013d1f284586ff04d8885c09 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 22 Mar 2013 19:21:25 -0000 --089e013d1f284586ff04d8885c09 Content-Type: text/plain; charset=ISO-8859-1 Hi Dave, thanks for the review. Comments below. On Fri, Mar 15, 2013 at 4:34 AM, Dave Cridland wrote: > For the most part, this document looks fine and solid. > Hooray! > > Two items concern me in a major way; one further item has me mildly > nervous. > > First, the minor one: > > The header includes definition of a version ABNF production optionally > following the authentication server's identity. It took me some time to > find the note of how to treat this; I didn't see any examples with it > present either. > I've updated one of the examples to include a version. > > Second, the first major one: > > The examples tend to imply, for the most part, a canonical form to the > header, which places CFWS is only particular places. In particular, all the > examples are of the form auth-srv-id "; " method "=" result, with some > optional properties and/or reason, with one single exception (which > includes a comment in lieu of a reason). It's not immediately apparent to a > comparatively novice reader that the following header field is valid: > > Authentication-Results: foo.example.net (My mailserver) / (I am number) 1 > (You see) ; dkim (Because I like it) /2 (Two yay) = (wait for it) pass ; > policy (And a dot can go here) . (Like that) fruit (which surprised me) = > (because I was not expecting it) banana > > I appreciate it's always nicer to only write pretty examples, but given > the specification, providing a nasty one is probably needed, lest people > expect to take a whitespace delimited token and split it on '='. For some > reason I particularly wasn't expecting the CFWS around the dot. (Maybe > that's because I'm out of practise with header parsing). > > In any case, highlighting this with an example seems appropriate and > useful. > Copied to the draft, with some adjustments to make it compliant and fit the width limit. > > Thirdly, one more major concern: > > You'll note that I included a version for the method in my example above. > The definition for this, from the comments in the ABNF, suggests that this > relates to the version of RFC 5451 and successors used, but this seems > unlikely - I'm also at a loss as to what a receiving implementation should > do with such a method, since the handling of version seems to be specified > only for the version number after the auth-srv-id. > > I have a vague suspicion that the correct thing to do here may be to > deprecate the method version entirely, but I might be missing something - > still, it doesn't appear to relate to the method, but the header field. > > > The method version refers to the method itself, which is specified elsewhere; the authserv-id version refers to this draft and thus the syntax of this header field. The idea is that if you find a version after an authserv-id that you can't handle, you stop trying to parse right away because what follows might not be what you expect. In terms of a method version, the parser should ignore a method result if the version of the version is not supported in case the semantics of the result have a different meaning. If, for example, DKIM v2 (were such a thing to exist) yielded a "pass" for different reasons than v1 did, a consumer of this field might not want the altered semantics to apply. This is a way to indicate this and let the consumer decide. Is your reply to this "You should say that?" :-) -MSK --089e013d1f284586ff04d8885c09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave, thanks for the review.=A0=A0 Comments below.
<= div class=3D"gmail_extra">
On Fri, Mar 15, 20= 13 at 4:34 AM, Dave Cridland <dave@cridland.net> wrote:
For the most part, this = document looks fine and solid.

Hooray!
=A0
=

Two items concern me in a ma= jor way; one further item has me mildly nervous.

First, the minor one:

The header includ= es definition of a version ABNF production optionally following the authent= ication server's identity. It took me some time to find the note of how= to treat this; I didn't see any examples with it present either.

I've updated one of = the examples to include a version.
=A0

Second, the first major one:

T= he examples tend to imply, for the most part, a canonical form to the heade= r, which places CFWS is only particular places. In particular, all the exam= ples are of the form auth-srv-id "; " method "=3D" resu= lt, with some optional properties and/or reason, with one single exception = (which includes a comment in lieu of a reason). It's not immediately ap= parent to a comparatively novice reader that the following header field is = valid:

Authentication-Results: foo.example.net (My mailserver) / (I am number) 1= (You see) ; dkim (Because I like it) /2 (Two yay) =3D (wait for it) pass ;= policy (And a dot can go here) . (Like that) fruit (which surprised me) = =3D (because I was not expecting it) banana

I appreciate it's always nicer to only write pretty= examples, but given the specification, providing a nasty one is probably n= eeded, lest people expect to take a whitespace delimited token and split it= on '=3D'. For some reason I particularly wasn't expecting the = CFWS around the dot. (Maybe that's because I'm out of practise with= header parsing).

In any case, highlighting this with an example seems ap= propriate and useful.

Copied to the draft, with some adjustments to make it compliant and = fit the width limit.
=A0

=
Thirdly, one more major concern:

You'll note that I included a version for the metho= d in my example above. The definition for this, from the comments in the AB= NF, suggests that this relates to the version of RFC 5451 and successors us= ed, but this seems unlikely - I'm also at a loss as to what a receiving= implementation should do with such a method, since the handling of version= seems to be specified only for the version number after the auth-srv-id.

I have a vague suspicion that the correct thing to do h= ere may be to deprecate the method version entirely, but I might be missing= something - still, it doesn't appear to relate to the method, but the = header field.



The method version refers to the method itself, which is specified= elsewhere; the authserv-id version refers to this draft and thus the synta= x of this header field.=A0 The idea is that if you find a version after an = authserv-id that you can't handle, you stop trying to parse right away = because what follows might not be what you expect.=A0 In terms of a method = version, the parser should ignore a method result if the version of the ver= sion is not supported in case the semantics of the result have a different = meaning.=A0 If, for example, DKIM v2 (were such a thing to exist) yielded a= "pass" for different reasons than v1 did, a consumer of this fie= ld might not want the altered semantics to apply.=A0 This is a way to indic= ate this and let the consumer decide.

Is your reply to this "You should say that?"=A0 :-= )

-MSK

--089e013d1f284586ff04d8885c09-- From superuser@gmail.com Fri Mar 22 12:22:46 2013 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 33E4021F8E77 for ; Fri, 22 Mar 2013 12:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, 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 wg-PlQkRgAZH for ; Fri, 22 Mar 2013 12:22:44 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6C66A21F8DCF for ; Fri, 22 Mar 2013 12:22:44 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id e12so3519014wge.22 for ; Fri, 22 Mar 2013 12:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n5q3plmzrKVH9dnXcvL+GKyO6wEBX4CJibH7Hvw/jUw=; b=H8337fgkZDFBLsGK44qqBPbUvLhIiCIjAX0yqN7IACqs4GpdyY+m3ojUp8F1evQFEf YDFWJbPuFeH9w0IYGXrvGj2R4WAOlVxnHbra9E9sFbP/jqMx+0NDjIOIzZTy/aSinlRC w10M7vZYV+R8Fea8oAPpR0QJs2QKJC1ZE5bxU3gEU3cD9fFyWTSUYrGaykfSK609cYYt afIzueiAsvLpriQETwrwoAGq1OBm/UevDG09tF+1vK7lWBq0H9d6GPWrvOOelL0P0LTn NVOljoR90YFzaYgWedufq79V6GTeFaTJujxevkvX4pFZpag0WZg/Jb7x0Aox7EDxMnPT CAMg== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr13473030wiy.5.1363980163608; Fri, 22 Mar 2013 12:22:43 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 22 Mar 2013 12:22:43 -0700 (PDT) In-Reply-To: <51458A59.8040206@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> Date: Fri, 22 Mar 2013 12:22:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04428eb621f8e704d88861bc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 22 Mar 2013 19:22:46 -0000 --f46d04428eb621f8e704d88861bc Content-Type: text/plain; charset=ISO-8859-1 I've revised the grammar in the next draft to avoid this ambiguity. Let me know if it works. Essentially, "dot-atom" has been replaced by "value", which disallows the case you've illustrated here. On Sun, Mar 17, 2013 at 2:18 AM, Alessandro Vesely wrote: > On Sat 16/Mar/2013 19:43:37 +0100 Dave Cridland wrote: > > On 16 Mar 2013 08:59, "Alessandro Vesely" wrote: > >> > >> Oops, I overlooked that "[ CFWS version ]" in authres-header. Thus > >> you helped me catch a bug. Thanks! > >> > > > > That was even the one that was properly specified... it's the other > > one I'm more concerned with. > > "Properly" might be something of an overstatement. Section 2.3 says: > > For tracing and debugging purposes, the authentication identifier MAY > instead be the hostname of the MTA performing the authentication > check whose result is being reported. This is also useful for > another purpose, as described in Section 4. Moreover, some > implementations have considered appending a delimiter such as "/" and > following it with useful transport tracing data such as the [SMTP] > queue ID or a timestamp. > > Informal discussions like that tend to be ambiguous because "/" is > allowed in dot-atom. Hence one doesn't know whether the text means > something like: > > server.example.com/Q304b5 / 1 > > or: > > server.example.com / 197813 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04428eb621f8e704d88861bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've revised the grammar in the next draft to avoid th= is ambiguity.=A0 Let me know if it works.=A0 Essentially, "dot-atom&qu= ot; has been replaced by "value", which disallows the case you= 9;ve illustrated here.


On Sun,= Mar 17, 2013 at 2:18 AM, Alessandro Vesely <vesely@tana.it> = wrote:
On Sat 16/Mar/2013 19:43:3= 7 +0100 Dave Cridland wrote:
> On 16 Mar 2013 08:59, "Alessandro Vesely" <vesely@tana.it> wrote:
>>
>> Oops, I overlooked that "[ CFWS versi= on ]" in authres-header. =A0Thus
>> you helped me catch a bug. =A0Thanks!
>>
>
> That was even the one that was properly specified... it's the othe= r
> one I'm more concerned with.

"Properly" might be something of an overstatement. =A0Secti= on 2.3 says:

=A0For tracing and debugging purposes, the authentication identifier MAY =A0instead be the hostname of the MTA performing the authentication
=A0check whose result is being reported. =A0This is also useful for
=A0another purpose, as described in Section 4. =A0Moreover, some
=A0implementations have considered appending a delimiter such as "/&qu= ot; and
=A0following it with useful transport tracing data such as the [SMTP]
=A0queue ID or a timestamp.

Informal discussions like that tend to be ambiguous because "/" i= s
allowed in dot-atom. =A0Hence one doesn't know whether the text means something like:

=A0 server.e= xample.com/Q304b5 / 1

or:

=A0 server.example.= com / 197813
___________________________________= ____________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d04428eb621f8e704d88861bc-- From vesely@tana.it Sat Mar 23 11:56:11 2013 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 B82AB21F8BED for ; Sat, 23 Mar 2013 11:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 zxRH5qU3SjCH for ; Sat, 23 Mar 2013 11:56:10 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACB021F8BF8 for ; Sat, 23 Mar 2013 11:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364064968; bh=U5PxJnCVX9M5KEk2NgjFYYQj8ears3XgPVx8RhzXbUs=; l=803; h=Date:From:To:References:In-Reply-To; b=K1FPOW/NS/xOdVtEw+ijzhRN1EcfX1jXjgO+5PFQlclvobWq7PoGY/L9YuQ8AnQYg TlaykfARsihMXQBujlow9jOztgzBoT2+sx6TKhiaDEabZ0egBqW4n/j7WyIIvvLyBp oxpIxy2Zlbelg8MHdLhK2UfCBQWmGAX2UH/sTfz0= Received: from [10.57.167.222] (93-32-180-247.ip34.fastwebnet.it [93.32.180.247]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 23 Mar 2013 19:56:08 +0100 id 00000000005DC039.00000000514DFAC8.00007DB7 Message-ID: <514DFAC8.7040406@tana.it> Date: Sat, 23 Mar 2013 19:56:08 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 23 Mar 2013 18:56:12 -0000 On Fri 22/Mar/2013 20:22:43 +0100 Murray S. Kucherawy wrote: > I've revised the grammar in the next draft to avoid this ambiguity. Let > me know if it works. Essentially, "dot-atom" has been replaced by > "value", which disallows the case you've illustrated here. Hm... that way it becomes possible to have "dkim"="pass". I'd beg for "token", which is somewhat simpler, but it allows dots. Wouldn't it be possible to have a grammar that matches the actual use? I mean, e.g.: authserv-id = domain-name method = Keyword [ [CFWS] "/" [CFWS] version ] result = Keyword property = Keyword "Keyword" is defined in RFC 5321, as well as "domain-name". (It seems to be useless to recall the definition from RFC 6376, as the domain literal alternative that was in RFC 2821 has gone away.) From vesely@tana.it Sat Mar 23 11:56:31 2013 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 2B18921F87AF for ; Sat, 23 Mar 2013 11:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=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 2b22qakgmapY for ; Sat, 23 Mar 2013 11:56:30 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04921F8BDD for ; Sat, 23 Mar 2013 11:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364064989; bh=AdgJuxqKj+cAtzUE7F8JGQz3o1nX3V1J4nWIo9vXXdA=; l=1670; h=Date:From:To:References:In-Reply-To; b=te8OXxY/WJtuD9XVgdJajT/HzZlqzV+ij2/doqoVF385021RNiJwc/lZBw5vYkIUO tBy4537hSnxz+ngx4RFBTVYZ+VrYlRNyALIxzwm0Q9zsTATkAwUaP9tUTbbhHPMwzw 8O2oDftbpmoBgxS9rSIYOj35B6uuCgHZBc4nWv0o= Received: from [10.57.167.222] (93-32-180-247.ip34.fastwebnet.it [93.32.180.247]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 23 Mar 2013 19:56:29 +0100 id 00000000005DC039.00000000514DFADD.00000145 Message-ID: <514DFADD.1010906@tana.it> Date: Sat, 23 Mar 2013 19:56:29 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Authentication-Results 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, 23 Mar 2013 18:56:31 -0000 On Fri 22/Mar/2013 17:48:01 +0100 Murray S. Kucherawy wrote: > > A Proposed Standard "bis" effort always benefits from describing extant > implementations. I know about the ones I've written, and about some > very public uses of it (Gmail, Yahoo, for example). If there's anyone > in this audience that knows of others, I'd love to hear about it. The following, copied from the source of your message, is added by recent prereleases of Courier-MTA (the server itself, not my filter): Authentication-Results: wmail.tana.it; dnswl=pass dns.zone=list.dnswl.org policy.ip=127.0.9.1 policy.txt="ietf.org http://dnswl.org/s?s=1703" It uses an extended method --I'd wait for your bis to change the registry rules to expert review. One further difference is that, rather than deleting existing A-R fields, that MTA renames them. The rationale is as follows: Courier does not implement DKIM natively; that is, the agent that renames existing fields cannot relay on that authentication method in order to establish whether a field is trusted. OTOH, a DKIM verifier working downstream can easily "unrename" a field, at least temporarily, so as to avoid breaking signatures if the field is signed. The spec (Sections 1.6 and 5) uses the term "remove". I'm not clear if that necessarily means to irrecoverably destroy the data. IMHO, the spec is more flexible in the opposite case. For a related theme, see https://sites.google.com/site/oauthgoog/mlistsdkim (X-Original-Authentication-Results). Finally, there are a couple of requests to use A-R in SpamAssassin, but it is uncertain that they will be fulfilled before 5451bis is released. From paulej@packetizer.com Sat Mar 23 12:04:50 2013 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 F0CB521F8D7A; Sat, 23 Mar 2013 12:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, 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 HpgLZfvoyYDj; Sat, 23 Mar 2013 12:04:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 906B421F8D32; Sat, 23 Mar 2013 12:04:47 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2NJ4jAO010965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Mar 2013 15:04:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1364065486; bh=mPYXxI4vF8qEzw0JOTB3ohLPa7BUQe2Q8XhxByoN1FY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=qmBDzbnUS2OnGo4MzvzZPlwnU6QvkNNgTitPfnckiFGgYJx92tnhYnGcCApcvvQ+5 vPZgUgMHbvVHNviOYGAijWhfH79Nu+AxNdOoeOcBTDFjM3UJwMUvfdl3jb9yhE0r/L K+B228H+VUYgGU+2rW/r8m00j3RRqoNMr6CjL6Z4= From: "Paul E. Jones" To: "'Dave Cridland'" References: <053c01ce25cc$8cca5730$a65f0590$@packetizer.com> <012301ce26a8$0d940a10$28bc1e30$@packetizer.com> <514C75C2.8050004@packetizer.com> In-Reply-To: Date: Sat, 23 Mar 2013 15:05:08 -0400 Message-ID: <03b401ce27f9$5668c5d0$033a5170$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B5_01CE27D7.CF57E920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6xtTU7bBnElLUOVycpt5dUnTbtQEse7f/Af/Bk0cCFB98AAKS9xmXAYAzFy4B85JRI5eAJN1Q Content-Language: en-us Cc: webfinger@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-webfinger.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-webfinger-11 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, 23 Mar 2013 19:04:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03B5_01CE27D7.CF57E920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dave, An "http" URI could be used to query information about a web page. It might return "copyright" or "author" or other defined link relation values. Had WF existed when OpenID 2.0 was drafted, it could have been used to resolve the OpenID Provider information for a given OpenID identifier. WebFinger might be used to find other information about things on the Internet, including printer, refrigerators, thermostats, or whatever. What one would or should expect for various URI schemes is not fully-defined, except that any URI will return a JRD document with links. How those links are interpreted will be defined by whatever document defines the link relation types or some document such as "Discovering Information about X using WebFinger" (where "X" might be a printer, thermostat, or whatever). So, it's not accurate to say the document is scoped to return information only about individuals. We put most of the emphasis there, because that has the most immediate practical use and we expect the 'acct' URI type to be used primarily. Paul What should we add? I'm not seeing any new or different security issues arising from use of any particular URI scheme. Every URI returns either a JRD or it does not. What would be different with mailto, http, sip, tel, gopher, or any other scheme? sip, simple mailto, acct, xmpp, and so on - those URIs which refer explicitly to an individual - are, I think, adequately considered in the specification. http seems to be considered only when referring to a person. However, in general http resources can have links anyway, so I'm not concerned about these - however I'm not sure that the fragment identifier needs to be sent. I'm entirely willing to believe you've considered these considerably more than that, however there's no evidence of it in the specification as written. I've spent very little time considering what might happen (beyond a 404) with arbitrary URI schemes. Should a client ever send a file: URI, for example? I'm not concerned with what information in the JRD it might be expecting, or whether or not the WF server understands it, but what information transfer has occurred and whether this is safe and can reasonably be expected to be interoperable. For example, I'd expect a sensible WF client to only ever send a simple mailto:local-part@domain URI to a server, and if the initial input was one of the deliciously complex forms, to strip away the header fields and body and extract (if needed) the To field value. I have no clue what a WF server might usefully do with a subject line, mind, whether it's malicious or not - I just think it doesn't need to have it. I'd suggest simply stating that the security considerations and protocol are scoped to consider only URIs identifying an individual entity, (perhaps give some simple examples), and that use beyond that may involve further security considerations. Then everyone's happy. Dave. ------=_NextPart_000_03B5_01CE27D7.CF57E920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

An “http” URI could be used to query information about a = web page.  It might return “copyright” or = “author” or other defined link relation values.  Had WF = existed when OpenID 2.0 was drafted, it could have been used to resolve = the OpenID Provider information for a given OpenID identifier.  = WebFinger might be used to find other information about things on the = Internet, including printer, refrigerators, thermostats, or = whatever.  What one would or should expect for various URI schemes = is not fully-defined, except that any URI will return a JRD document = with links.  How those links are interpreted will be defined by = whatever document defines the link relation types or some document such = as “Discovering Information about X using WebFinger” (where = “X” might be a printer, thermostat, or = whatever).

 

So, it’s not accurate to say the document is scoped to return = information only about individuals.  We put most of the emphasis = there, because that has the most immediate practical use and we expect = the ‘acct’ URI type to be used = primarily.

 

Paul

 

 

What = should we add?  I'm not seeing any new or different security issues = arising from use of any particular URI scheme.  Every URI returns = either a JRD or it does not.  What would be different with mailto, = http, sip, tel, gopher, or any other = scheme?

 

sip, simple mailto, acct, xmpp, and so on - those URIs = which refer explicitly to an individual - are, I think, adequately = considered in the specification.

 

http seems to be considered only when referring to a = person. However, in general http resources can have links anyway, so I'm = not concerned about these - however I'm not sure that the fragment = identifier needs to be sent.

 

I'm entirely willing to believe you've considered = these considerably more than that, however there's no evidence of it in = the specification as written.

 

I've spent very little time considering what might = happen (beyond a 404) with arbitrary URI schemes. Should a client ever = send a file: URI, for example? I'm not concerned with what information = in the JRD it might be expecting, or whether or not the WF server = understands it, but what information transfer has occurred and whether = this is safe and can reasonably be expected to be = interoperable.

 

For example, I'd expect a sensible WF client to only = ever send a simple mailto:local-part@domain URI to a server, = and if the initial input was one of the deliciously complex forms, to = strip away the header fields and body and extract (if needed) the To = field value. I have no clue what a WF server might usefully do with a = subject line, mind, whether it's malicious or not - I just think it = doesn't need to have it.

 

I'd suggest simply stating that the security = considerations and protocol are scoped to consider only URIs identifying = an individual entity, (perhaps give some simple examples), and that use = beyond that may involve further security considerations. Then everyone's = happy.

 

Dave.

------=_NextPart_000_03B5_01CE27D7.CF57E920-- From superuser@gmail.com Sat Mar 23 13:31:25 2013 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 0146021F8C93 for ; Sat, 23 Mar 2013 13:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, 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 00g15YM8aMDT for ; Sat, 23 Mar 2013 13:31:23 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5621021F8576 for ; Sat, 23 Mar 2013 13:31:23 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id fm10so1108630wgb.21 for ; Sat, 23 Mar 2013 13:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Vtb5dJGNMomQr9JBqNnv8dIlvx4ZolowLET786i/mlY=; b=lRx7AMxkc+qt/NnH1W3+dr/ACRHkg3KFbvONVy/hgkXJ2vC/jeFgvIeGLvYVD5Sd6W bSJEUu1mIP93mauiy1fExyDsvGA/h2pOo9H4nRClkdbOWRVG1MU0z1QQ/G3lOJ/hOloa iszp1OCgVHqKeBSoM046pr2a+eeCS03LB2nL0Xmdfl+Czm03GW4jQJ5B0s8ljnCiLy3v ClwS37KqeXvXHVmtRI9OhMU6t9lRsAplmM/SoJRrFIOI57Lwhc7p/1OkHty9cZAdfesx F/Gg5dzp6EAt2ru2xjFRqHrwMv4GFoT10HelzLPSTSW7Ng8f0mpPTrNrcQKJi3fdLYoe VfkA== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr9984891wjc.39.1364070682597; Sat, 23 Mar 2013 13:31:22 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sat, 23 Mar 2013 13:31:22 -0700 (PDT) In-Reply-To: <514DFAC8.7040406@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> Date: Sat, 23 Mar 2013 13:31:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e013d1f287c20b004d89d745d Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 23 Mar 2013 20:31:25 -0000 --089e013d1f287c20b004d89d745d Content-Type: text/plain; charset=ISO-8859-1 What would be wrong with "dkim"="pass"? The main difference between "token" and "value" is that the latter permits quoted strings. I couldn't think of a good reason to proscribe those, and it's not like it makes parsing any more difficult; things that can parse "value" have been around for years. -MSK On Sat, Mar 23, 2013 at 11:56 AM, Alessandro Vesely wrote: > On Fri 22/Mar/2013 20:22:43 +0100 Murray S. Kucherawy wrote: > > I've revised the grammar in the next draft to avoid this ambiguity. Let > > me know if it works. Essentially, "dot-atom" has been replaced by > > "value", which disallows the case you've illustrated here. > > Hm... that way it becomes possible to have "dkim"="pass". I'd beg for > "token", which is somewhat simpler, but it allows dots. Wouldn't it be > possible to have a grammar that matches the actual use? I mean, e.g.: > > authserv-id = domain-name > method = Keyword [ [CFWS] "/" [CFWS] version ] > result = Keyword > property = Keyword > > "Keyword" is defined in RFC 5321, as well as "domain-name". (It seems > to be useless to recall the definition from RFC 6376, as the domain > literal alternative that was in RFC 2821 has gone away.) > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013d1f287c20b004d89d745d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What would be wrong with "dkim"=3D&quo= t;pass"?

The main difference between "token" an= d "value" is that the latter permits quoted strings.=A0 I couldn&= #39;t think of a good reason to proscribe those, and it's not like it m= akes parsing any more difficult; things that can parse "value" ha= ve been around for years.

-MSK


On Sat, Mar 23, 2013 at 11:56 AM, Alessandro Vesely <vesely@tana.i= t> wrote:
=A0On Fri 22/Mar/2013 20:2= 2:43 +0100 Murray S. Kucherawy wrote:
> I've revised the grammar in the next draft to avoid this ambiguity= . =A0Let
> me know if it works. =A0Essentially, "dot-atom" has been rep= laced by
> "value", which disallows the case you've illustrated her= e.

Hm... that way it becomes possible to have "dkim"=3D"p= ass". =A0I'd beg for
"token", which is somewhat simpler, but it allows dots. =A0Wouldn= 't it be
possible to have a grammar that matches the actual use? =A0I mean, e.g.:
authserv-id =3D domain-name
=A0 =A0 =A0method =3D Keyword [ [CFWS] "/" [CFWS] version ]
=A0 =A0 =A0result =3D Keyword
=A0 =A0property =3D Keyword

"Keyword" is defined in RFC 5321, as well as "domain-name&qu= ot;. =A0(It seems
to be useless to recall the definition from RFC 6376, as the domain
literal alternative that was in RFC 2821 has gone away.)
___________________________________= ____________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e013d1f287c20b004d89d745d-- From vesely@tana.it Sun Mar 24 05:04:10 2013 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 3D0CC21F8CD1 for ; Sun, 24 Mar 2013 05:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 LElvPbmYVGyh for ; Sun, 24 Mar 2013 05:04:09 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5093E21F8A56 for ; Sun, 24 Mar 2013 05:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364126647; bh=Om9KMafLKZooLDyXSoSbCoUW790GVHKC/ps7p1qgWWk=; l=2392; h=Date:From:To:References:In-Reply-To; b=LWqyJ2eMjoa2DQ2nZKPL80XFkAXaKvRIV/hI+quuWX70dPp2nWxcIWWlHfN0qAIjC iv6imiZUh92UnIVbfkuH+cpJGXATNPsWrxvN40a3Lcjo3jTXAIk2SSXhfS/8ZGoixp VcDMSPGxbwOdb/bgwwtgm3zKT2AfVYjaipFs0PjY= Received: from [10.57.167.221] (93-32-179-143.ip34.fastwebnet.it [93.32.179.143]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sun, 24 Mar 2013 13:04:07 +0100 id 00000000005DC039.00000000514EEBB7.00000876 Message-ID: <514EEBB7.40205@tana.it> Date: Sun, 24 Mar 2013 13:04:07 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 24 Mar 2013 12:04:10 -0000 There's nothing intrinsically wrong with "value", albeit it is sometimes a nuisance not to have a canonical form. The point is how many A-R parsers will need to be updated to comply with it, since "dot-atom" didn't admit quotes. Another point is about extensions. I proposed "Keyword" because it matches all the registered methods, and thus looks like what may seem to be the spirit of the spec. If 5451bis will say "value", then the appointed expert will have no reason to oppose methods with long names and properties, comprising spaces and punctuation like some sort of filenames which require composition assistance in order to be spelled correctly. Is that what we want? On Sat 23/Mar/2013 21:31:22 +0100 Murray S. Kucherawy wrote: > What would be wrong with "dkim"="pass"? > > The main difference between "token" and "value" is that the latter > permits quoted strings. I couldn't think of a good reason to proscribe > those, and it's not like it makes parsing any more difficult; things > that can parse "value" have been around for years. > > -MSK > > > On Sat, Mar 23, 2013 at 11:56 AM, Alessandro Vesely > wrote: > > On Fri 22/Mar/2013 20:22:43 +0100 Murray S. Kucherawy wrote: > > I've revised the grammar in the next draft to avoid this > ambiguity. Let > > me know if it works. Essentially, "dot-atom" has been replaced by > > "value", which disallows the case you've illustrated here. > > Hm... that way it becomes possible to have "dkim"="pass". I'd beg for > "token", which is somewhat simpler, but it allows dots. Wouldn't it be > possible to have a grammar that matches the actual use? I mean, e.g.: > > authserv-id = domain-name > method = Keyword [ [CFWS] "/" [CFWS] version ] > result = Keyword > property = Keyword > > "Keyword" is defined in RFC 5321, as well as "domain-name". (It seems > to be useless to recall the definition from RFC 6376, as the domain > literal alternative that was in RFC 2821 has gone away.) > _______________________________________________ > 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 scott@kitterman.com Sun Mar 24 05:43:15 2013 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 5125721F89EE for ; Sun, 24 Mar 2013 05:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boFLUQWUAkFr for ; Sun, 24 Mar 2013 05:43:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAC121F8938 for ; Sun, 24 Mar 2013 05:43:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 06CBA20E40D2; Sun, 24 Mar 2013 08:43:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364128993; bh=auHOWzV76w3Fclm4gzmNHMTYIlijyYvYMRhVds2/frA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j4onAUFmaweOzV+7EnBr/LrvRWMSfdn5Y+XZgFhFs98YC5uj+jTLZMb26DjhZehsc leLv3ETpGLjy2hBgK8AiI/he3lEqLQJ6vUljCg/R3Hc9jd3TxjWzq7q7gDG7k3mi2U iloEW50GqReY8As3LW67ulgu3wtM552/5eymoMhE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DF93620E40C7; Sun, 24 Mar 2013 08:43:12 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Sun, 24 Mar 2013 08:43:11 -0400 Message-ID: <5103174.tJ3nsKeqxz@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <514EEBB7.40205@tana.it> References: <514EEBB7.40205@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 24 Mar 2013 12:43:15 -0000 I tried out "auth"="pass" and my implementation chokes on it. I'd strongly prefer not to have to change it and having a single canonical form is definitely better. So my answer to Alessandro's question about how many parsers would have to be updated is "at least one". Scott K On Sunday, March 24, 2013 01:04:07 PM Alessandro Vesely wrote: > There's nothing intrinsically wrong with "value", albeit it is sometimes > a nuisance not to have a canonical form. The point is how many A-R > parsers will need to be updated to comply with it, since "dot-atom" > didn't admit quotes. > > Another point is about extensions. I proposed "Keyword" because it > matches all the registered methods, and thus looks like what may seem to > be the spirit of the spec. If 5451bis will say "value", then the > appointed expert will have no reason to oppose methods with long names > and properties, comprising spaces and punctuation like some sort of > filenames which require composition assistance in order to be spelled > correctly. Is that what we want? > > On Sat 23/Mar/2013 21:31:22 +0100 Murray S. Kucherawy wrote: > > What would be wrong with "dkim"="pass"? > > > > The main difference between "token" and "value" is that the latter > > permits quoted strings. I couldn't think of a good reason to proscribe > > those, and it's not like it makes parsing any more difficult; things > > that can parse "value" have been around for years. > > > > -MSK > > > > > > On Sat, Mar 23, 2013 at 11:56 AM, Alessandro Vesely > > > > wrote: > > On Fri 22/Mar/2013 20:22:43 +0100 Murray S. Kucherawy wrote: > > > I've revised the grammar in the next draft to avoid this > > > > ambiguity. Let > > > > > me know if it works. Essentially, "dot-atom" has been replaced by > > > "value", which disallows the case you've illustrated here. > > > > Hm... that way it becomes possible to have "dkim"="pass". I'd beg for > > "token", which is somewhat simpler, but it allows dots. Wouldn't it > > be > > possible to have a grammar that matches the actual use? I mean, e.g.: > > > > authserv-id = domain-name > > > > method = Keyword [ [CFWS] "/" [CFWS] version ] > > result = Keyword > > > > property = Keyword > > > > "Keyword" is defined in RFC 5321, as well as "domain-name". (It seems > > to be useless to recall the definition from RFC 6376, as the domain > > literal alternative that was in RFC 2821 has gone away.) > > _______________________________________________ > > 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 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From superuser@gmail.com Sun Mar 24 14:06:44 2013 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 0940E21F8DD9 for ; Sun, 24 Mar 2013 14:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dJA9t4xQ7eT2 for ; Sun, 24 Mar 2013 14:06:43 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id D3E6421F8CA4 for ; Sun, 24 Mar 2013 14:06:42 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ez12so1364527wid.17 for ; Sun, 24 Mar 2013 14:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0L33OuZkGdNGMbAE6GdcOoHlChJsK4P53oXL0kQG+6c=; b=lr49PugKqF2Hy714BVJUehHE2XJ5f0/9Pawg8MIZ8OTGktWY0FE2s6ozjqGEerQi8J nKKSNQdjCQQqQHVfh4TUm3iHwmAWHJ/bK1m25qly4AsCZq9LyK446Uhm6qhqZve7vSlw mlCLNNgYsHV3Ax5mZObx20g110T8iXjkx5B79qMumGuCdoAAF+7QegH7qxPrM9e3vkEs HAsK3cdjjXQgL4A4yM35rSzKopqGwD0dq6kPHcU/lXYAX2/DckQB0tY0vAp9YCAotFJx nnd+6XJ0ZhoGdLKlm1NFGedJ7nDqb9kz3zXC2+rJwTLZJCqg3uPUtzRFmfD5xp9vPtrS s6DQ== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr21966538wiy.5.1364159201999; Sun, 24 Mar 2013 14:06:41 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sun, 24 Mar 2013 14:06:41 -0700 (PDT) In-Reply-To: <514EEBB7.40205@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> Date: Sun, 24 Mar 2013 14:06:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04428eb6a7008c04d8b210fa Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis 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, 24 Mar 2013 21:06:44 -0000 --f46d04428eb6a7008c04d8b210fa Content-Type: text/plain; charset=ISO-8859-1 I'm not in favour of changing to a grammar that matches current use to the exclusion of other uses without a good reason to do so. Since in the prose we talk about authserv-id being a domain name in the typical case but basically also say it could be anything the operator wants to use, I think "value" is the right thing there. We also shouldn't be making changes that aren't either improvements to the prose or bug fixes to the normative parts. Keyword is probably fine for the other three you mentioned. I'll make that change. This is obviously a bug fix since, as you pointed out, "dot-atom" permits ambiguous productions. -MSK On Sun, Mar 24, 2013 at 5:04 AM, Alessandro Vesely wrote: > There's nothing intrinsically wrong with "value", albeit it is sometimes > a nuisance not to have a canonical form. The point is how many A-R > parsers will need to be updated to comply with it, since "dot-atom" > didn't admit quotes. > > Another point is about extensions. I proposed "Keyword" because it > matches all the registered methods, and thus looks like what may seem to > be the spirit of the spec. If 5451bis will say "value", then the > appointed expert will have no reason to oppose methods with long names > and properties, comprising spaces and punctuation like some sort of > filenames which require composition assistance in order to be spelled > correctly. Is that what we want? > > On Sat 23/Mar/2013 21:31:22 +0100 Murray S. Kucherawy wrote: > > What would be wrong with "dkim"="pass"? > > > > The main difference between "token" and "value" is that the latter > > permits quoted strings. I couldn't think of a good reason to proscribe > > those, and it's not like it makes parsing any more difficult; things > > that can parse "value" have been around for years. > > > > -MSK > > > > > > On Sat, Mar 23, 2013 at 11:56 AM, Alessandro Vesely > > wrote: > > > > On Fri 22/Mar/2013 20:22:43 +0100 Murray S. Kucherawy wrote: > > > I've revised the grammar in the next draft to avoid this > > ambiguity. Let > > > me know if it works. Essentially, "dot-atom" has been replaced by > > > "value", which disallows the case you've illustrated here. > > > > Hm... that way it becomes possible to have "dkim"="pass". I'd beg > for > > "token", which is somewhat simpler, but it allows dots. Wouldn't it > be > > possible to have a grammar that matches the actual use? I mean, > e.g.: > > > > authserv-id = domain-name > > method = Keyword [ [CFWS] "/" [CFWS] version ] > > result = Keyword > > property = Keyword > > > > "Keyword" is defined in RFC 5321, as well as "domain-name". (It > seems > > to be useless to recall the definition from RFC 6376, as the domain > > literal alternative that was in RFC 2821 has gone away.) > > _______________________________________________ > > 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 > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d04428eb6a7008c04d8b210fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not in favour of changing to a grammar that m= atches current use to the exclusion of other uses without a good reason to = do so.=A0 Since in the prose we talk about authserv-id being a domain name = in the typical case but basically also say it could be anything the operato= r wants to use, I think "value" is the right thing there.=A0 We a= lso shouldn't be making changes that aren't either improvements to = the prose or bug fixes to the normative parts.

Keyword is probably fine for the other three you mentioned.= =A0 I'll make that change.=A0 This is obviously a bug fix since, as you= pointed out, "dot-atom" permits ambiguous productions.

-MSK



=
On Sun, Mar 24, 2013 at 5:04 AM, Alessandro Vese= ly <vesely@tana.it> wrote:
There's nothing intrinsically wrong with= "value", albeit it is sometimes
a nuisance not to have a canonical form. =A0The point is how many A-R
parsers will need to be updated to comply with it, since "dot-atom&quo= t;
didn't admit quotes.

Another point is about extensions. =A0I proposed "Keyword" becaus= e it
matches all the registered methods, and thus looks like what may seem to be the spirit of the spec. =A0If 5451bis will say "value", then t= he
appointed expert will have no reason to oppose methods with long names
and properties, comprising spaces and punctuation like some sort of
filenames which require composition assistance in order to be spelled
correctly. =A0Is that what we want?

On Sat 23/Mar/2013 21:31:22 +0100 Murray S. Kucherawy wrote:
> What would be wrong with "dkim"=3D"pass"?
>
> The main difference between "token" and "value" is= that the latter
> permits quoted strings. =A0I couldn't think of a good reason to pr= oscribe
> those, and it's not like it makes parsing any more difficult; thin= gs
> that can parse "value" have been around for years.
>
> -MSK
>
>
> On Sat, Mar 23, 2013 at 11:56 AM, Alessandro Vesely <vesely@tana.it
> <mailto:v= esely@tana.it>> wrote:
>
> =A0 =A0 =A0On Fri 22/Mar/2013 20:22:43 +0100 Murray S. Kucherawy wrote= :
> =A0 =A0 > I've revised the grammar in the next draft to avoid t= his
> =A0 =A0 ambiguity. =A0Let
> =A0 =A0 > me know if it works. =A0Essentially, "dot-atom"= has been replaced by
> =A0 =A0 > "value", which disallows the case you've il= lustrated here.
>
> =A0 =A0 Hm... that way it becomes possible to have "dkim"=3D= "pass". =A0I'd beg for
> =A0 =A0 "token", which is somewhat simpler, but it allows do= ts. =A0Wouldn't it be
> =A0 =A0 possible to have a grammar that matches the actual use? =A0I m= ean, e.g.:
>
> =A0 =A0 authserv-id =3D domain-name
> =A0 =A0 =A0 =A0 =A0method =3D Keyword [ [CFWS] "/" [CFWS] ve= rsion ]
> =A0 =A0 =A0 =A0 =A0result =3D Keyword
> =A0 =A0 =A0 =A0property =3D Keyword
>
> =A0 =A0 "Keyword" is defined in RFC 5321, as well as "d= omain-name". =A0(It seems
> =A0 =A0 to be useless to recall the definition from RFC 6376, as the d= omain
> =A0 =A0 literal alternative that was in RFC 2821 has gone away.)
> =A0 =A0 _______________________________________________
> =A0 =A0 apps-discuss mailing list
> =A0 =A0 apps-discuss@ie= tf.org <mailto:apps-discuss= @ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> 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

--f46d04428eb6a7008c04d8b210fa-- From vesely@tana.it Mon Mar 25 05:19:33 2013 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 E39AD21F8BA4 for ; Mon, 25 Mar 2013 05:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 A+7i1XzsydZl for ; Mon, 25 Mar 2013 05:19:33 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E551E21F8BD4 for ; Mon, 25 Mar 2013 05:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364213971; bh=AZxcoQkUcr29n7QBLG5xBOZnvXXyljAkRJYIOtubhRw=; l=2884; h=Date:From:To:References:In-Reply-To; b=WhltP9jQLUtzWnOFW8dv1OFKzsUSzOnY2b4dVKP6yvWH4Ik4g+v6TY+PvkZX5CNrB xUG2ArNi8XrviV+3k1KTIiLEjf0SUphWXJPGWLfCkEkTJNg9tPN2ymJyPCaEDqQMOv J0gi52Dl4cmHdwYQ9NHTs0DE32odjUQAEbwwx6Nc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 25 Mar 2013 13:19:30 +0100 id 00000000005DC039.00000000515040D2.0000552F Message-ID: <515040D2.1080409@tana.it> Date: Mon, 25 Mar 2013 13:19:30 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [apps-discuss] The authentication server id, was rfc5451bis 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, 25 Mar 2013 12:19:34 -0000 On Sun 24/Mar/2013 22:06:41 +0100 Murray S. Kucherawy wrote: > I'm not in favour of changing to a grammar that matches current use to > the exclusion of other uses without a good reason to do so. Since in > the prose we talk about authserv-id being a domain name in the typical > case but basically also say it could be anything the operator wants to > use, I think "value" is the right thing there. Besides the parsability point (quotes), the intended use of this piece of data is rather overloaded. Let me recap some requirements: 1. Identification of the ADMD for assessing trust relationships (and possibly also for POP3 MUAs to send back complaints, per Section 5.3 of RFC 6650), 2. uniqueness of the identifier, 3. similar in syntax to a fully-qualified domain name, 4. transport tracing data such as the SMTP queue ID or a timestamp (semantic hints would also go here, e.g. "all signatures checked but failures not reported" vs "checking stops on first success"), 5. version identification, 6. examples of valid authentication identifiers are "example.com", "mail.example.org", "ms1.newyork.example.com", and "example-auth". Bullets #3 and #6 are compatible with "domain-name". By using domain names in the traditional ways, even though they are not required to be in the DNS, operators can easily implement #1 and #2. Conversely, we'd need production rules to parse a "domain-name" inside the rest of the "value" if the grammar were relaxed that way. Alternatively, we can meet #4 and #5 by relaxing or extending the "version". For example: authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] separator [CFWS] ex-version ] ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF authserv-id = domain-name artext = ALPHA / DIGIT / ; RFC 5322 atext without "=" "-" / "_" / separator separator = "!" / "#" / ; dot-atom characters that cannot "$" / "%" / ; be part of a domain-name "&" / "'" / "*" / "+" / / "/" / "?" / "^" / "`" / "{" / "|" / "}" / "~" ar-dot-text = 1*artext *("." 1*artext) ex-version = [CFWS] ar-dot-text [CFWS] That way, we can be compatible with the current dot-atom, still allow free use, and define the id. It is grammatically involved, as bug fixes often are. Semantically, allowing "anything the operator wants to use" conflicts with the requirement that a parser explicitly knows it, in the new Section 2.4. IMHO, unrecognized ex-versions could just be ignored, as the format is determined by the field name. > We also shouldn't be making changes that aren't either improvements > to the prose or bug fixes to the normative parts. > > Keyword is probably fine for the other three you mentioned. I'll make > that change. This is obviously a bug fix since, as you pointed out, > "dot-atom" permits ambiguous productions. Thanks From superuser@gmail.com Mon Mar 25 11:54:28 2013 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 0A6A721F92BA for ; Mon, 25 Mar 2013 11:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 g87h36X-mdmB for ; Mon, 25 Mar 2013 11:54:27 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id ADCA121F9402 for ; Mon, 25 Mar 2013 11:54:26 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id d46so3429483wer.2 for ; Mon, 25 Mar 2013 11:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rxnjwMqGkJ9oSx7g0nJ5V+387QLIUeq8/iohIaNuH7g=; b=AH1oEG2cfliV28g+Qqvf3ZSvLVYh2yj5ybZLpU+25e+mxts72bXTAGzcbRafPE0WBk FYflxd9HK6O+SqbPYoEQyvs4Pp3Nxb/ylHhmuRJY1rcKrArz3eqFtiB0zkOmlmHHVavl Auszyg4B1x6vIdX5TJFOhd4eTQKl2XEA0EwTIGMBA2XBrbKYCeXOL6IjrHU5UJoFkGRN rnXBD+WyTSnWBIaFYUJWN13FPqUPtPfHYzlmBuAG23IO5W8XcQ6MWAPVV+AUo46pZhKn mJ32MZAOJMIQGXr4v1Glj4IjU/MgA53fpmJoweK/6TGlDZBWuVw+4+g92BC31AkHU6uL W/lA== MIME-Version: 1.0 X-Received: by 10.180.185.44 with SMTP id ez12mr27398096wic.33.1364237665662; Mon, 25 Mar 2013 11:54:25 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 25 Mar 2013 11:54:25 -0700 (PDT) In-Reply-To: <515040D2.1080409@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> Date: Mon, 25 Mar 2013 11:54:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c2257473803104d8c45546 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 25 Mar 2013 18:54:28 -0000 --001a11c2257473803104d8c45546 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 25, 2013 at 5:19 AM, Alessandro Vesely wrote: > On Sun 24/Mar/2013 22:06:41 +0100 Murray S. Kucherawy wrote: > > I'm not in favour of changing to a grammar that matches current use to > > the exclusion of other uses without a good reason to do so. Since in > > the prose we talk about authserv-id being a domain name in the typical > > case but basically also say it could be anything the operator wants to > > use, I think "value" is the right thing there. > > Besides the parsability point (quotes), the intended use of this piece > of data is rather overloaded. Let me recap some requirements: > > 1. Identification of the ADMD for assessing trust relationships > (and possibly also for POP3 MUAs to send back complaints, > per Section 5.3 of RFC 6650), > I don't see a reference to this work there. > 2. uniqueness of the identifier, > This is key for identifying your own, but it doesn't speak to a necessary syntax. > 3. similar in syntax to a fully-qualified domain name, > There's nothing saying an ADMD can't use a simple word or even a single punctuation here (so long as it fits the grammar). Ideally it's most useful when it's in this form, but an ADMD could use "---" as an authserv-id and still get results useful to it. A complete sentence would also be valid. I can't think of a good reason to restrict this to look like a domain name if it doesn't actually represent a single DNS domain entity. One ADMD could be doing authentication service for lots of domains, but it's still one ADMD. If I run a service that does email authentication for tons of domains, why could I not use "Murray's Authentication Service" for an authserv-id? Or even the empty string? As long as the producer and consumer are consistent in their uses of it, all of your stated requirements are met. > 4. transport tracing data such as the SMTP queue ID or a timestamp > (semantic hints would also go here, e.g. "all signatures checked > but failures not reported" vs "checking stops on first success"), > This also doesn't appear to me to demand a specific format (as above). > 5. version identification, > That's not part of the authserv-id itself. > 6. examples of valid authentication identifiers are "example.com", > "mail.example.org", "ms1.newyork.example.com", and "example-auth". > The last string in that list is not what most people think of as a fully-qualified domain name, but as you point out, it's perfectly acceptable. > > Bullets #3 and #6 are compatible with "domain-name". By using domain > names in the traditional ways, even though they are not required to be > in the DNS, operators can easily implement #1 and #2. Conversely, > we'd need production rules to parse a "domain-name" inside the rest of > the "value" if the grammar were relaxed that way. > > Alternatively, we can meet #4 and #5 by relaxing or extending the > "version". For example: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] separator [CFWS] ex-version ] > ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF > > authserv-id = domain-name > > artext = ALPHA / DIGIT / ; RFC 5322 atext without "=" > "-" / "_" / > separator > > separator = "!" / "#" / ; dot-atom characters that cannot > "$" / "%" / ; be part of a domain-name > "&" / "'" / > "*" / "+" / > / "/" / > "?" / > "^" / > "`" / "{" / > "|" / "}" / > "~" > > ar-dot-text = 1*artext *("." 1*artext) > > ex-version = [CFWS] ar-dot-text [CFWS] > I think we're wandering off into some bikeshedding here. I'm curious to know if anyone else supports this more complicated notion. I certainly don't agree with making the "separator" be anything other than "/". The overall grammar is pretty clean right now: break on unescaped semicolons and you get paragraphs of useful information; the first paragraph is the authserv-id stuff, and everything else is "method=result" followed by relevant method parameters; any unescaped "/" followed by a number is a version. Is there a reason to complicate that? Semantically, allowing "anything the operator wants to use" conflicts > with the requirement that a parser explicitly knows it, in the new > Section 2.4. IMHO, unrecognized ex-versions could just be ignored, as > the format is determined by the field name. > How does it conflict? -MSK --001a11c2257473803104d8c45546 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 25, 2013 at 5:19 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
On Sun 24/Mar/2013 22:06:41 +0100 Murray S. = Kucherawy wrote:
> I'm not in favour of changing to a grammar that matches current us= e to
> the exclusion of other uses without a good reason to do so. =A0Since i= n
> the prose we talk about authserv-id being a domain name in the typical=
> case but basically also say it could be anything the operator wants to=
> use, I think "value" is the right thing there.

Besides the parsability point (quotes), the intended use of this piece
of data is rather overloaded. =A0Let me recap some requirements:

1. Identification of the ADMD for assessing trust relationships
=A0 =A0(and possibly also for POP3 MUAs to send back complaints,
=A0 =A0per Section 5.3 of RFC 6650),

I = don't see a reference to this work there.
=A0
2. uniqueness of the identifier,

This i= s key for identifying your own, but it doesn't speak to a necessary syn= tax.
=A0
3. similar in syntax to a fully-qualified domain name,

There's nothing saying an ADMD can't use a simple w= ord or even a single punctuation here (so long as it fits the grammar).=A0 = Ideally it's most useful when it's in this form, but an ADMD could = use "---" as an authserv-id and still get results useful to it.= =A0 A complete sentence would also be valid.

I can't think of a good reason to restrict this to look like a doma= in name if it doesn't actually represent a single DNS domain entity.=A0= One ADMD could be doing authentication service for lots of domains, but it= 's still one ADMD.=A0 If I run a service that does email authentication= for tons of domains, why could I not use "Murray's Authentication= Service" for an authserv-id?=A0 Or even the empty string?=A0 As long = as the producer and consumer are consistent in their uses of it, all of you= r stated requirements are met.
=A0
4. transport tracing data such as the SMTP queue ID or a timestamp
=A0 =A0(semantic hints would also go here, e.g. "all signatures checke= d
=A0 =A0but failures not reported" vs "checking stops on first suc= cess"),

This also doesn't appe= ar to me to demand a specific format (as above).
=A0
5. version identification,

That's n= ot part of the authserv-id itself.
=A0
6. examples of valid authentication identifiers are "example.com",
=A0 =A0"mail.exa= mple.org", "ms1.newyork.example.com", and "example-auth"= .

The last string in that list is not what most people th= ink of as a fully-qualified domain name, but as you point out, it's per= fectly acceptable.
=A0
Semantically, allowing "anything the operator wants to use" confl= icts
with the requirement that a parser explicitly knows it, in the new
Section 2.4. =A0IMHO, unrecognized ex-versions could just be ignored, as the format is determined by the field name.

=
How does it conflict?

-MSK

--001a11c2257473803104d8c45546-- From sm@elandsys.com Mon Mar 25 23:30:41 2013 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 414A821F88FB; Mon, 25 Mar 2013 23:30: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 bYPbT8WCp8VH; Mon, 25 Mar 2013 23:30:40 -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 9C33421F88EF; Mon, 25 Mar 2013 23:30:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.25]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2Q6UQ95023526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 23:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364279439; bh=a6fjdCMI6boZ2b9qUwOnhL0pB5L0xGATO4Q9MlRoQ2o=; h=Date:To:From:Subject:Cc; b=E0jtcGXbNSd9hy4vwvHY+F4QR9PE5b+bbZUSuTZw3TH7FZzXl3vrxjYl5Eqd6XmCA QakS4BN86LrkY8RuA4Cjl1HDx6fj7DQN46juo0HE9gX3gs/woEBbUt9271cb9OCY8X iLOHFJq4aqdPqpsiRWdtQtg8w9n2ep5cgsDeYM4k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1364279439; i=@elandsys.com; bh=a6fjdCMI6boZ2b9qUwOnhL0pB5L0xGATO4Q9MlRoQ2o=; h=Date:To:From:Subject:Cc; b=sCIcAgJ+nmKQ7KKtMAgjS1QJIzsinvyr2lmPqKpMS777ZDLf6HgJxIliU/on/Wb5w fl71TnIw1VM46UIDJM+3zhAuADGugS74DHKsj96SICNmwm1pqcP+LMP+jQjsxPyH0c OY/+kzI3AfUsEBFPxOIOCqC7Wa9T+JvMTeDi9fFo= Message-Id: <6.2.5.6.2.20130325224555.0c22ec60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Mar 2013 23:27:47 -0700 To: apps-discuss@ietf.org, draft-merkle-ikev2-ke-brainpool.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-merkle-ikev2-ke-brainpool-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, 26 Mar 2013 06:30:41 -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-merkle-ikev2-ke-brainpool-03 Title: Using the ECC Brainpool Curves for IKEv2 Key Exchange Reviewer: S. Moonesamy Review Date: March 25, 2013 IETF Last Call Date: February 26, 2013 Summary: This draft is ready for publication as an Informational RFC This document specifies specifies the use of ECC Brainpool elliptic curve groups for key exchange in the Internet Key Exchange version 2 (IKEv2) protocol. It requests the registration of the Transform Type 4 - Diffie-Hellman Group Transform IDs in the Internet Key Exchange Version 2 (IKEv2) Parameters registry. I did not verify the test vectors in Appendix A. I did not find any application considerations in the document. Major issues: None Minor issues: None Regards, S. Moonesamy From vesely@tana.it Tue Mar 26 05:41:15 2013 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 F143721F8AE3 for ; Tue, 26 Mar 2013 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 1eADN3ejvB+q for ; Tue, 26 Mar 2013 05:41:14 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 841E521F8ACE for ; Tue, 26 Mar 2013 05:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364301671; bh=91H1aya8cVLAY3euL7gmY4zL9oulYLUjzl0JczwMvjo=; l=6961; h=Date:From:To:References:In-Reply-To; b=RgZTdpQp2dEydF2mPlJfS01WHM+59lKEfA4BWhSjF4AYDOlPdbBRpacDrW73TvW4x bFI+YGaA92fnkl29zYHPmLYIIY54CCRv4p6PetYW109ahZlcbujtC0pTeVEib8wqO5 X5128HP37xkU+BEabewNLfWnz35kde1UeLjReY8w= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 26 Mar 2013 13:41:11 +0100 id 00000000005DC047.0000000051519767.00005AF9 Message-ID: <51519767.4060808@tana.it> Date: Tue, 26 Mar 2013 13:41:11 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 26 Mar 2013 12:41:15 -0000 On Mon 25/Mar/2013 19:54:25 +0100 Murray S. Kucherawy wrote: > On Mon, Mar 25, 2013 at 5:19 AM, Alessandro Vesely wrote: >> On Sun 24/Mar/2013 22:06:41 +0100 Murray S. Kucherawy wrote: >> >>> Since in the prose we talk about authserv-id being a domain >>> name in the typical case but basically also say it could be >>> anything the operator wants to use, I think "value" is the >>> right thing there. >> >> Besides the parsability point (quotes), the intended use of this piece >> of data is rather overloaded. Let me recap some requirements: >> >> 1. Identification of the ADMD for assessing trust relationships >> (and possibly also for POP3 MUAs to send back complaints, >> per Section 5.3 of RFC 6650), > > I don't see a reference to this work there. That possibility was voiced in the ASRG and elsewhere, but never formalized --which is why I put it in parentheses. AIUI, the authentication server identifies the ADMD responsible for receiving a message. The means of identification, usually a registered domain name, is consistent with the way each method identifies the ADMD(s) responsible for /sending/ the message. >> 2. uniqueness of the identifier, > > This is key for identifying your own, but it doesn't speak to a > necessary syntax. I'm dumbfounded by that statement. How can a piece of software be configured by an ADMD so as to determine whether A-Rs "have been added within its trust boundary"[Section 5] if that software is unable to distinguish the server id from, say, the queue id? >> 3. similar in syntax to a fully-qualified domain name, > > There's nothing saying an ADMD can't use a simple word or even a > single punctuation here (so long as it fits the grammar). Ideally > it's most useful when it's in this form, but an ADMD could use "---" > as an authserv-id and still get results useful to it. "---" doesn't match "domain-name". > A complete sentence would also be valid. If you use "value", yes. However, the methods to determine whether two sentences identify the same ADMD are not part of the common practices. > I can't think of a good reason to restrict this to look like a domain > name if it doesn't actually represent a single DNS domain entity. Well, one could use, e.g, verifier-X.host-Y.my-ADMD.example. In that case, those common practices might suggest that Z.my-ADMD.example belongs to the same ADMD. RFC 5451 does not impose such method, presumably to allow implementers to experiment different ways. > One ADMD could be doing authentication service for lots of domains, > but it's still one ADMD. It's their choice whether to masquerade or not. > If I run a service that does email authentication for tons of > domains, why could I not use "Murray's Authentication Service" for > an authserv-id? Or even the empty string? As long as the producer > and consumer are consistent in their uses of it, all of your stated > requirements are met. In principle, I agree. However, producers and consumers can consist of software developed by several independent programmers. Those agents can interoperate only if programmers agree on a common syntax, so that agents can be configured in ways compatible with one another. >> 4. transport tracing data such as the SMTP queue ID or a timestamp >> (semantic hints would also go here, e.g. "all signatures checked >> but failures not reported" vs "checking stops on first success"), > > This also doesn't appear to me to demand a specific format (as above). It is unspecified how a consumer would use a queue id or a verifier's configuration version. Consonant producers and consumers can carve out a space where to pass useful data from one to the other. The important point is that they don't step on another agent's toes by invading the id proper. >> 5. version identification, > > That's not part of the authserv-id itself. Right, it's similar to #4 in this respect. >> 6. examples of valid authentication identifiers are "example.com" >> "mail.example.org", "ms1.newyork.example.com", and "example-auth". > > The last string in that list is not what most people think of as a > fully-qualified domain name, but as you point out, it's perfectly > acceptable. Yes, albeit that may preclude A-Rs produced that way to cross domain boundaries. >> Bullets #3 and #6 are compatible with "domain-name". By using domain >> names in the traditional ways, even though they are not required to be >> in the DNS, operators can easily implement #1 and #2. Conversely, >> we'd need production rules to parse a "domain-name" inside the rest of >> the "value" if the grammar were relaxed that way. >> >> Alternatively, we can meet #4 and #5 by relaxing or extending the >> "version". [example omitted] > > I think we're wandering off into some bikeshedding here. I'm curious > to know if anyone else supports this more complicated notion. I > certainly don't agree with making the "separator" be anything other > than "/". The text is not stringent: appending a delimiter such as "/" and following it with useful transport tracing data I'd prefer a fixed separator too. How about this: "Authentication-Results:" [CFWS] domain-name [ [CFWS] "/" [CFWS] dot-atom ] ? > The overall grammar is pretty clean right now: break on unescaped > semicolons and you get paragraphs of useful information; the first > paragraph is the authserv-id stuff, and everything else is > "method=result" followed by relevant method parameters; any unescaped > "/" followed by a number is a version. Is there a reason to > complicate that? My attempt is for simplifying, not complicating. The "value" syntax would allow: Authentication-Results: "Murray's Authentication Service; used with permission since version /1. ;-)" / 2; dkim = pass header . d = example.com (...) You'd have to extend the acid test in C.7 to account for that. >> Semantically, allowing "anything the operator wants to use" conflicts >> with the requirement that a parser explicitly knows it, in the new >> Section 2.4. IMHO, unrecognized ex-versions could just be ignored, as >> the format is determined by the field name. > > How does it conflict? For example, assume my MTA is set up such that I can tell from the queue id whether a message arrived to port 25 rather than 587, and I'd like to use that info downstream, e.g. for logging something. It is a hack, admittedly, but the A-R producer I use happens to let me configure it for appending the queue id, so I use that and roll my A-R consumer hack. Now, I also run another A-R consumer, for example spamassassin, which is --will be, hopefully-- able to use existing results rather than computing them from scratch. What should it do when it finds A-R-producer.my-host.my-ADMD/12345? If that is a version number that it knows nothing about, it should discard the field. From lear@cisco.com Tue Mar 26 07:29:36 2013 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 D0E3321F8BCF; Tue, 26 Mar 2013 07:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.812 X-Spam-Level: X-Spam-Status: No, score=-109.812 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 CF0TtUXqvLJz; Tue, 26 Mar 2013 07:29:35 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B450521F8BBC; Tue, 26 Mar 2013 07:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10969; q=dns/txt; s=iport; t=1364308175; x=1365517775; h=message-id:date:from:mime-version:to:cc:subject; bh=lV1b6jV4N+OpQ6x7wESAVEkS6oc98eLazQUDmfXNjjQ=; b=eiM11IspriUj6gqaX/1bGr+TX5qdGthsbJlyB0sWWqhk7goUde9NYl0k OSWaeCYyq9eC08hYfcIv9hRRPkp5YM2054BviGO+4EiWcFa0yZkUGKb0I WRAx3jmgjRGPNct5qcFcOl6qR3jvaqB4I1pI0xOXuMS8J2GGL5B8bnj8E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHmwUVGQ/khR/2dsb2JhbABDhle9K4EFFoEqgkkEQBEBLw0WCwILAwIBAgFYAQcBAYgQDK5ygkCQBI8BEYI0gRMDlmeBH49ogws7gTAk X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208,217";a="12905311" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 26 Mar 2013 14:29:26 +0000 Received: from ams3-vpn-dhcp7552.cisco.com (ams3-vpn-dhcp7552.cisco.com [10.61.93.127]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2QETCQj019938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Mar 2013 14:29:19 GMT Message-ID: <5151B0B5.2090407@cisco.com> Date: Tue, 26 Mar 2013 15:29:09 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: draft-ietf-geopriv-held-measurements.all@tools.ietf.org X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------080609080905010409090802" Cc: 'IESG' , "apps-discuss@ietf.org" Subject: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.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, 26 Mar 2013 14:29:37 -0000 This is a multi-part message in MIME format. --------------080609080905010409090802 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Gents, 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-geopriv-held-measurements-06.txt Title: Using Device-provided Location-Related Measurements in Location Configuration Protocols Reviewer: Eliot Lear Review Date: 26 Mar 2013 Congratulations. Really nice draft. This draft describes a container that can be used to request and report measurements relating to location. It is almost ready for publication. I'd suggest that this draft receive additional review regarding its privacy considerations section. I will comment outside this review regarding that issue, as this is an apps area review. Also, I've not done schema validation. Major issues: § 4.3, page 10: I realize it'd be silly to write a six line RFC for this, but the semantics of the HELD examples seem normative. I think it's appropriate for them to be so, but then you should make it more explicit. Same with your XMPP example. Minor issues: §4.1, 2nd para on page 7. While surely this is applicable for HELD, there are protocols that have size considerations, and so your assertion is a bit strong, and I would suggest that you scope it to be applicable where XML can be carried.(*) §4.4 Page 11, last paragraph. It's not quite clear how the example combines information in the LIS. Maybe it's because I'm not steeped in location lore, so perhaps you might point this out to me, if not others? §8.3, Page 44: there has got to be an existing schema one can borrow IP addresses from, no? If not, is this worth splitting off? Finally, see RFC 2026 for proper use of normative references. You're referencing 802.11v as an informative reference when in fact flightTime depends on TOD and TOA from that spec. And you're normatively referencing RFC 20 (you were just aching to get that one in there) when the ASCII reference is more than sufficient (btw, if you're using xml2rfc you're looking for ANSI.X3-4.1986). I get the following normative: [ASCII], [RFC3629], [RFC5985], [RFC2119], [RFC4119], [IEEE.8021AB], [RFC3046], [RFC4649], [RFC3993], [RFC4580], [IANA.enterprise], [RFC3986], [RFC4291], [IEEE.80211], [RFC5491], [TS.3GPP.23.003], [TIA-2000.5], [GPS.ICD], [GALLILEO.ICD], [RFC2865], [IEEE.80211V] The following are Informative: [RFC3693], [RFC6155], [ANSI-TIA-1057], [RFC2661], [HARPER], [GPS.SPOOF], [RFC5226], [RFC3688], [DSL.TR025], [DSL.TR101] N.B.: regarding TRs 25 and 101, if you meant that other parameters could somehow be pulled in as responses, then more work needs to be done in the draft on this point to specify them. Nits: *Please save the RFC Editor some time and run the thing through a spell checker*. I've only caught a few errors, but I'll bet there are more. * In §2, plain language would dictate that an estimate cannot depend on a determination. A location estimate can be based on reported observations. * HELD should be defined on first use (§ 3, page 5). * Page 5, first paragraph, has some extraneous characters (\u002D). * Page 6, PIDF-LO should be defined on first use. * §4.2.1, Page 9, "multiple samples of a measurement is taken" -> "multiple samples of a measurement are taken" * §4.3 Page 9, last paragraph first sentence, last word: change "a error" to "an error" * Page 12, label the XMPP example. * §5.2, Page 14, remote identifier -> Remote ID or remote-id (depending on whether you refer to RFC 3046 or RFC4649, respectively). Similarly, subscriber-id or Subscriber-ID for RFCs 3993 and 4580. * Page 16, (type specification) introducted -> introduced * idnits indicates that there are 7 instances of lines that are too long, and that RFC 20 is listed as normative without being used in the body. Eliot (*) I thought about whether or not you've chosen the correct format for this sort of information exchange (as opposed to ASN.1 or JSON), and whether or not you should abstract away from it. I think it would be a good idea for somebody (like a grad student) to do that, but in the end your primary application for this is HELD, and the draft is just fine with its use of XML. But it wouldn't kill you to indicate that as possible future work, if someone is interested in this information in very compressed form. --------------080609080905010409090802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Gents,

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-geopriv-held-measurements-06.txt
Title: Using Device-provided Location-Related Measurements in Location Configuration Protocols
Reviewer: Eliot Lear
Review Date: 26 Mar 2013

Congratulations.  Really nice draft.    This draft describes a container that can be used to request and report measurements relating to location.  It is almost ready for publication.

I'd suggest that this draft receive additional review regarding its privacy considerations section.  I will comment outside this review regarding that issue, as this is an apps area review.  Also, I've not done schema validation.

Major issues:

§ 4.3, page 10: I realize it'd be silly to write a six line RFC for this, but the semantics of the HELD examples seem normative.  I think it's appropriate for them to be so, but then you should make it more explicit.  Same with your XMPP example. 

Minor issues:

§4.1, 2nd para on page 7.  While surely this is applicable for HELD, there are protocols that have size considerations, and so your assertion is a bit strong, and I would suggest that you scope it to be applicable where XML can be carried.(*)

§4.4 Page 11, last paragraph.  It's not quite clear how the example combines information in the LIS.  Maybe it's because I'm not steeped in location lore, so perhaps you might point this out to me, if not others?


§8.3, Page 44: there has got to be an existing schema one can borrow IP addresses from, no?  If not, is this worth splitting off?

Finally, see RFC 2026 for proper use of normative references.  You're referencing 802.11v as an informative reference when in fact flightTime depends on TOD and TOA from that spec.  And you're normatively referencing RFC 20 (you were just aching to get that one in there) when the ASCII reference is more than sufficient (btw, if you're using xml2rfc you're looking for ANSI.X3-4.1986).

I get the following normative:

[ASCII], [RFC3629],  [RFC5985], [RFC2119], [RFC4119], [IEEE.8021AB], [RFC3046], [RFC4649], [RFC3993], [RFC4580], [IANA.enterprise], [RFC3986], [RFC4291], [IEEE.80211], [RFC5491], [TS.3GPP.23.003], [TIA-2000.5], [GPS.ICD], [GALLILEO.ICD], [RFC2865], [IEEE.80211V]

The following are Informative:

[RFC3693], [RFC6155], [ANSI-TIA-1057], [RFC2661], [HARPER], [GPS.SPOOF], [RFC5226], [RFC3688], [DSL.TR025], [DSL.TR101]

N.B.: regarding TRs 25 and 101, if you meant that other parameters could somehow be pulled in as responses, then more work needs to be done in the draft on this point to specify them.

Nits:

*Please save the RFC Editor some time and run the thing through a spell checker*.  I've only caught a few errors, but I'll bet there are more.

  • In §2, plain language would dictate that an estimate cannot depend on a determination.  A location estimate can be based on reported observations. 
  • HELD should be defined on first use (§ 3, page 5).
  • Page 5, first paragraph, has some extraneous characters (\u002D).
  • Page 6, PIDF-LO should be defined on first use.
  • §4.2.1, Page 9, "multiple samples of a measurement is taken" -> "multiple samples of a measurement are taken"
  • §4.3 Page 9, last paragraph first sentence, last word: change "a error" to "an error"
  • Page 12, label the XMPP example.
  • §5.2, Page 14, remote identifier -> Remote ID or remote-id (depending on whether you refer to RFC 3046 or RFC4649, respectively).  Similarly, subscriber-id or Subscriber-ID for RFCs 3993 and 4580.
  • Page 16, (type specification) introducted -> introduced
  • idnits indicates that there are 7 instances of lines that are too long, and that RFC 20 is listed as normative without being used in the body.
Eliot

(*) I thought about whether or not you've chosen the correct format for this sort of information exchange (as opposed to ASN.1 or JSON), and whether or not you should abstract away from it.  I think it would be a good idea for somebody (like a grad student) to do that, but in the end your primary application for this is HELD, and the draft is just fine with its use of XML.  But it wouldn't kill you to indicate that as possible future work, if someone is interested in this information in very compressed form.

--------------080609080905010409090802-- From superuser@gmail.com Tue Mar 26 08:35:37 2013 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 73F6C21F8BDD for ; Tue, 26 Mar 2013 08:35:37 -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, HTML_MESSAGE=0.001, 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 cPp4e18Clz2F for ; Tue, 26 Mar 2013 08:35:30 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DF00121F85ED for ; Tue, 26 Mar 2013 08:35:29 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so1038979wib.2 for ; Tue, 26 Mar 2013 08:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kv05qv3QzEz4iRjP1tITE3CNzdJ79Jn9At42jYOLFq8=; b=nfAXFBcKSertpfzS2aOQytTqBd3CZzDWoOIHogWKZCLUiZpl+8r1kyrevec8Vi1LqH SV424ehIFfgGhTrNKKP5/EO2lH0mFLUaJzlORsoBYyBFa6GZptzTF/i7szmYUTbFLC9H 2vL8GZpTIJz8m8k0IrLTLXFfvyq7ZtL4doxEEfhPJyzQ5pKyElO5sCXjVkCCaZDVE26c 0TYdV+hnpetBEiFnUo2Fu1CDUpKy+8vPda/hlKath4BYqTph+D4e7VPraHgBHjGDfI2m mbub4NcAt4+q4Lh65VtT6qb+igYBY38jDejE/42KJ3e6pbMRvUhWgokv7+Xe3BsdAYop V+/A== MIME-Version: 1.0 X-Received: by 10.180.77.226 with SMTP id v2mr3978202wiw.33.1364312128922; Tue, 26 Mar 2013 08:35:28 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Tue, 26 Mar 2013 08:35:28 -0700 (PDT) In-Reply-To: <51519767.4060808@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> Date: Tue, 26 Mar 2013 08:35:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d043c7f1acec8d504d8d5abe5 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 26 Mar 2013 15:35:37 -0000 --f46d043c7f1acec8d504d8d5abe5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 26, 2013 at 5:41 AM, Alessandro Vesely wrote: > >> 1. Identification of the ADMD for assessing trust relationships > >> (and possibly also for POP3 MUAs to send back complaints, > >> per Section 5.3 of RFC 6650), > > > > I don't see a reference to this work there. > > That possibility was voiced in the ASRG and elsewhere, but never > formalized --which is why I put it in parentheses. AIUI, the > authentication server identifies the ADMD responsible for receiving a > message. The means of identification, usually a registered domain > name, is consistent with the way each method identifies the ADMD(s) > responsible for /sending/ the message. > My point is that RFC6650 Section 5.3 says nothing about allowing POP3 MUAs to extract a reporting address from the Authentication-Results header field's authserv-id, so I don't understand why you used it as a reference. Such was never the intent. It's fine to talk about it in ASRG or anywhere else, of course, but that's not in my view a good impetus for now adding that possible meaning here. > >> 2. uniqueness of the identifier, > > > > This is key for identifying your own, but it doesn't speak to a > > necessary syntax. > > I'm dumbfounded by that statement. How can a piece of software be > configured by an ADMD so as to determine whether A-Rs "have been added > within its trust boundary"[Section 5] if that software is unable to > distinguish the server id from, say, the queue id? > That logic presupposes that queue IDs have a known syntax, but they don't. I know of one that uses slashes and hyphens in its queue IDs, for example. But to answer your question directly, any software inside an ADMD seeking to use this field would be configured to look for a particular string right after the header field name and up to the first semicolon, and if that string matches the string it's looking for, then the field can (presumably) be trusted. > > >> 3. similar in syntax to a fully-qualified domain name, > > > > There's nothing saying an ADMD can't use a simple word or even a > > single punctuation here (so long as it fits the grammar). Ideally > > it's most useful when it's in this form, but an ADMD could use "---" > > as an authserv-id and still get results useful to it. > > "---" doesn't match "domain-name". > "domain-name" isn't in the new document except as part of a pvalue. > > > A complete sentence would also be valid. > > If you use "value", yes. However, the methods to determine whether > two sentences identify the same ADMD are not part of the common practices. > There is no obvious reason to preclude the possibility of not using a domain-name there either. > > > One ADMD could be doing authentication service for lots of domains, > > but it's still one ADMD. > > It's their choice whether to masquerade or not. > Indeed. And there's no reason to constrain such masquerading to "domain-name", is there? > > If I run a service that does email authentication for tons of > > domains, why could I not use "Murray's Authentication Service" for > > an authserv-id? Or even the empty string? As long as the producer > > and consumer are consistent in their uses of it, all of your stated > > requirements are met. > > In principle, I agree. However, producers and consumers can consist > of software developed by several independent programmers. Those > agents can interoperate only if programmers agree on a common syntax, > so that agents can be configured in ways compatible with one another. > Isn't that the point of publishing a standard, i.e., this entire exercise? > > >> 4. transport tracing data such as the SMTP queue ID or a timestamp > >> (semantic hints would also go here, e.g. "all signatures checked > >> but failures not reported" vs "checking stops on first success"), > > > > This also doesn't appear to me to demand a specific format (as above). > > It is unspecified how a consumer would use a queue id or a verifier's > configuration version. Consonant producers and consumers can carve > out a space where to pass useful data from one to the other. The > important point is that they don't step on another agent's toes by > invading the id proper. > You seem to be advocating for giving the queue ID its own token in the header field different from the authserv-id in a normative sense. What for? > > >> 5. version identification, > > > > That's not part of the authserv-id itself. > > Right, it's similar to #4 in this respect. > Then I don't understand you claimed it as a separate requirement. > >> 6. examples of valid authentication identifiers are "example.com" > >> "mail.example.org", "ms1.newyork.example.com", and "example-auth". > > > > The last string in that list is not what most people think of as a > > fully-qualified domain name, but as you point out, it's perfectly > > acceptable. > > Yes, albeit that may preclude A-Rs produced that way to cross domain > boundaries. > I don't understand. > > The overall grammar is pretty clean right now: break on unescaped > > semicolons and you get paragraphs of useful information; the first > > paragraph is the authserv-id stuff, and everything else is > > "method=result" followed by relevant method parameters; any unescaped > > "/" followed by a number is a version. Is there a reason to > > complicate that? > > My attempt is for simplifying, not complicating. The "value" syntax > would allow: > > I don't see how the additional grammar you proposed previously (which was half a page long on my screen) simplifies anything. > Authentication-Results: "Murray's Authentication Service; > used with permission since version /1. ;-)" / 2; > dkim = pass header . d = example.com (...) > > You'd have to extend the acid test in C.7 to account for that. > I'm fine with extending the convoluted example to show this possibility. > > >> Semantically, allowing "anything the operator wants to use" conflicts > >> with the requirement that a parser explicitly knows it, in the new > >> Section 2.4. IMHO, unrecognized ex-versions could just be ignored, as > >> the format is determined by the field name. > > > > How does it conflict? > > For example, assume my MTA is set up such that I can tell from the > queue id whether a message arrived to port 25 rather than 587, and I'd > like to use that info downstream, e.g. for logging something. It is a > hack, admittedly, but the A-R producer I use happens to let me > configure it for appending the queue id, so I use that and roll my A-R > consumer hack. Now, I also run another A-R consumer, for example > spamassassin, which is --will be, hopefully-- able to use existing > results rather than computing them from scratch. What should it do > when it finds A-R-producer.my-host.my-ADMD/12345? If that is a > version number that it knows nothing about, it should discard the field. > Attaching the queue ID as part of the authserv-id means you're effectively using a new authserv-id for every message, which is clearly not the intent. It's incumbent on the consumers to figure out what that means. I don't think that (or any hack) should be encoded into the document. But to give you a counter-hack, append the queue ID after a ":" instead of a "/". -MSK --f46d043c7f1acec8d504d8d5abe5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 26, 2013 at 5:41 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
>> 1. Identificatio= n of the ADMD for assessing trust relationships
>> =A0 =A0(and possibly also for POP3 MUAs to send back complaints, >> =A0 =A0per Section 5.3 of RFC 6650),
>
> I don't see a reference to this work there.

That possibility was voiced in the ASRG and elsewhere, but never
formalized --which is why I put it in parentheses. =A0AIUI, the
authentication server identifies the ADMD responsible for receiving a
message. =A0The means of identification, usually a registered domain
name, is consistent with the way each method identifies the ADMD(s)
responsible for /sending/ the message.

= My point is that RFC6650 Section 5.3 says nothing about allowing POP3 MUAs = to extract a reporting address from the Authentication-Results header field= 's authserv-id, so I don't understand why you used it as a referenc= e.=A0 Such was never the intent.=A0 It's fine to talk about it in ASRG = or anywhere else, of course, but that's not in my view a good impetus f= or now adding that possible meaning here.


>> 2. uniqueness of the identifier,
>
> This is key for identifying your own, but it doesn't speak to a > necessary syntax.

I'm dumbfounded by that statement. =A0How can a piece of software= be
configured by an ADMD so as to determine whether A-Rs "have been added=
within its trust boundary"[Section 5] if that software is unable to distinguish the server id from, say, the queue id?
That logic presupposes that queue IDs have a known syntax, but = they don't.=A0 I know of one that uses slashes and hyphens in its queue= IDs, for example.

But to answer your question directly, any software inside an= ADMD seeking to use this field would be configured to look for a particula= r string right after the header field name and up to the first semicolon, a= nd if that string matches the string it's looking for, then the field c= an (presumably) be trusted.
=A0

>> 3. similar in syntax to a fully-qualified domain name,
>
> There's nothing saying an ADMD can't use a simple word or even= a
> single punctuation here (so long as it fits the grammar). =A0Ideally > it's most useful when it's in this form, but an ADMD could use= "---"
> as an authserv-id and still get results useful to it.

"---" doesn't match "domain-name".

"domain-name" isn'= t in the new document except as part of a pvalue.

=A0

> A complete sentence would also be valid.

If you use "value", yes. =A0However, the methods to determi= ne whether
two sentences identify the same ADMD are not part of the common practices.<= br>

There is no obvious reason to preclude = the possibility of not using a domain-name there either.
=A0
=A0
> One ADMD could be doing authentication service for lots of domains, > but it's still one ADMD.

It's their choice whether to masquerade or not.
<= div>
Indeed.=A0 And there's no reason to constrain such m= asquerading to "domain-name", is there?


> If I run a service that does email authentication for tons of
> domains, why could I not use "Murray's Authentication Service= " for
> an authserv-id? =A0Or even the empty string? =A0As long as the produce= r
> and consumer are consistent in their uses of it, all of your stated > requirements are met.

In principle, I agree. =A0However, producers and consumers can consis= t
of software developed by several independent programmers. =A0Those
agents can interoperate only if programmers agree on a common syntax,
so that agents can be configured in ways compatible with one another.

Isn't that the point of publishing a sta= ndard, i.e., this entire exercise?
=A0

>> 4. transport tracing data such as the SMTP queue ID or a timestamp=
>> =A0 =A0(semantic hints would also go here, e.g. "all signatur= es checked
>> =A0 =A0but failures not reported" vs "checking stops on = first success"),
>
> This also doesn't appear to me to demand a specific format (as abo= ve).

It is unspecified how a consumer would use a queue id or a verifier&#= 39;s
configuration version. =A0Consonant producers and consumers can carve
out a space where to pass useful data from one to the other. =A0The
important point is that they don't step on another agent's toes by<= br> invading the id proper.

You seem to be = advocating for giving the queue ID its own token in the header field differ= ent from the authserv-id in a normative sense.=A0 What for?
=A0

>> 5. version identification,
>
> That's not part of the authserv-id itself.

Right, it's similar to #4 in this respect.
<= br>
Then I don't understand you claimed it as a separate requ= irement.


>> 6. examples of valid authentication identifiers are "example.com"
>> =A0 =A0"mail.example.org", "ms1.newyork.example.com&qu= ot;, and "example-auth".
>
> The last string in that list is not what most people think of as a
> fully-qualified domain name, but as you point out, it's perfectly<= br> > acceptable.

Yes, albeit that may preclude A-Rs produced that way to cross domain<= br> boundaries.

I don't understand.
= =A0
> The overall grammar is pretty clean right now: break= on unescaped
> semicolons and you get paragraphs of useful information; the first
> paragraph is the authserv-id stuff, and everything else is
> "method=3Dresult" followed by relevant method parameters; an= y unescaped
> "/" followed by a number is a version. =A0Is there a reason = to
> complicate that?

My attempt is for simplifying, not complicating. =A0The "value&q= uot; syntax
would allow:


I don't see how the additional grammar you pr= oposed previously (which was half a page long on my screen) simplifies anyt= hing.

=A0
=A0 =A0Authentication-Results: "Murray's Authentication Service; =A0 =A0 =A0 used with permission since version /1. ;-)" / 2;
=A0 =A0 =A0 dkim =3D pass header . d =3D example.com (...)

You'd have to extend the acid test in C.7 to account for that.

I'm fine with extending the convoluted exam= ple to show this possibility.
=A0

>> Semantically, allowing "anything the operator wants to use&qu= ot; conflicts
>> with the requirement that a parser explicitly knows it, in the new=
>> Section 2.4. =A0IMHO, unrecognized ex-versions could just be ignor= ed, as
>> the format is determined by the field name.
>
> How does it conflict?

For example, assume my MTA is set up such that I can tell from the queue id whether a message arrived to port 25 rather than 587, and I'd<= br> like to use that info downstream, e.g. for logging something. =A0It is a hack, admittedly, but the A-R producer I use happens to let me
configure it for appending the queue id, so I use that and roll my A-R
consumer hack. =A0Now, I also run another A-R consumer, for example
spamassassin, which is --will be, hopefully-- able to use existing
results rather than computing them from scratch. =A0What should it do
when it finds A-R-producer.my-host.my-ADMD/12345? =A0If that is a
version number that it knows nothing about, it should discard the field.

Attaching the queue ID as part of the authserv-id me= ans you're effectively using a new authserv-id for every message, which= is clearly not the intent.=A0 It's incumbent on the consumers to figur= e out what that means.=A0 I don't think that (or any hack) should be en= coded into the document.

But to give you a counter-hack, append the queue ID after a = ":" instead of a "/".

-MSK=
--f46d043c7f1acec8d504d8d5abe5-- From vesely@tana.it Tue Mar 26 12:27:23 2013 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 023C421F8DBF for ; Tue, 26 Mar 2013 12:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 xp3H05o72C5f for ; Tue, 26 Mar 2013 12:27:22 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9A621F8DC1 for ; Tue, 26 Mar 2013 12:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364326040; bh=mTrb3Ze2tHb4VnIW3WwHA0bExbIB1zIKctGykViIRus=; l=7839; h=Date:From:To:References:In-Reply-To; b=mCBnD/BDA+Zh+VHCsmM12DqFtL6R9r7STHhykgVN4a05nAvLXjmyy4RJjO6q0dBh/ Nzkr47kcvW/PHFgrbRZlirTk/Q4YJLe4mSHlDUyKm2PAdcOcfzk+GaEucR1lD1ZyA6 izE2J5O3aDtyBLZmTVz+oZ0M+OQRFVfGwxM27D00= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 26 Mar 2013 20:27:20 +0100 id 00000000005DC039.000000005151F698.00003B41 Message-ID: <5151F698.60309@tana.it> Date: Tue, 26 Mar 2013 20:27:20 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 26 Mar 2013 19:27:23 -0000 On Tue 26/Mar/2013 16:35:28 +0100 Murray S. Kucherawy wrote: > On Tue, Mar 26, 2013 at 5:41 AM, Alessandro Vesely wrote: > >>>> 1. Identification of the ADMD for assessing trust relationships >>>> (and possibly also for POP3 MUAs to send back complaints, >>>> per Section 5.3 of RFC 6650), >>> >>> I don't see a reference to this work there. >> >> That possibility was voiced in the ASRG and elsewhere, but never >> formalized --which is why I put it in parentheses. AIUI, the >> authentication server identifies the ADMD responsible for receiving a >> message. The means of identification, usually a registered domain >> name, is consistent with the way each method identifies the ADMD(s) >> responsible for /sending/ the message. > > My point is that RFC6650 Section 5.3 says nothing about allowing POP3 MUAs > to extract a reporting address from the Authentication-Results header > field's authserv-id, so I don't understand why you used it as a reference. > Such was never the intent. It's fine to talk about it in ASRG or anywhere > else, of course, but that's not in my view a good impetus for now adding > that possible meaning here. Point taken. I mentioned it to stress that there are cases where authserv-id is consumed outside the ADMD where it was produced. >>>> 2. uniqueness of the identifier, >>> >>> This is key for identifying your own, but it doesn't speak to a >>> necessary syntax. >> >> I'm dumbfounded by that statement. How can a piece of software be >> configured by an ADMD so as to determine whether A-Rs "have been added >> within its trust boundary"[Section 5] if that software is unable to >> distinguish the server id from, say, the queue id? > > That logic presupposes that queue IDs have a known syntax, but they don't. > I know of one that uses slashes and hyphens in its queue IDs, for example. Yes,the queue id is just an example. > But to answer your question directly, any software inside an ADMD seeking > to use this field would be configured to look for a particular string right > after the header field name and up to the first semicolon, and if that > string matches the string it's looking for, then the field can (presumably) > be trusted. It has better be careful to exclude the queue id from the comparison. >>>> 3. similar in syntax to a fully-qualified domain name, >>> >>> There's nothing saying an ADMD can't use a simple word or even a >>> single punctuation here (so long as it fits the grammar). Ideally >>> it's most useful when it's in this form, but an ADMD could use "---" >>> as an authserv-id and still get results useful to it. >> >> [...] > > There is no obvious reason to preclude the possibility of not using a > domain-name there either. A domain name can be used effectively only if the consumer knows it is a domain name. >> One ADMD could be doing authentication service for lots of domains, >>> but it's still one ADMD. >> >> It's their choice whether to masquerade or not. > > Indeed. And there's no reason to constrain such masquerading to > "domain-name", is there? There are pros and cons. Similar arguments hold for the choice of domain that an ADMD uses as d= to sign messages... >>> If I run a service that does email authentication for tons of >>> domains, why could I not use "Murray's Authentication Service" for >>> an authserv-id? Or even the empty string? As long as the producer >>> and consumer are consistent in their uses of it, all of your stated >>> requirements are met. >> >> In principle, I agree. However, producers and consumers can consist >> of software developed by several independent programmers. Those >> agents can interoperate only if programmers agree on a common syntax, >> so that agents can be configured in ways compatible with one another. > > Isn't that the point of publishing a standard, i.e., this entire exercise? Yes! My point is that is a producer is allowed to stuff a queue id somewhere besides the server id, then the consumer has better to expect that possibility. >>>> 4. transport tracing data such as the SMTP queue ID or a timestamp >>>> [...] > > You seem to be advocating for giving the queue ID its own token in > the header field different from the authserv-id in a normative > sense. Exactly! > What for? Anything that it might be useful for. If we think it isn't useful, then the spec should not allow it. >>>> 5. version identification, >>> >>> That's not part of the authserv-id itself. >> >> Right, it's similar to #4 in this respect. > > Then I don't understand you claimed it as a separate requirement. They are both specified. I think it is difficult and useless to have them both to coexist. I'd drop the authserv-id's version. >>>> 6. examples of valid authentication identifiers are "example.com" >>>> "mail.example.org", "ms1.newyork.example.com", and "example-auth". >>> >>> The last string in that list is not what most people think of as a >>> fully-qualified domain name, but as you point out, it's perfectly >>> acceptable. >> >> Yes, albeit that may preclude A-Rs produced that way to cross domain >> boundaries. > > I don't understand. It is quite complicated to let trusted domain's A-R pass through. Using identifiers that are not domain names forces an additional level of indirection, and I'd figure average admins would rather remove them. >> > The overall grammar is pretty clean right now: break on unescaped >> > semicolons and you get paragraphs of useful information; the first >> > paragraph is the authserv-id stuff, and everything else is >> > "method=result" followed by relevant method parameters; any unescaped >> > "/" followed by a number is a version. Is there a reason to >> > complicate that? >> >> My attempt is for simplifying, not complicating. The "value" syntax >> would allow: > > I don't see how the additional grammar you proposed previously (which was > half a page long on my screen) simplifies anything. Importing grammar from external sources doesn't make it simpler. >> Authentication-Results: "Murray's Authentication Service; >> used with permission since version /1. ;-)" / 2; >> dkim = pass header . d = example.com (...) >> >> You'd have to extend the acid test in C.7 to account for that. > > I'm fine with extending the convoluted example to show this possibility. And the (possibly minor) incompatibility with RFC 5451? >>> How does it conflict? >> >> For example, assume my MTA is set up such that I can tell from the >> queue id whether a message arrived to port 25 rather than 587, and I'd >> like to use that info downstream, e.g. for logging something. It is a >> hack, admittedly, but the A-R producer I use happens to let me >> configure it for appending the queue id, so I use that and roll my A-R >> consumer hack. Now, I also run another A-R consumer, for example >> spamassassin, which is --will be, hopefully-- able to use existing >> results rather than computing them from scratch. What should it do >> when it finds A-R-producer.my-host.my-ADMD/12345? If that is a >> version number that it knows nothing about, it should discard the field. > > Attaching the queue ID as part of the authserv-id means you're effectively > using a new authserv-id for every message, which is clearly not the > intent. It's incumbent on the consumers to figure out what that means. I > don't think that (or any hack) should be encoded into the document. But then why do you write: Moreover, some implementations have considered appending a delimiter such as "/" and following it with useful transport tracing data such as the [SMTP] queue ID or a timestamp. ? You can allow or prohibit that, but not both at the same time. From johnl@iecc.com Tue Mar 26 13:16:39 2013 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 40E3321F8DD2 for ; Tue, 26 Mar 2013 13:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 1lMApQLvu5NF for ; Tue, 26 Mar 2013 13:16:38 -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 4111221F8DDA for ; Tue, 26 Mar 2013 13:16:37 -0700 (PDT) Received: (qmail 54176 invoked from network); 26 Mar 2013 20:16:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Mar 2013 20:16:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51520224.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=OKF6mR+BqSsA3UUSUIdxXZ5E9nReEkHgRCXZTZZHmI8=; b=Fg0C+DAmBD0TcOxs5G8ANyi3vRgrz7dVWTYfOM2kwZYokxcLllpbh3Nz93wqgEG/uI0aUgdqNvZa4qUoD4QRrKlXwmybMxA9PVnhgP15w0AW80WRzMm2YE84p0mRiS1j4rdRgHcH85CIE7o/8b/5zPD6md0UIbDTDPWQwpiqNXc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51520224.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=OKF6mR+BqSsA3UUSUIdxXZ5E9nReEkHgRCXZTZZHmI8=; b=jsQ61eRM1N4KauLxGZoDv74Voccet2GFYZxQWktDlc/ANSRcOonPL8i2ZSKy8n3pQUq7H194+icrHYMI5ZhRH/o2NVcRurX90yp7PHjctiuIDNNk7gK/wr7jnBpV+/ACi7mN7dhizrOc6GPUY+h8uyADy8HDlqArfrL1wBD3lYQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 26 Mar 2013 20:16:12 -0000 Message-ID: <20130326201612.33132.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 26 Mar 2013 20:16:39 -0000 The point of the authserv-id is to allow a system to recognize its own A-R headers. I was happy with dot-atom and don't particularly care about changing it to e MIME-ish value, which I gather is to agree with some existing implementations. But I certainly don't see any need to add further complications, which nobody will implement anyway. R's, John PS: In my implementation the authserv-id is the FQDN of the host on which the mail server is running. From superuser@gmail.com Tue Mar 26 14:33:21 2013 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 47DB421F8595 for ; Tue, 26 Mar 2013 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 CYsokUqOu1x5 for ; Tue, 26 Mar 2013 14:33:20 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 654BB21F8585 for ; Tue, 26 Mar 2013 14:33:19 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ez12so1648884wid.0 for ; Tue, 26 Mar 2013 14:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XbgtxS1kgGifE2jzRJgrI4ynyOEbiR1BxRs731PjjUI=; b=qmkCXl6SHQFysldJ0ot3aAPDFDg2YAl50PGX9Er9Ld/a8dVj5S6Kr+mRPftfBdjkVK 7FzYnpZseHeZXr6Q3EesOhfYEKFsD6r5VoG2whERKKjEGzHBlTiih/p7qWPBzXtSjpoW NEJRa0Vzddi4m64r9r9KLwkQMrfpA5YMQgkD7JJ3kCJodWJPMeCyze17QOg5w7ugdYdC m5rvKZKwLMY/fqsC/hRp2KtBDk9bNXiyxj+vnU62qqjsdr76QlW0piWnKECOlucNVDi4 oZTt4162dItfYFiyBs80LMF726Uj1g/7YimkL8OAnATh4Yglg5cnmFrwlF5q+YrAvUSK BWqg== MIME-Version: 1.0 X-Received: by 10.194.178.9 with SMTP id cu9mr27556592wjc.39.1364333598333; Tue, 26 Mar 2013 14:33:18 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Tue, 26 Mar 2013 14:33:17 -0700 (PDT) In-Reply-To: <5151F698.60309@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> Date: Tue, 26 Mar 2013 16:33:17 -0500 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e013d1f287be71d04d8daab06 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 26 Mar 2013 21:33:21 -0000 --089e013d1f287be71d04d8daab06 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 26, 2013 at 2:27 PM, Alessandro Vesely wrote: > > That logic presupposes that queue IDs have a known syntax, but they > don't. > > I know of one that uses slashes and hyphens in its queue IDs, for > example. > > Yes,the queue id is just an example. > So the goal then is to allow the authserv-id to encode arbitrary other details, such as but not including the queue ID, and that one example has a completely unspecified format. This seems like a no-win situation. > > > But to answer your question directly, any software inside an ADMD seeking > > to use this field would be configured to look for a particular string > right > > after the header field name and up to the first semicolon, and if that > > string matches the string it's looking for, then the field can > (presumably) > > be trusted. > > It has better be careful to exclude the queue id from the comparison. > If an ADMD chooses to use the authserv-id to encode details apart from an ADMD identifier, contrary to its stated purpose, then you're absolutely correct. RFC5451 already talks about that. > > >>>> 3. similar in syntax to a fully-qualified domain name, > >>> > >>> There's nothing saying an ADMD can't use a simple word or even a > >>> single punctuation here (so long as it fits the grammar). Ideally > >>> it's most useful when it's in this form, but an ADMD could use "---" > >>> as an authserv-id and still get results useful to it. > >> > >> [...] > > > > There is no obvious reason to preclude the possibility of not using a > > domain-name there either. > > A domain name can be used effectively only if the consumer knows it is > a domain name. > Again, there's nothing saying that it has to be a domain name. It's merely a string that the consumers expect will be set to a certain thing by border MTAs within its own ADMD. I get that it's a convenient construct, and it's a good example, but there's no operational reason to limit it that way. > > >> One ADMD could be doing authentication service for lots of domains, > >>> but it's still one ADMD. > >> > >> It's their choice whether to masquerade or not. > > > > Indeed. And there's no reason to constrain such masquerading to > > "domain-name", is there? > > There are pros and cons. Similar arguments hold for the choice of > domain that an ADMD uses as d= to sign messages... > Quite right. Should this document be making that call? > > >>> If I run a service that does email authentication for tons of > >>> domains, why could I not use "Murray's Authentication Service" for > >>> an authserv-id? Or even the empty string? As long as the producer > >>> and consumer are consistent in their uses of it, all of your stated > >>> requirements are met. > >> > >> In principle, I agree. However, producers and consumers can consist > >> of software developed by several independent programmers. Those > >> agents can interoperate only if programmers agree on a common syntax, > >> so that agents can be configured in ways compatible with one another. > > > > Isn't that the point of publishing a standard, i.e., this entire > exercise? > > Yes! My point is that is a producer is allowed to stuff a queue id > somewhere besides the server id, then the consumer has better to > expect that possibility. > Absolutely correct, and also absolutely not something that has to be specified here beyond making it a "value". I'd be happy to add text saying this specifically if necessary. > > >>>> 4. transport tracing data such as the SMTP queue ID or a timestamp > >>>> [...] > > > > You seem to be advocating for giving the queue ID its own token in > > the header field different from the authserv-id in a normative > > sense. > > Exactly! > > > What for? > > Anything that it might be useful for. If we think it isn't useful, > then the spec should not allow it. > So why doesn't making authserv-id a "value" accommodate that case? > > >>>> 5. version identification, > >>> > >>> That's not part of the authserv-id itself. > >> > >> Right, it's similar to #4 in this respect. > > > > Then I don't understand you claimed it as a separate requirement. > > They are both specified. I think it is difficult and useless to have > them both to coexist. I'd drop the authserv-id's version. > The authserv-id doesn't have a version in the ABNF. That version is the version of the A-R specification as a whole. It's a convenient place to attach that information (e.g., "this ADMD is using A-R version 'x'"), and consistent with use of versions on the method tokens. > > >>>> 6. examples of valid authentication identifiers are "example.com" > >>>> "mail.example.org", "ms1.newyork.example.com", and "example-auth". > >>> > >>> The last string in that list is not what most people think of as a > >>> fully-qualified domain name, but as you point out, it's perfectly > >>> acceptable. > >> > >> Yes, albeit that may preclude A-Rs produced that way to cross domain > >> boundaries. > > > > I don't understand. > > It is quite complicated to let trusted domain's A-R pass through. > Using identifiers that are not domain names forces an additional level > of indirection, and I'd figure average admins would rather remove them. > Why is it quite complicated? Trusted authserv-ids is merely a set of strings. If you're looking at an A-R header field whose authserv-id is in that list, you've decided explicitly that its content can be trusted. Anything else should either be ignored or removed (depending on which agent is looking at it). It only gets complicated if you choose to overload that field with your own purposes by encoding other data in it. If some people find that useful, then great, but I don't think this specification should describe how to do that beyond not explicitly blocking it. > >> Authentication-Results: "Murray's Authentication Service; > >> used with permission since version /1. ;-)" / 2; > >> dkim = pass header . d = example.com (...) > >> > >> You'd have to extend the acid test in C.7 to account for that. > > > > I'm fine with extending the convoluted example to show this possibility. > > And the (possibly minor) incompatibility with RFC 5451? > The specific thing you're talking about, namely the occasional practice of encoding queue IDs into authserv-ids, is already incompatible with RFC5451. This change adapts to current use. > > >>> How does it conflict? > >> > >> For example, assume my MTA is set up such that I can tell from the > >> queue id whether a message arrived to port 25 rather than 587, and I'd > >> like to use that info downstream, e.g. for logging something. It is a > >> hack, admittedly, but the A-R producer I use happens to let me > >> configure it for appending the queue id, so I use that and roll my A-R > >> consumer hack. Now, I also run another A-R consumer, for example > >> spamassassin, which is --will be, hopefully-- able to use existing > >> results rather than computing them from scratch. What should it do > >> when it finds A-R-producer.my-host.my-ADMD/12345? If that is a > >> version number that it knows nothing about, it should discard the field. > > > > Attaching the queue ID as part of the authserv-id means you're > effectively > > using a new authserv-id for every message, which is clearly not the > > intent. It's incumbent on the consumers to figure out what that means. > I > > don't think that (or any hack) should be encoded into the document. > > But then why do you write: > > Moreover, some > implementations have considered appending a delimiter such as "/" and > following it with useful transport tracing data such as the [SMTP] > queue ID or a timestamp. > ? > > You can allow or prohibit that, but not both at the same time. > Keep reading; the remainder of that section actively discourages the practice. There are a lot of things that standards enable but also say "You could do this, but there are costs involved." This is one of them. -MSK --089e013d1f287be71d04d8daab06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 26, 2013 at 2:27 PM, Alessandro Vesely <vesely@t= ana.it> wrote:
> That logic presupposes that queue IDs have a known syntax, but they do= n't.
> I know of one that uses slashes and hyphens in its queue IDs, for exam= ple.

Yes,the queue id is just an example.

So the goal = then is to allow the authserv-id to encode arbitrary other details, such as= but not including the queue ID, and that one example has a completely unsp= ecified format.=A0 This seems like a no-win situation.
=A0

> But to answer your question directly, any software inside an ADMD seek= ing
> to use this field would be configured to look for a particular string = right
> after the header field name and up to the first semicolon, and if that=
> string matches the string it's looking for, then the field can (pr= esumably)
> be trusted.

It has better be careful to exclude the queue id from the comparison.=

If an ADMD chooses to use the authserv= -id to encode details apart from an ADMD identifier, contrary to its stated= purpose, then you're absolutely correct.=A0 RFC5451 already talks abou= t that.
=A0

>>>> 3. similar in syntax to a fully-qualified domain name,
>>>
>>> There's nothing saying an ADMD can't use a simple word= or even a
>>> single punctuation here (so long as it fits the grammar). =A0I= deally
>>> it's most useful when it's in this form, but an ADMD c= ould use "---"
>>> as an authserv-id and still get results useful to it.
>>
>> [...]
>
> There is no obvious reason to preclude the possibility of not using a<= br> > domain-name there either.

A domain name can be used effectively only if the consumer knows it i= s
a domain name.

Again, there's nothi= ng saying that it has to be a domain name.=A0 It's merely a string that= the consumers expect will be set to a certain thing by border MTAs within = its own ADMD.=A0 I get that it's a convenient construct, and it's a= good example, but there's no operational reason to limit it that way.<= br> =A0

>> One ADMD could be doing authentication service for lots of domains= ,
>>> but it's still one ADMD.
>>
>> It's their choice whether to masquerade or not.
>
> Indeed. =A0And there's no reason to constrain such masquerading to=
> "domain-name", is there?

There are pros and cons. =A0Similar arguments hold for the choice of<= br> domain that an ADMD uses as d=3D to sign messages...
<= br>
Quite right.=A0 Should this document be making that call?
= =A0

>>> If I run a service that does email authentication for tons of<= br> >>> domains, why could I not use "Murray's Authentication= Service" for
>>> an authserv-id? =A0Or even the empty string? =A0As long as the= producer
>>> and consumer are consistent in their uses of it, all of your s= tated
>>> requirements are met.
>>
>> In principle, I agree. =A0However, producers and consumers can con= sist
>> of software developed by several independent programmers. =A0Those=
>> agents can interoperate only if programmers agree on a common synt= ax,
>> so that agents can be configured in ways compatible with one anoth= er.
>
> Isn't that the point of publishing a standard, i.e., this entire e= xercise?

Yes! =A0My point is that is a producer is allowed to stuff a queue id=
somewhere besides the server id, then the consumer has better to
expect that possibility.

Absolutely cor= rect, and also absolutely not something that has to be specified here beyon= d making it a "value".

I'd be happy to add = text saying this specifically if necessary.
=A0

>>>> 4. transport tracing data such as the SMTP queue ID or a t= imestamp
>>>> [...]
>
> You seem to be advocating for giving the queue ID its own token in
> the header field different from the authserv-id in a normative
> sense.

Exactly!

> What for?

Anything that it might be useful for. =A0If we think it isn't useful, then the spec should not allow it.

So w= hy doesn't making authserv-id a "value" accommodate that case= ?
=A0

>>>> 5. version identification,
>>>
>>> That's not part of the authserv-id itself.
>>
>> Right, it's similar to #4 in this respect.
>
> Then I don't understand you claimed it as a separate requirement.<= br>
They are both specified. =A0I think it is difficult and useless to ha= ve
them both to coexist. =A0I'd drop the authserv-id's version.

The authserv-id doesn't have a version in= the ABNF.=A0 That version is the version of the A-R specification as a who= le.=A0 It's a convenient place to attach that information (e.g., "= this ADMD is using A-R version 'x'"), and consistent with use = of versions on the method tokens.

=A0

>>>> 6. examples of valid authentication identifiers are "= example.com"
>>>> =A0 =A0"mail.example.org", "ms1.newyork.example.com", and "e= xample-auth".
>>>
>>> The last string in that list is not what most people think of = as a
>>> fully-qualified domain name, but as you point out, it's pe= rfectly
>>> acceptable.
>>
>> Yes, albeit that may preclude A-Rs produced that way to cross doma= in
>> boundaries.
>
> I don't understand.

It is quite complicated to let trusted domain's A-R pass through.=
Using identifiers that are not domain names forces an additional level
of indirection, and I'd figure average admins would rather remove them.=

Why is it quite complicated?=A0 Truste= d authserv-ids is merely a set of strings.=A0 If you're looking at an A= -R header field whose authserv-id is in that list, you've decided expli= citly that its content can be trusted.=A0 Anything else should either be ig= nored or removed (depending on which agent is looking at it).

It only gets complicated if you choose to overload that fiel= d with your own purposes by encoding other data in it.=A0 If some people fi= nd that useful, then great, but I don't think this specification should= describe how to do that beyond not explicitly blocking it.
=A0
&= gt;> =A0 =A0Authentication-Results: "Murray's Authentication Se= rvice;
>> =A0 =A0 =A0 used with permission since version /1. ;-)" / 2;<= br> >> =A0 =A0 =A0 dkim =3D pass header . d =3D example.com (...)
>>
>> You'd have to extend the acid test in C.7 to account for that.=
>
> I'm fine with extending the convoluted example to show this possib= ility.

And the (possibly minor) incompatibility with RFC 5451?

The specific thing you're talking about, namely = the occasional practice of encoding queue IDs into authserv-ids, is already= incompatible with RFC5451.=A0 This change adapts to current use.
=A0

>>> How does it conflict?
>>
>> For example, assume my MTA is set up such that I can tell from the=
>> queue id whether a message arrived to port 25 rather than 587, and= I'd
>> like to use that info downstream, e.g. for logging something. =A0I= t is a
>> hack, admittedly, but the A-R producer I use happens to let me
>> configure it for appending the queue id, so I use that and roll my= A-R
>> consumer hack. =A0Now, I also run another A-R consumer, for exampl= e
>> spamassassin, which is --will be, hopefully-- able to use existing=
>> results rather than computing them from scratch. =A0What should it= do
>> when it finds A-R-producer.my-host.my-ADMD/12345? =A0If that is a<= br> >> version number that it knows nothing about, it should discard the = field.
>
> Attaching the queue ID as part of the authserv-id means you're eff= ectively
> using a new authserv-id for every message, which is clearly not the > intent. =A0It's incumbent on the consumers to figure out what that= means. =A0I
> don't think that (or any hack) should be encoded into the document= .

But then why do you write:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Moreover, some
=A0implementations have considered appending a delimiter such as "/&qu= ot; and
=A0following it with useful transport tracing data such as the [SMTP]
=A0queue ID or a timestamp.
?

You can allow or prohibit that, but not both at the same time.

Keep reading; the remainder of that section activel= y discourages the practice.

There are a lot of things that standards= enable but also say "You could do this, but there are costs involved.= "=A0 This is one of them.

-MSK

--089e013d1f287be71d04d8daab06-- From dret@berkeley.edu Tue Mar 26 19:33:07 2013 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 8BC1F21F85BF for ; Tue, 26 Mar 2013 19:33:07 -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 4k4THWXunjb7 for ; Tue, 26 Mar 2013 19:33:07 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2098421F85B3 for ; Tue, 26 Mar 2013 19:33:07 -0700 (PDT) Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.97]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UKgAe-0006Ux-D3; Tue, 26 Mar 2013 19:33:06 -0700 Message-ID: <51525A58.2020803@berkeley.edu> Date: Tue, 26 Mar 2013 19:32:56 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130327023118.32662.16489.idtracker@ietfa.amsl.com> In-Reply-To: <20130327023118.32662.16489.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130327023118.32662.16489.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: New Version Notification for draft-sinnema-xacml-media-type-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, 27 Mar 2013 02:33:07 -0000 A new version of I-D, draft-sinnema-xacml-media-type-02.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-sinnema-xacml-media-type Revision: 02 Title: eXtensible Access Control Markup Language (XACML) Media Type Creation date: 2013-03-26 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-sinnema-xacml-media-type-02.txt Status: http://datatracker.ietf.org/doc/draft-sinnema-xacml-media-type Htmlized: http://tools.ietf.org/html/draft-sinnema-xacml-media-type-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-sinnema-xacml-media-type-02 Abstract: This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). Note to Readers This draft should be discussed on the apps-discuss mailing list. From dave@cridland.net Wed Mar 27 01:47:38 2013 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 08BF521F90E1 for ; Wed, 27 Mar 2013 01:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 KliVM-8WD5p5 for ; Wed, 27 Mar 2013 01:47:37 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E509321F90DE for ; Wed, 27 Mar 2013 01:47:36 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wd20so8032680obb.9 for ; Wed, 27 Mar 2013 01:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mWSVvSiA7up9u50UPdrrx2rz1TBEDxpo6Y9+3JRuFvI=; b=HQyW+RcRLI+QdR9Q4gWAM6a3GHOWUu02JLpLARgOBUibwcv8RJ9DISG1LFcMtxbwkh C+0a7IRPYjw8SWYFFXGnkyR50xTh1FbMpgWBwThJajgr7mBnRL5EuTeSM5KuV3jUrkix syf4Jud/w4PXTg25IE+s5wdWQjlXk6jm78zbw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=mWSVvSiA7up9u50UPdrrx2rz1TBEDxpo6Y9+3JRuFvI=; b=elIFrMs2pwUaTVBJ1FtGnd4BP9vpYpaMFOY4TgFhKK8Oi7ao/d7QvQu8iTW07knNNY TQyegvxdcWuaTYWOsWPoIv1V3IfphiCwGjtz8/Da958Uz+oTg1AcvY8BAd4Ocnn13YDG VGEY4UGb3rBaEF/s74iaLeANntU91OD/jKJZG51vz7ePTVD8cso/zv05fd43IB2l9T68 mTbJw0fkLN11TOqe4l9+Gixo9u2X8TulY5r16dKh0uFm3+ttchqCaZ8mz2q85yZosZtt ZUWcYXOvZXJe4qKPKwW8QTxj7Y3Cdu81A8Mq2/BCouPaJOtRNVFYwCoi+9MOn4Sb8dJH Fsyw== MIME-Version: 1.0 X-Received: by 10.60.117.3 with SMTP id ka3mr1334516oeb.67.1364374055813; Wed, 27 Mar 2013 01:47:35 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Wed, 27 Mar 2013 01:47:35 -0700 (PDT) Received: by 10.60.22.105 with HTTP; Wed, 27 Mar 2013 01:47:35 -0700 (PDT) In-Reply-To: <583081CD-147D-4DFD-8C9A-E02F06F2E0EB@cisco.com> References: <583081CD-147D-4DFD-8C9A-E02F06F2E0EB@cisco.com> Date: Wed, 27 Mar 2013 08:47:35 +0000 Message-ID: From: Dave Cridland To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=047d7b417ffbf018fa04d8e416a6 X-Gm-Message-State: ALoCoQl3jsQbhvaLVTSvhvPRyazv3x1Q89LpM8R9jrIHQStlkSsJbIl9oHUQbfbEnxn6lEwsVKrZ Cc: draft-ietf-appsawg-acct-uri.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-acct-uri-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, 27 Mar 2013 08:47:38 -0000 --047d7b417ffbf018fa04d8e416a6 Content-Type: text/plain; charset=ISO-8859-1 Thanks. This completely satisfies my comments. On 27 Mar 2013 02:02, "Peter Saint-Andre" wrote: > On Mar 11, 2013, at 9:38 AM, Dave Cridland 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-ietf-appsawg-webfinger-11 > Title: The 'acct' URI Scheme > Reviewer: Dave Cridland > Review Date: 2013/03/11 > > Summary: Ready for publication as Standards Track. Although I note one > possible additional security consideration it is minor. > > Editorial Comments: > > 1) I do love the use of "discussants", but I hesitantly wonder if the more > common (if less specific) "participants" would be a more readily understood > choice of word? > > > I'll change it "the participants in that discussion". > > Minor Comments: > > 1) I note that an acct scheme URI provides proof of existence of the > account; this implies that harvesting published acct URIs would be useful > for spammers and similar attackers, if they can also use this to leverage > more information about the account (such as via WebFinger). > > > Good point. I'll add text to the Security Considerations on this point > (expect a revised I-D at some point in the near future). > > Peter > > > --047d7b417ffbf018fa04d8e416a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks. This completely satisfies my comments.

On 27 Mar 2013 02:02, "Peter Saint-Andre&qu= ot; <psaintan@cisco.com> wr= ote:
On Mar 11, 2013, at 9:38 AM, = Dave Cridland wrote:

I have been selected as the Applications Area Directorate reviewer for t= his draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat= e ).

Please resolve these comments along with any other Las= t Call comments you may receive. Please wait for direction from your docume= nt shepherd or AD before posting a new version of the draft.
Document: draft-ietf-appsawg-webfinger-11
Title:=A0The 'acct' URI = Scheme
Reviewer: Dave Cridland
Review Date: 2013= /03/11

Summary: Ready for publication as Standards Track. Alth= ough I note one possible additional security consideration it is minor.
=

Editorial Comments:

1) I do love the use of "discussants", but I hesitantly wonder if= the more common (if less specific) "participants" would be a mor= e readily understood choice of word?

I'll change it "the participants in that discussion".

Minor Comments:

1) I note that an acct scheme URI provides proof of e= xistence of the account; this implies that harvesting published acct URIs w= ould be useful for spammers and similar attackers, if they can also use thi= s to leverage more information about the account (such as via WebFinger).

Good point. I'll add text to the Sec= urity Considerations on this point (expect a revised I-D at some point in t= he near future).

Peter


--047d7b417ffbf018fa04d8e416a6-- From vesely@tana.it Wed Mar 27 05:15:26 2013 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 62F8221F9019 for ; Wed, 27 Mar 2013 05:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 DbyqqBcFDswq for ; Wed, 27 Mar 2013 05:15:25 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CF98921F9047 for ; Wed, 27 Mar 2013 05:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364386523; bh=OKB34Luehy2eHHt7m2HkmMqHBPzNHDVjBAVtUc5qvm4=; l=5109; h=Date:From:To:References:In-Reply-To; b=UkkSSkv+Je8sulv9vbAt9HoXWjWnFK1Pia4AlaFwXUFxEpKzlWtlj7aiqYeOwkltN /8evPWU6/ovZ17Ji82rpAPpnbyCr6yHQjMgdLjwyOQttkBEMsx+sABtRkqocOSTkb4 FZGub2os+p72g5SJQJBaJmZUcbkLdMqjWjMBOI8E= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 27 Mar 2013 13:15:23 +0100 id 00000000005DC039.000000005152E2DB.00007D90 Message-ID: <5152E2DB.4030807@tana.it> Date: Wed, 27 Mar 2013 13:15:23 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 27 Mar 2013 12:15:26 -0000 On Tue 26/Mar/2013 22:33:17 +0100 Murray S. Kucherawy wrote: >>> But to answer your question directly, any software inside an ADMD seeking >>> to use this field would be configured to look for a particular string right >>> after the header field name and up to the first semicolon, and if that >>> string matches the string it's looking for, then the field can (presumably) >>> be trusted. >> >> It has better be careful to exclude the queue id from the comparison. > > If an ADMD chooses to use the authserv-id to encode details apart from an > ADMD identifier, contrary to its stated purpose, then you're absolutely > correct. RFC5451 already talks about that. Ok, that is starting to make some sense. Maybe it's me, but reading RFC 5451 as well as its bis I had the false impression that the spec not only allows but even encourages such practice. I'll try and suggest an alternative text at the bottom. >>>> One ADMD could be doing authentication service for lots of domains, >>>>> but it's still one ADMD. >>>> >>>> It's their choice whether to masquerade or not. >>> >>> Indeed. And there's no reason to constrain such masquerading to >>> "domain-name", is there? >> >> There are pros and cons. Similar arguments hold for the choice of >> domain that an ADMD uses as d= to sign messages... > > Quite right. Should this document be making that call? No. However I'd like a discourse on virtual domains, I don't think this I-D is the right place to develop it. >>> What [would transport tracing data and such be useful] for? >> >> Anything that it might be useful for. If we think it isn't useful, >> then the spec should not allow it. > > So why doesn't making authserv-id a "value" accommodate that case? It would overkill, considering that we'd tend to discourage complicated stuff. A "dot-atom" can have a slash, but perhaps we can live with that. Otherwise, a "token" can be fit. >> It is quite complicated to let trusted domain's A-R pass through. > > Why is it quite complicated? Trusted authserv-ids is merely a set of > strings. If you're looking at an A-R header field whose authserv-id is in > that list, you've decided explicitly that its content can be trusted. > Anything else should either be ignored or removed (depending on which agent > is looking at it). IMHO, the first paragraph of Section 5 is too mild. It could be hardened like so: OLD For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary and that did not come directly from another trusted MTA. NEW For security reasons, any MTA conforming to this specification MUST remove or rename any instance of this header field that was not added within its trust boundary. The authentication service identifier (authserv-id) is used to identify the agent which added the header field, with the limits described in Section 7.1. If an MTA kills only the A-Rs that it can clearly identify as forgeries, it would let thru any A-R field bearing some unknown identifier. Those identifiers may be forged. If they match a trusted id at the next ADMD (MTA or MUA), then if the latter trusts the former, it has no obvious reason to suspect. It gets complicated if one tries to derive trustworthiness from routing considerations. Renaming rather than removing solves some issues with debugging and signature verification, so I'd consider it anyway. I don't understand the "(border or otherwise)", still in the first paragraph. If it is an internal MTA it shouldn't delete fields added by the border MTA of example.com. The rest of the section becomes more stringent, which seems to be correct. > It only gets complicated if you choose to overload that field with your own > purposes by encoding other data in it. If some people find that useful, > then great, but I don't think this specification should describe how to do > that beyond not explicitly blocking it. Fine! >>> I don't think that (or any hack) should be encoded into the >>> document. >> >> But then why do you write: >> >> Moreover, some >> implementations have considered appending a delimiter such as "/" and >> following it with useful transport tracing data such as the [SMTP] >> queue ID or a timestamp. >> ? >> >> You can allow or prohibit that, but not both at the same time. > > Keep reading; the remainder of that section actively discourages the > practice. Here's the alternative text I promised above: Consistently with the scope limit outlined in Section 1.2, the grammar does not constrain the authentication identifier to be a domain name. Improper use could thus consider appending a delimiter such as "#" and following it with useful transport tracing data such as the [SMTP] queue ID or a timestamp. > There are a lot of things that standards enable but also say "You could do > this, but there are costs involved." This is one of them. From superuser@gmail.com Wed Mar 27 05:56:31 2013 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 63CD721F8FEC for ; Wed, 27 Mar 2013 05:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=0.559, 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 FlbPm0khnIsp for ; Wed, 27 Mar 2013 05:56:30 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id CF69021F8FDF for ; Wed, 27 Mar 2013 05:56:29 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so441078wgh.21 for ; Wed, 27 Mar 2013 05:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=J4jeB/sJdegnLK1pyAu4q1HIRDO67lZKaS18knplH94=; b=msHoz7VxRYzm9dNty/NvOGC2kIwvL5RuOQ4O9T2ol4QXONNLSEezVP6NPa3YJXWMAd 55uZp8N9gnDv7Soi8q6L53CkvF530dHIwax3fNRqcVk9kgIROK32Hf1ar/SQkskgtH36 YQQHS3x5xy6WXedHhOUxl6kUegQTSZH47ha8k+qymQ6aoU0WuLRi6RVNGuaPFqwB5GpK 3VcYC6dUPeETCaV3v3Qa/NapJdGG6cEEHbMcxsU/j1NNCMslrnKQdv1rOqrHmF6vJ07+ Gtje4b30xsJKwqFoeYLhkhBjSlFok4yqqDttuB1TKDYs/D6AXyBq7lgPw6deN+wQYP12 HKrw== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr31109666wjc.35.1364388989013; Wed, 27 Mar 2013 05:56:29 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Wed, 27 Mar 2013 05:56:28 -0700 (PDT) In-Reply-To: <5152E2DB.4030807@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> Date: Wed, 27 Mar 2013 13:56:28 +0100 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e013d1da8069a2104d8e7919e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 27 Mar 2013 12:56:31 -0000 --089e013d1da8069a2104d8e7919e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 27, 2013 at 1:15 PM, Alessandro Vesely wrote: > >>> What [would transport tracing data and such be useful] for? > >> > >> Anything that it might be useful for. If we think it isn't useful, > >> then the spec should not allow it. > > > > So why doesn't making authserv-id a "value" accommodate that case? > > It would overkill, considering that we'd tend to discourage > complicated stuff. A "dot-atom" can have a slash, but perhaps we can > live with that. Otherwise, a "token" can be fit. > A quoted string is complicated? They've been used in email header fields for quite a long time now. > > >> It is quite complicated to let trusted domain's A-R pass through. > > > > Why is it quite complicated? Trusted authserv-ids is merely a set of > > strings. If you're looking at an A-R header field whose authserv-id is > in > > that list, you've decided explicitly that its content can be trusted. > > Anything else should either be ignored or removed (depending on which > agent > > is looking at it). > > IMHO, the first paragraph of Section 5 is too mild. It could be > hardened like so: > > OLD > For security reasons, any MTA conforming to this specification MUST > delete any discovered instance of this header field that claims, by > virtue of its authentication service identifier, to have been added > within its trust boundary and that did not come directly from another > trusted MTA. > > NEW > For security reasons, any MTA conforming to this specification MUST > remove or rename any instance of this header field that was not added > within its trust boundary. The authentication service identifier > (authserv-id) is used to identify the agent which added the header > field, with the limits described in Section 7.1. > > If an MTA kills only the A-Rs that it can clearly identify as > forgeries, it would let thru any A-R field bearing some unknown > identifier. Those identifiers may be forged. If they match a trusted > id at the next ADMD (MTA or MUA), then if the latter trusts the > former, it has no obvious reason to suspect. It gets complicated if > one tries to derive trustworthiness from routing considerations. > If consumers are already looking only for A-Rs that use an expected authserv-id, and ignoring others, what's the harm in letting the other ones through? The document already goes as far as saying one can also remove all of them if it chooses, just to be safe. Renaming them is probably also fine, but I'm skeptical about adding that here since you're renaming within a registered namespace. > Renaming rather than removing solves some issues with debugging and > signature verification, so I'd consider it anyway. > True, but the agent removing suspect header fields could also log or otherwise record them as it does so. > > I don't understand the "(border or otherwise)", still in the first > paragraph. If it is an internal MTA it shouldn't delete fields added > by the border MTA of example.com. The rest of the section becomes > more stringent, which seems to be correct. > Yeah, I don't know what that means either. If I can't come up with a good reason to keep it, I'll remove it in the next version. Here's the alternative text I promised above: > > Consistently with the > scope limit outlined in Section 1.2, the grammar does not constrain > the authentication identifier to be a domain name. Improper use > could thus consider appending a delimiter such as "#" and following > it with useful transport tracing data such as the [SMTP] queue ID or > a timestamp. > Isn't that materially the same as what's already in Section 2.3? -MSK --089e013d1da8069a2104d8e7919e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 27, 2013 at 1:15 PM, Alessandro Vesely <vesely@t= ana.it> wrote:
>>> What [would transport tracing d= ata and such be useful] for?
>>
>> Anything that it might be useful for. =A0If we think it isn't = useful,
>> then the spec should not allow it.
>
> So why doesn't making authserv-id a "value" accommodate = that case?

It would overkill, considering that we'd tend to discourage
complicated stuff. =A0A "dot-atom" can have a slash, but perhaps = we can
live with that. =A0Otherwise, a "token" can be fit.

A quoted string is complicated?=A0 They've been = used in email header fields for quite a long time now.
=A0

>> It is quite complicated to let trusted domain's A-R pass throu= gh.
>
> Why is it quite complicated? =A0Trusted authse= rv-ids is merely a set of
> strings. =A0If you're looking at an A-R header field whose authser= v-id is in
> that list, you've decided explicitly that its content can be trust= ed.
> Anything else should either be ignored or removed (depending on which = agent
> is looking at it).

IMHO, the first paragraph of Section 5 is too mild. =A0It could be hardened like so:

OLD
=A0For security reasons, any MTA conforming to this specification MUST
=A0delete any discovered instance of this header field that claims, by
=A0virtue of its authentication service identifier, to have been added
=A0within its trust boundary and that did not come directly from another =A0trusted MTA.

NEW
=A0For security reasons, any MTA conforming to this specification MUST
=A0remove or rename any instance of this header field that was not added =A0within its trust boundary. =A0The authentication service identifier
=A0(authserv-id) is used to identify the agent which added the header
=A0field, with the limits described in Section 7.1.

If an MTA kills only the A-Rs that it can clearly identify as
forgeries, it would let thru any A-R field bearing some unknown
identifier. =A0Those identifiers may be forged. =A0If they match a trusted<= br> id at the next ADMD (MTA or MUA), then if the latter trusts the
former, it has no obvious reason to suspect. =A0It gets complicated if
one tries to derive trustworthiness from routing considerations.

If consumers are already looking only for A-Rs th= at use an expected authserv-id, and ignoring others, what's the harm in= letting the other ones through?

The document already goes as far as saying one can also remove all of t= hem if it chooses, just to be safe.=A0 Renaming them is probably also fine,= but I'm skeptical about adding that here since you're renaming wit= hin a registered namespace.


Renaming rather than removing solves some issues with debugging and
signature verification, so I'd consider it anyway.

True, but the agent removing suspect header fields could al= so log or otherwise record them as it does so.
=A0

I don't understand the "(border or otherwise)", still in the = first
paragraph. =A0If it is an internal MTA it shouldn't delete fields added=
by the border MTA of examp= le.com. =A0The rest of the section becomes
more stringent, which seems to be correct.

<= div>Yeah, I don't know what that means either.=A0 If I can't come u= p with a good reason to keep it, I'll remove it in the next version.
Here's the alternative text I = promised above:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 Consistently with the
=A0scope limit outlined in Section 1.2, the grammar does not constrain
=A0the authentication identifier to be a domain name. =A0Improper use
=A0could thus consider appending a delimiter such as "#" and foll= owing
=A0it with useful transport tracing data such as t= he [SMTP] queue ID or
=A0a timestamp.

Isn't that ma= terially the same as what's already in Section 2.3?

-= MSK
--089e013d1da8069a2104d8e7919e-- From psaintan@cisco.com Tue Mar 26 19:02:19 2013 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 A288621F87E5; Tue, 26 Mar 2013 19:02:19 -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=[AWL=-0.000, 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 pOHAI-oh0fqf; Tue, 26 Mar 2013 19:02:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1E79921F8555; Tue, 26 Mar 2013 19:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4131; q=dns/txt; s=iport; t=1364349739; x=1365559339; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=MTv03vIwXsUlPQMChMNB/vN3I0SXyG27DQxHq9tl6Mo=; b=eNs6kCe7YrFZbqPqGOcApSfwAan01Zhm5locHfA0U8/fIwr5Gv1EoqFC I78QZ0Li7z8PgTe/AjCI4W47COWIG0ZYFPBwBdCfIPbMxCeiGZIPS4PkJ MFPvN/q4TennKKryODGNT7Fx23g5pAtL7zQ6BEK6tkAbgXpZsBK9ICKLC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0IAHtSUlGrRDoH/2dsb2JhbABDgzoBuC2IO4EJFoEqgh8BAQEDAXkFCwsEEBkZVwaIIQUNr0+PZY8BEQcKglVhA4h4jW+BH4RgiwiDKh0 X-IronPort-AV: E=Sophos;i="4.84,915,1355097600"; d="scan'208,217";a="73717200" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 27 Mar 2013 02:02:18 +0000 Received: from [192.168.1.3] (sjc-vpn7-1020.cisco.com [10.21.147.252]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2R22Hvj024707; Wed, 27 Mar 2013 02:02:17 GMT Message-Id: <583081CD-147D-4DFD-8C9A-E02F06F2E0EB@cisco.com> From: Peter Saint-Andre To: Dave Cridland In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2--504519363 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Mar 2013 20:02:17 -0600 References: X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 27 Mar 2013 08:05:14 -0700 Cc: draft-ietf-appsawg-acct-uri.all@tools.ietf.org, iesg@ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir Review of draft-ietf-appsawg-acct-uri-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, 27 Mar 2013 02:02:19 -0000 --Apple-Mail-2--504519363 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 11, 2013, at 9:38 AM, Dave Cridland 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-ietf-appsawg-webfinger-11 > Title: The 'acct' URI Scheme > Reviewer: Dave Cridland > Review Date: 2013/03/11 > > Summary: Ready for publication as Standards Track. Although I note > one possible additional security consideration it is minor. > > Editorial Comments: > > 1) I do love the use of "discussants", but I hesitantly wonder if > the more common (if less specific) "participants" would be a more > readily understood choice of word? I'll change it "the participants in that discussion". > Minor Comments: > > 1) I note that an acct scheme URI provides proof of existence of the > account; this implies that harvesting published acct URIs would be > useful for spammers and similar attackers, if they can also use this > to leverage more information about the account (such as via > WebFinger). Good point. I'll add text to the Security Considerations on this point (expect a revised I-D at some point in the near future). Peter --Apple-Mail-2--504519363 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 11, 2013, at = 9:38 AM, Dave Cridland 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/ApplicationsAreaDir= ectorate ).

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-appsawg-webfinger-11
=
Title: The 'acct' URI = Scheme
Reviewer: Dave Cridland
Review Date: = 2013/03/11

Summary: Ready for publication as = Standards Track. Although I note one possible additional security = consideration it is minor.

Editorial Comments:

1) I do love the use of "discussants", but I hesitantly = wonder if the more common (if less specific) "participants" would be a = more readily understood choice of = word?

I'll change it "the = participants in that discussion".

Minor = Comments:

1) I note that = an acct scheme URI provides proof of existence of the account; this = implies that harvesting published acct URIs would be useful for spammers = and similar attackers, if they can also use this to leverage more = information about the account (such as via WebFinger).
=

Good point. I'll add text to the = Security Considerations on this point (expect a revised I-D at some = point in the near = future).

Peter


= --Apple-Mail-2--504519363-- From vesely@tana.it Wed Mar 27 11:41:07 2013 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 0BB0721F88BD for ; Wed, 27 Mar 2013 11:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 rNexQlae-Fd8 for ; Wed, 27 Mar 2013 11:41:06 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A59C621F85BD for ; Wed, 27 Mar 2013 11:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364409661; bh=CkSFxQRdapm7ATsHJNNLqJlRFLoaFtdFXy88kATWXu4=; l=5855; h=Date:From:To:References:In-Reply-To; b=sMEezbGFO8oCQNoh2jfl7IXYP4m8xUetwdqpfdkCMtY/FK852Nv48DF4fUJKromPE gpQRFnfSYZR9zL/9DRRxQDdzC+Xy8/x421155N0nmxLT25JhYBEvags1wZs8kJuGRA PhD4x1FWIAeZD+PSTkXAwQTrFswwO4Fp8dACFOjk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 27 Mar 2013 19:41:01 +0100 id 00000000005DC02B.0000000051533D3D.00007E59 Message-ID: <51533D3D.20702@tana.it> Date: Wed, 27 Mar 2013 19:41:01 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 27 Mar 2013 18:41:07 -0000 On Wed 27/Mar/2013 13:56:28 +0100 Murray S. Kucherawy wrote: > On Wed, Mar 27, 2013 at 1:15 PM, Alessandro Vesely wrote: > >>> So why doesn't making authserv-id a "value" accommodate that case? >> >> It would overkill, considering that we'd tend to discourage >> complicated stuff. A "dot-atom" can have a slash, but perhaps we can >> live with that. Otherwise, a "token" can be fit. > > A quoted string is complicated? They've been used in email header fields > for quite a long time now. Yes, sorry for picking the wrong adjective. The "complication" is just the annoyance to modify the parser. It is not that much of a burden, but asking developers to do so only for accommodating a hack that we'd discourage anyway is what I'd call overkill. And, yes, at this point it is bikeshedding... Another reason to review implementations is the version requirement of Section 2.4. Don't you need to say explicitly that the field version being specified is "1"? >>>> It is quite complicated to let trusted domain's A-R pass through. >>> >>> Why is it quite complicated? Trusted authserv-ids is merely a set of >>> strings. If you're looking at an A-R header field whose authserv-id is in >>> that list, you've decided explicitly that its content can be trusted. >>> Anything else should either be ignored or removed (depending on which agent >>> is looking at it). >> >> IMHO, the first paragraph of Section 5 is too mild. It could be >> hardened like so: >> >> OLD >> For security reasons, any MTA conforming to this specification MUST >> delete any discovered instance of this header field that claims, by >> virtue of its authentication service identifier, to have been added >> within its trust boundary and that did not come directly from another >> trusted MTA. >> >> NEW >> For security reasons, any MTA conforming to this specification MUST >> remove or rename any instance of this header field that was not added >> within its trust boundary. The authentication service identifier >> (authserv-id) is used to identify the agent which added the header >> field, with the limits described in Section 7.1. >> >> If an MTA kills only the A-Rs that it can clearly identify as >> forgeries, it would let thru any A-R field bearing some unknown >> identifier. Those identifiers may be forged. If they match a trusted >> id at the next ADMD (MTA or MUA), then if the latter trusts the >> former, it has no obvious reason to suspect. It gets complicated if >> one tries to derive trustworthiness from routing considerations. > > If consumers are already looking only for A-Rs that use an expected > authserv-id, and ignoring others, what's the harm in letting the other ones > through? It disables transitive extensions of trust. The assumption that the producer has the same list of trusted identities as the consumer imposes restrictions on the trust boundary. Substantially, it requires the trust boundary to be a single ADMD, or a set of ADMDs where the transitive closure of the trust relationship can be actually computed. For example, if you have Gmail and Yahoo accounts, you cannot configure your MUA to simply trust the corresponding identities unless both ADMDs vet A-R fields. Otherwise, someone can send a message containing a forged trust-me.yahoo.com to your Gmail account, which would get through. In a non-transitive trust scenario, your MUA can trust Yahoo IDs only when they come from Yahoo directly. For transitive trust, if Gmail trusts Yahoo and you instruct Yahoo to forward your mail to Gmail, you may expect to find pristine Yahoo A-Rs in there, and have your MUA trust them when they come from any compliant ADMD. In this case, I think "complicated" is the right adjective. Do you have an idea of what percentage of opendkim users configure those regexps complicatedly? > The document already goes as far as saying one can also remove all of them > if it chooses, just to be safe. Renaming them is probably also fine, but > I'm skeptical about adding that here since you're renaming within a > registered namespace. Hm... I don't know if registering the renamed header would make sense. >> Renaming rather than removing solves some issues with debugging and >> signature verification, so I'd consider it anyway. > > True, but the agent removing suspect header fields could also log or > otherwise record them as it does so. That needs to be done cleverly to avoid losing the field's position, and is unpractical for signature verification. Another possibility is to comment out the field content. Like logging, that allows additional explanations with it. If the header was signed with the relaxed algorithm there's no need to worry about added whitespace. Perhaps the spec can mention the three possibilities, delete, rename, and comment-out, and then pretend that the term "remove" means any of such dismissals, when used for the A-R header field in the rest of the document. However, five times the I-D uses the term "delete" instead. >> Here's the alternative text I promised above: >> >> Consistently with the >> scope limit outlined in Section 1.2, the grammar does not constrain >> the authentication identifier to be a domain name. Improper use >> could thus consider appending a delimiter such as "#" and following >> it with useful transport tracing data such as the [SMTP] queue ID or >> a timestamp. > > Isn't that materially the same as what's already in Section 2.3? Materially, yes, but it took me multiple messages to finally grasp the intended meaning. Again, maybe it's me, but the discussion starting at the next paragraph doesn't seem to characterize the stuffing of a queue id as improper use, and the somewhat relaxed grammar can complete the misunderstanding. From sm@resistor.net Wed Mar 27 12:23:28 2013 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 B933421F91B6 for ; Wed, 27 Mar 2013 12:23:28 -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.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 OAPFhAQpp-Mv for ; Wed, 27 Mar 2013 12:23: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 BD2C221F9184 for ; Wed, 27 Mar 2013 12:23:27 -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 r2RJNMc2025868; Wed, 27 Mar 2013 12:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364412206; bh=2sVffxJntI2CTQj70RSnt47C51JngeS9/X7MIUZ5y8Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fA2uZJknsT9Oz+o3G2qPA5bfco34mY4vc5rZGmNYM2NPnGr9Te49cNUQacadiC2Kb Eum/GHXIHSXZtQwgGh3YdPfN5POSdzA+L4fmezB9j7fRBVycE21A46ufsZwn7pEtBX DSDxIjaDwa0fpLREqtKfv7pZTUAmKoWCWcTpyROs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364412206; i=@resistor.net; bh=2sVffxJntI2CTQj70RSnt47C51JngeS9/X7MIUZ5y8Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fe41G+XAlvoqn3pb2GuiO2zxgnk3psNVgOGcX9ih9t5S7AZZkk9MBcnE8wzNNFuBb ZhsukH9EkIuTrilEXCcSV9DeZeKZKsBaGwaTjj1hn928d2YN5q7A/IKamzSo8iNOlW y0twXM4VjA09pA9LhlwYzIQZm2fzXLt1uXW5+gFo= Message-Id: <6.2.5.6.2.20130327120614.0a8a2000@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Mar 2013 12:20:03 -0700 To: Alessandro Vesely From: SM In-Reply-To: <5152E2DB.4030807@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 27 Mar 2013 19:23:28 -0000 Hi Alessandro, At 05:15 27-03-2013, Alessandro Vesely wrote: >Renaming rather than removing solves some issues with debugging and >signature verification, so I'd consider it anyway. I have a vague recollection of this. The remove operation (milter) was easier. The issue was about security where some unknown party spoofs my "id". The rename (ignoring the "X-" stuff) might create more problems as I'll have to decide what to do when such a header is spoofed. The case of the large provider doing a rename operation is their internal decision. I'll have to apply heuristics to use that header. Regards, -sm From johnl@iecc.com Wed Mar 27 12:47:23 2013 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 5A8A121F9007 for ; Wed, 27 Mar 2013 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 nChheXVnZxc0 for ; Wed, 27 Mar 2013 12:47:22 -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 E9D4D21F9005 for ; Wed, 27 Mar 2013 12:47:21 -0700 (PDT) Received: (qmail 8519 invoked from network); 27 Mar 2013 19:47:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Mar 2013 19:47:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51534cc8.xn--30v786c.k1303; i=johnl@user.iecc.com; bh=Uq3tEfWnjoPwyoWX/l8Xy1VDUzz9PNadkZxoEVq7GrM=; b=FM28EyduNyGrbBqFK3kc0hYPRJnX2pFpzwwo7yMSn5de4pVIr7+9fO0dyL5Fadq8BuGkje5/kjIMsivPHByyoNVcuZ120dYo6v8skY9+VPOOVrTVnP5JsX8i/Vpme59jPpDveSZcypxYBqhtA/FAgGxji8/wrz9ApZe73/itmIo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51534cc8.xn--30v786c.k1303; olt=johnl@user.iecc.com; bh=Uq3tEfWnjoPwyoWX/l8Xy1VDUzz9PNadkZxoEVq7GrM=; b=gmcKpYysJdhR9IP1PiYb0/5muUSe6PdTH+5/tOybjbeTa0ZscKGZ3m5xagUmq8yHIf8T4vX3GMWYk0f6YqCPV88qkSvbub35JQsyZRq9vM4KdnmpVWF0uokyNIoIwxW0RQn3W94NV1f4G+I5ryNJS6htmBi6yuW1djFEltMkDFQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Mar 2013 19:46:58 -0000 Message-ID: <20130327194658.42435.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5152E2DB.4030807@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 27 Mar 2013 19:47:23 -0000 >Ok, that is starting to make some sense. Maybe it's me, but reading >RFC 5451 as well as its bis I had the false impression that the spec >not only allows but even encourages such practice. I'll try and >suggest an alternative text at the bottom. As far as I'm aware, nobody else has read it that way. When I read the text, it's clear that it's a stable identifier to let systems recognize their own A-R headers. >NEW > For security reasons, any MTA conforming to this specification MUST > remove or rename Definitely not. R's, John From superuser@gmail.com Wed Mar 27 12:53:54 2013 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 AF42C21F9131 for ; Wed, 27 Mar 2013 12:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.466, 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 LOsnh8iOsQmY for ; Wed, 27 Mar 2013 12:53:34 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 901AA21F9128 for ; Wed, 27 Mar 2013 12:53:33 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so918829wgh.32 for ; Wed, 27 Mar 2013 12:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tdTwvtL9s6HRH8hmFgI+Mw+c6YQywj9SVLnqVimi9Ik=; b=e1dfZIxN/YHab0E+cxpcwncuOYefBP1dtJzjVxImf5QuLX0BCb0FspGz++bFk7d7lG W78i+EsLNnIdSy+HhRYYWIXuaFGmnD4AUV2gCSE1Y44lqZCe2yc3GOJ8zhmzTGGbu/6E 7HWjirVdsqStPDrthRVOOU3QgIg1V4riROL3CF9OEboKftpPkXafqzWqvQopwaxuKB4N q9deJIIJ+wk//Mr1G6n6Q/AF99Q9KKrb6gdG/64TjD2dbBgihUt2KL6CxEtldWBjrE7l 0/pUCy23B/hXWBlMxTuM/ALZEG3Xv0UXqf5+qpdKzHLPkvi8cBuVmsXG+bOlOPOao+PP Z6GA== MIME-Version: 1.0 X-Received: by 10.180.89.243 with SMTP id br19mr6410518wib.5.1364414012587; Wed, 27 Mar 2013 12:53:32 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Wed, 27 Mar 2013 12:53:32 -0700 (PDT) In-Reply-To: <51533D3D.20702@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> <51533D3D.20702@tana.it> Date: Wed, 27 Mar 2013 20:53:32 +0100 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=e89a8f3ba24d8c081c04d8ed640a Cc: IETF Apps Discuss Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 27 Mar 2013 19:53:54 -0000 --e89a8f3ba24d8c081c04d8ed640a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 27, 2013 at 7:41 PM, Alessandro Vesely wrote: > Another reason to review implementations is the version requirement of > Section 2.4. Don't you need to say explicitly that the field version > being specified is "1"? > The version is indeed 1, but it is optional in the ABNF. > It disables transitive extensions of trust. The assumption that the > producer has the same list of trusted identities as the consumer > imposes restrictions on the trust boundary. Substantially, it > requires the trust boundary to be a single ADMD, or a set of ADMDs > where the transitive closure of the trust relationship can be actually > computed. > But this isn't a new requirement. It has always been the case that the consumers need to know how to identify the instances produced by its own ADMD. > > For example, if you have Gmail and Yahoo accounts, you cannot > configure your MUA to simply trust the corresponding identities unless > both ADMDs vet A-R fields. Otherwise, someone can send a message > containing a forged trust-me.yahoo.com to your Gmail account, which > would get through. In a non-transitive trust scenario, your MUA can > trust Yahoo IDs only when they come from Yahoo directly. For > transitive trust, if Gmail trusts Yahoo and you instruct Yahoo to > forward your mail to Gmail, you may expect to find pristine Yahoo A-Rs > in there, and have your MUA trust them when they come from any > compliant ADMD. > I don't think this document (old or new) goes to great lengths to establish transitive trust mechanisms, and shouldn't unless there are implementations that do so. (I know of some that tried and failed, in fact.) We do mention that a starting point for doing so would be to sign A-R fields before they travel onward, and then the ultimate recipient would need to know (a) that the external ones to be trusted were covered by a valid signature, and (b) that they contained an authserv-id that can be trusted. But this is more bikeshedding for, as John put it, something that's unlikely to be implemented anyway. > In this case, I think "complicated" is the right adjective. Do you > have an idea of what percentage of opendkim users configure those > regexps complicatedly? > I don't think there are any regular expression configurations in opendkim with respect to A-R. There's one setting that enables the "/queue-id" hack, if that's what you're talking about. Either way, no, I have no idea how many people are using. I recall only one or two ever discussing it. > > > The document already goes as far as saying one can also remove all of > them > > if it chooses, just to be safe. Renaming them is probably also fine, but > > I'm skeptical about adding that here since you're renaming within a > > registered namespace. > > Hm... I don't know if registering the renamed header would make sense. > Indeed it would not. > > >> Renaming rather than removing solves some issues with debugging and > >> signature verification, so I'd consider it anyway. > > > > True, but the agent removing suspect header fields could also log or > > otherwise record them as it does so. > > That needs to be done cleverly to avoid losing the field's position, > and is unpractical for signature verification. Another possibility is > to comment out the field content. Like logging, that allows > additional explanations with it. If the header was signed with the > relaxed algorithm there's no need to worry about added whitespace. > Any modification, including removing or altering in place, risks clobbering otherwise valid signatures. They aren't different in that regard. > > Perhaps the spec can mention the three possibilities, delete, rename, > and comment-out, and then pretend that the term "remove" means any of > such dismissals, when used for the A-R header field in the rest of the > document. However, five times the I-D uses the term "delete" instead. > Do you know of any extant or proposed implementations of the non-delete options? I don't think it's appropriate to revise a Proposed Standard by peppering it with a giant "maybe". -MSK --e89a8f3ba24d8c081c04d8ed640a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 27, 2013 at 7:41 PM, Alessandro Vesely <vesely@t= ana.it> wrote:
Another reason to review implementations is = the version requirement of
Section 2.4. =A0Don't you need to say explicitly that the field version=
being specified is "1"?

The v= ersion is indeed 1, but it is optional in the ABNF.
=A0
It disables transitive extensions of trust. =A0The assumption that the
producer has the same list of trusted identities as the consumer
imposes restrictions on the trust boundary. =A0Substantially, it
requires the trust boundary to be a single ADMD, or a set of ADMDs
where the transitive closure of the trust relationship can be actually
computed.

But this isn't a new requ= irement.=A0 It has always been the case that the consumers need to know how= to identify the instances produced by its own ADMD.
=A0

For example, if you have Gmail and Yahoo accounts, you cannot
configure your MUA to simply trust the corresponding identities unless
both ADMDs vet A-R fields. =A0Otherwise, someone can send a message
containing a forged trust-me.yahoo.com to your Gmail account, which
would get through. =A0In a non-transitive trust scenario, your MUA can
trust Yahoo IDs only when they come from Yahoo directly. =A0For
transitive trust, if Gmail trusts Yahoo and you instruct Yahoo to
forward your mail to Gmail, you may expect to find pristine Yahoo A-Rs
in there, and have your MUA trust them when they come from any
compliant ADMD.

I don't think this = document (old or new) goes to great lengths to establish transitive trust m= echanisms, and shouldn't unless there are implementations that do so.= =A0 (I know of some that tried and failed, in fact.)=A0 We do mention that = a starting point for doing so would be to sign A-R fields before they trave= l onward, and then the ultimate recipient would need to know (a) that the e= xternal ones to be trusted were covered by a valid signature, and (b) that = they contained an authserv-id that can be trusted.

But this is more bikeshedding for, as John put it, something= that's unlikely to be implemented anyway.


In this case, I think "complicated" is the right adjective. =A0Do= you
have an idea of what percentage of opendkim users configure those
regexps complicatedly?

I don't thin= k there are any regular expression configurations in opendkim with respect = to A-R.=A0 There's one setting that enables the "/queue-id" h= ack, if that's what you're talking about.=A0 Either way, no, I have= no idea how many people are using.=A0 I recall only one or two ever discus= sing it.

=A0

> The document already goes as far as saying one can also remove all of = them
> if it chooses, just to be safe. =A0Renaming them is probably also fine= , but
> I'm skeptical about adding that here since you're renaming wit= hin a
> registered namespace.

Hm... I don't know if registering the renamed header would make s= ense.

Indeed it would not.
=A0

>> Renaming rather than removing solves some issues with debugging an= d
>> signature verification, so I'd consider it anyway.
>
> True, but the agent removing suspect header fields could also log or > otherwise record them as it does so.

That needs to be done cleverly to avoid losing the field's positi= on,
and is unpractical for signature verification. =A0Another possibility is to comment out the field content. =A0Like logging, that allows
additional explanations with it. =A0If the header was signed with the
relaxed algorithm there's no need to worry about added whitespace.
<= /blockquote>

Any modification, including removing or alt= ering in place, risks clobbering otherwise valid signatures.=A0 They aren&#= 39;t different in that regard.
=A0

Perhaps the spec can mention the three possibilities, delete, rename,
and comment-out, and then pretend that the term "remove" means an= y of
such dismissals, when used for the A-R header field in the rest of the
document. =A0However, five times the I-D uses the term "delete" i= nstead.

Do you know of any extant or pr= oposed implementations of the non-delete options?=A0 I don't think it&#= 39;s appropriate to revise a Proposed Standard by peppering it with a giant= "maybe".

-MSK
--e89a8f3ba24d8c081c04d8ed640a-- From tbray@textuality.com Wed Mar 27 21:48:02 2013 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 C7C8C21F92A7 for ; Wed, 27 Mar 2013 21:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.957 X-Spam-Level: * X-Spam-Status: No, score=1.957 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 5h7eZkf1gb-t for ; Wed, 27 Mar 2013 21:48:02 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CCB8521F92AB for ; Wed, 27 Mar 2013 21:47:55 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fo12so16996706lab.28 for ; Wed, 27 Mar 2013 21:47:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:cc:content-type:x-gm-message-state; bh=Hw1TRxX5ba/QkkHcIHtIjaKPCAKKG9jYBe9/ZvxdunM=; b=NfzospgksHeG2rgnS81uOcF7SoUN8SaZhLmW1HiBZKaiQTuRMOk/ZedWD22cVkdY8H GiUmmg4BHHsQbIn6I7LzRVoS9a0MJYdBsc4HuGOQNakROewuRRMupGXYuFxGABDBqHon VW+NHvBP2apXDbRhOFKjKFPSc6bxalmSH21Y9y1NGmeHqLtvlLQ5W5Y7kmTxbFs9oYKt d8qB1kbVfLd4oNP/NIUC4qUnqF5oh6lNhEhG+4EpyRBDVjXQKSjpFiNUT706OGkkmCD1 y2jbDtWspz2zR6EgoF2fEnvgTTpnMIzWZYJGxhSY0qKYqFO9ggPFO/Vn7mnUdnjP4Ztm 65aQ== MIME-Version: 1.0 X-Received: by 10.112.68.34 with SMTP id s2mr11218330lbt.111.1364446074493; Wed, 27 Mar 2013 21:47:54 -0700 (PDT) Received: by 10.114.14.37 with HTTP; Wed, 27 Mar 2013 21:47:54 -0700 (PDT) X-Originating-IP: [24.84.235.32] Date: Wed, 27 Mar 2013 21:47:54 -0700 Message-ID: From: Tim Bray To: draft-ietf-tsvwg-byte-pkt-congest.all@tools.ietf.org, "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba30941e95e50804d8f4dbe6 X-Gm-Message-State: ALoCoQmjcFddxCcZbq5Nn8f7Pdx9BpKeQ2ytE7mAn1lJJIqwmfOqTwhuE/CV/UIGNyxd/3so5/Ve Cc: The IESG Subject: [apps-discuss] Applications Area Directorate review of draft-ietf-tsvwg-byte-pkt-congest-09 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, 28 Mar 2013 04:48:02 -0000 --90e6ba30941e95e50804d8f4dbe6 Content-Type: text/plain; charset=windows-1252 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-tsvwg-byte-pkt-congest-09 Title: Byte and Packet Congestion Notification Reviewer: Tim Bray Review Date: March 8, 2013 I lack expertise in the subject matter, so can only comment on the exposition and clarity. Since I, not a subject-matter expert, think I understood the analysis, and actually enjoyed reading it. I believe this draft is pretty well ready for publication, assuming subject matter experts agree with its analysis and conclusions. Major issues: None Minor issues: None Nits: 1. Introduction I had a little trouble parsing =93... how we should correctly scale congestion control functions with packet size...=94 I guess =93scale A with= B=94 is a little bit nonstandard grammar. Do you mean =93scale A as a function o= f B=94 or =93scale A as B increases=94 or what? s/notifying congestion/notifying of congestion/ s/notifies its level of congestion/notifies of its level of congestion/ s/byte-size/size/ in general, right? How else would one measure size? Might it be smart, in the spirit of tl;dr, to move Section 8 to near the front of the document? For example, the answers =93it depends=94, =93no= =94, and =93yes=94, are too far from the questions. --90e6ba30941e95e50804d8f4dbe6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I have been select= ed as the Applications Area Directorate reviewer for this draft (for backgr= ound 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: dra= ft-ietf-tsvwg-byte-pkt-congest-09
Title: Byte and Packet Congestio= n Notification
Reviewer: Tim Bray
Review Date: March 8, 2013
I lack expertise in the subject matter, so can only comment = on the exposition and clarity.=A0 Since I, not a subject-matter expert, thi= nk I understood the analysis, and actually enjoyed reading it. I believe th= is draft is pretty well ready for publication, assuming subject matter expe= rts agree with its analysis and conclusions.

Major issues: None
Minor issues: None

N= its:

1. Introduction
I had a little trouble parsing =93... how we = should correctly scale congestion control functions with packet size...=94 = I guess =93scale A with B=94 is a little bit nonstandard grammar. Do you me= an =93scale A as a function of B=94 or =93scale A as B increases=94 or what= ?

s/notifying congestion/notifying of congestion/

s/no= tifies its level of congestion/notifies of its level of congestion/

=
s/byte-size/size/ in general, right?=A0 How else would one measure si= ze?

Might it be smart, in the spirit of tl;dr, to move Section 8 to n= ear the front of the document?=A0=A0 For example, the answers =93it depends= =94, =93no=94, and =93yes=94, are too far from the questions.

<= div>


--90e6ba30941e95e50804d8f4dbe6-- From internet-drafts@ietf.org Wed Mar 27 23:07:37 2013 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 5BEB221F9346; Wed, 27 Mar 2013 23:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 cXxHDM+dqemG; Wed, 27 Mar 2013 23:07:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2401721F9304; Wed, 27 Mar 2013 23:07:36 -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.43 Message-ID: <20130328060736.2908.27753.idtracker@ietfa.amsl.com> Date: Wed, 27 Mar 2013 23:07:36 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-12.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, 28 Mar 2013 06:07:37 -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 Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-12.txt Pages : 23 Date : 2013-03-27 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaojk@cnnic.cn Wed Mar 27 23:35:47 2013 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 D0E3321F919D for ; Wed, 27 Mar 2013 23:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.695 X-Spam-Level: X-Spam-Status: No, score=-98.695 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.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 dSCyWVTjq57l for ; Wed, 27 Mar 2013 23:35:47 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 6ED0921F916B for ; Wed, 27 Mar 2013 23:35:45 -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; Thu, 28 Mar 2013 14:35:36 +0800 Message-ID: From: "Jiankang YAO" To: Date: Thu, 28 Mar 2013 14:35:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 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 Cc: iesg@ietf.org Subject: [apps-discuss] AppsDir review of draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 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, 28 Mar 2013 06:35:47 -0000 SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRl IHJldmlld2VyIA0KZm9yIHRoaXMgZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBs ZWFzZSANCnNlZSANCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lr aS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUgDQopLiAgDQpQbGVhc2UgcmVzb2x2ZSB0aGVz ZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBjb21tZW50cyANCnlvdSBtYXkgcmVjZWl2 ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgDQpzaGVwaGVy ZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRG9j dW1lbnQ6IGRyYWZ0LWlldGYtb3NwZi1pcHY0LWVtYmVkZGVkLWlwdjYtcm91dGluZy0wNyANClRp dGxlOiBSb3V0aW5nIGZvciBJUHY0LWVtYmVkZGVkIElQdjYgUGFja2V0cw0KDQpSZXZpZXdlcjog SmlhbmthbmcgWWFvDQpSZXZpZXcgRGF0ZTogTWFyY2ggMjgsIDIwMTMNCg0KU3VtbWFyeToNCg0K VGhpcyBkcmFmdCBpcyBnb29kIHdvcmsgYW5kIGFsbW9zdCByZWFkeSBmb3IgcHVibGljYXRpb24g YXMgaW5mb3JtYXRpb25hbCBSRkMuDQoNCk1ham9yIGlzc3VlOm5vbmUuDQoNCk1pbm9yIGlzc3Vl Og0KDQogIEFic3RyYWN0IHNhaWQ6IiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcm91dGluZyBw YWNrZXRzIGRlc3RpbmVkIHRvIElQdjQtZW1iZWRkZWQNCiAgIElQdjYgYWRkcmVzc2VzIGFjcm9z cyBhbiBJUHY2IGNvcmUgdXNpbmcgT1NQRnYzIHdpdGggYSBzZXBhcmF0ZQ0KICAgcm91dGluZyB0 YWJsZS4iLCB3aGljaCBtZWFucyB0aGF0IHRoaXMgZG9jdW1lbnQgd2lsbCBmb2N1cyBvbiByb3V0 aW5nIHBhY2tldHMuDQoNCiAgU2VjdGlvbiAxICJJbnRyb2R1Y3Rpb24iIHNhaWQ6IiAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSByb3V0aW5nIHNjZW5hcmlvIHdoZXJlIElQdjQgcGFja2V0cyBh cmUNCiAgIHRyYW5zcG9ydGVkIG92ZXIgYW4gSVB2NiBuZXR3b3JrLCBiYXNlZCBvbiBbUkZDNjE0 NV0gYW5kIFtSRkM2MDUyXSwNCiAgIGFsb25nIHdpdGggYSBzZXBhcmF0ZSBPU1BGdjMgcm91dGlu ZyB0YWJsZSBmb3IgSVB2NC1lbWJlZGRlZCBJUHY2DQogICByb3V0ZXMgaW4gdGhlIElQdjYgbmV0 d29yay4gIiwgd2hpY2ggbWVhbnMgdGhhdCB0aGlzIGRvY3VtZW50IHdpbGwgZm9jdXMgb24gcm91 dGluZyBzY2VuYXJpby4NCg0KICBTZWN0aW9uIDEuMSBzYWlkIGFib3V0ICJUaGUgU2NlbmFyaW9u Ii4NCg0KICAgVGhlIHJlYWRlciBtaWdodCBoYXZlIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5nIGFi b3V0IGZvY3VzIG9mIHRoaXMgZG9jdW1lbnQgYmFzZWQgb24gU2VjdGlvbiAxICJJbnRyb2R1Y3Rp b24iIGFuZCAiQWJzdHJhY3QiIC4gVGhlIGVkaXRvciBtYXkgbmVlZCB0byBkbyBzb21lIGltcHJv dmluZyB3cml0aW5nIHRvIG1ha2UgdGhlIG1lYW5pbmcgbW9yZSBwcmVjaXNlLiANCg0KQmVzdCBS ZWdhcmRzDQoNCkppYW5rYW5nIFlhbw== From barryleiba.mailing.lists@gmail.com Thu Mar 28 06:36:48 2013 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 6A9A021F8970 for ; Thu, 28 Mar 2013 06:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.824 X-Spam-Level: X-Spam-Status: No, score=-101.824 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 retvAnJjYWwD for ; Thu, 28 Mar 2013 06:36:47 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3792121F86CD for ; Thu, 28 Mar 2013 06:36:47 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id ia10so7662808vcb.36 for ; Thu, 28 Mar 2013 06:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ARmc5fQ5lFMZBepUp5Eg0nyIV69lGdeDNv8hGH47iwo=; b=dYBhgtLk6RsYQKy2fI5DJlF2ZQlHeA8VehifHtqMWYSEwdhWf1kEgLYUa2jvCwjtYj GigErl5CPY7JHHkb42K6qtvkAET7hAJQEjNaihwOTFOTSBSGNiQJ4/VLhXPZVcrADaeN NxLuI7YeWBizRuqlIMLPRbbpmWX6Lhk+V9mId3CSoAD0Po8pNO57B4KAVCJYxyiMCo1a MGtYNDKvNS3v6bV1OL0ahCB+MgeKoe++asV+Vwz2dEE7HsvJX3M3Gzz6vW7mpJAvtMiT z7RUamsk78MeKF6y2yrpJTK4pw7ow4130ZmjHNCHckUKo+Qh86ud9abUBorqLCRP/5sV kmgw== MIME-Version: 1.0 X-Received: by 10.58.253.33 with SMTP id zx1mr13309132vec.35.1364477806623; Thu, 28 Mar 2013 06:36:46 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 28 Mar 2013 06:36:46 -0700 (PDT) In-Reply-To: <51525A58.2020803@berkeley.edu> References: <20130327023118.32662.16489.idtracker@ietfa.amsl.com> <51525A58.2020803@berkeley.edu> Date: Thu, 28 Mar 2013 09:36:46 -0400 X-Google-Sender-Auth: YcafIxPnabuPwd9knVVLdWfH1oM Message-ID: From: Barry Leiba To: Erik Wilde Content-Type: multipart/alternative; boundary=047d7bf0d230f7c2fa04d8fc3e50 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-sinnema-xacml-media-type-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, 28 Mar 2013 13:36:48 -0000 --047d7bf0d230f7c2fa04d8fc3e50 Content-Type: text/plain; charset=ISO-8859-1 Hi, Erik. As far as I can tell at a brief glance, this is only a media type registration, for something that's documented in an OASIS document. Is that correct? If so, then you needn't even publish this as an RFC at all. You can make the media type registration on behalf of OASIS directly to IANA, using the form on the media types IANA page, requesting a registration in the standards tree for an SDO. In any case, you should post a pointer to this I-D to , so the media types crowd can review it. Barry On Tuesday, March 26, 2013, Erik Wilde wrote: > A new version of I-D, draft-sinnema-xacml-media-**type-02.txt > has been successfully submitted by Erik Wilde and posted to the > IETF repository. > > Filename: draft-sinnema-xacml-media-type > Revision: 02 > Title: eXtensible Access Control Markup Language (XACML) Media > Type > Creation date: 2013-03-26 > Group: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-**drafts/draft-sinnema-xacml-** > media-type-02.txt > Status: http://datatracker.ietf.org/**doc/draft-sinnema-xacml-media-**type > Htmlized: http://tools.ietf.org/html/**draft-sinnema-xacml-media-**type-02 > Diff: http://www.ietf.org/rfcdiff?**url2=draft-sinnema-xacml-** > media-type-02 > > Abstract: > This specification registers an XML-based media type for the > eXtensible Access Control Markup Language (XACML). > > Note to Readers > > This draft should be discussed on the apps-discuss mailing list. > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --047d7bf0d230f7c2fa04d8fc3e50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Erik.

As far as I can tell at a brief glance, this i= s only a media type registration, for something that's documented in an= OASIS document. =A0Is that correct?

If so, then y= ou needn't even publish this as an RFC at all. =A0You can make the medi= a type registration on behalf of OASIS directly to IANA, using the form on = the media types IANA page, requesting a registration in the standards tree = for an SDO.

In any case, you should post a pointer to this I-D to &= lt;media-types@iana.org>, so= the media types crowd can review it.

Barry<= /span>

On Tuesday, March 26, 2013, Erik Wilde wrote:
A new version of I-D, draft-sinnema-xacml-media-type-02.tx= t
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sinnema-xacml-media-type
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 eXtensible Access Control Markup Language (XACML= ) Media Type
Creation date: =A0 2013-03-26
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9
URL: http://www.ietf.org/internet-draft= s/draft-sinnema-xacml-media-type-02.txt
Status: http://datatracker.ietf.org/doc/draft-sinn= ema-xacml-media-type
Htmlized: http://tools.ietf.org/html/draft-sinnema-x= acml-media-type-02
Diff: http://www.ietf.org/rfcdiff?url2=3Ddra= ft-sinnema-xacml-media-type-02

Abstract:
=A0 =A0This specification registers an XML-based media type for the
=A0 =A0eXtensible Access Control Markup Language (XACML).

Note to Readers

=A0 =A0This draft should be discussed on the apps-discuss mailing list.
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--047d7bf0d230f7c2fa04d8fc3e50-- From vesely@tana.it Thu Mar 28 10:08:06 2013 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 E4A3521F8ECC for ; Thu, 28 Mar 2013 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 JNL2szPPPblm for ; Thu, 28 Mar 2013 10:08:05 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 23E3C21F8E63 for ; Thu, 28 Mar 2013 10:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364490482; bh=2sSSvhLq699OOXwSRvQj/kLbJ9bZXzoIFoqEgWSqjYs=; l=4463; h=Date:From:To:References:In-Reply-To; b=UZbt2GEvp2+bKCoRiinNY/QcKHxhrcXGkrJXHZRFGymR/2PeeKmYCp7Oo9BIiBF+z bAbBkPC5R+WssGKYD4+1YhVHuRdcf6vmlnXx86zZL2zeYY5W4wgufCQ06dYvdlFawq R+L4srNlewrJ7klmETbR1c/wghPfnicqmqzPsvVo= Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 28 Mar 2013 18:08:02 +0100 id 00000000005DC039.00000000515478F2.000008F4 Message-ID: <515478F2.9070702@tana.it> Date: Thu, 28 Mar 2013 18:08:02 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> <51533D3D.20702@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 28 Mar 2013 17:08:07 -0000 On Wed 27/Mar/2013 20:53:32 +0100 Murray S. Kucherawy wrote: > On Wed, Mar 27, 2013 at 7:41 PM, Alessandro Vesely wrote: > >> Another reason to review implementations is the version requirement of >> Section 2.4. Don't you need to say explicitly that the field version >> being specified is "1"? > > The version is indeed 1, but it is optional in the ABNF. Fine. But since the spec says: if a parser finds a version after an authserv-id that it does not explicitly know, then, a parser designed after 5451bis has to _guess_ that the one it knows is indeed "1". >> It disables transitive extensions of trust. The assumption that the >> producer has the same list of trusted identities as the consumer >> imposes restrictions on the trust boundary. > > But this isn't a new requirement. It has always been the case that the > consumers need to know how to identify the instances produced by its own > ADMD. My point was that the producer needs to know the list trusted by the consumers, in order to remove spoofed fields. > I don't think this document (old or new) goes to great lengths to establish > transitive trust mechanisms, and shouldn't unless there are implementations > that do so. I agree that it shouldn't: Section 1.2 is clear about being agnostic on the trust boundary. However, if the local definition of "trust boundary" is such that a producer doesn't know the whole trust-list, then the MUST in the first paragraph of Section 5 is not actionable. >> Do you have an idea of what percentage of opendkim users configure >> those regexps complicatedly? > > I don't think there are any regular expression configurations in > opendkim with respect to A-R. Oops, I thought the patterns in "RemoveARFrom" were regular expressions rather than plain strings. > Either way, no, I have no idea how many people are using. I recall > only one or two ever discussing it. Yeah, not worth overworking on that. Sorry I raised that point. >>> The document already goes as far as saying one can also remove >>> all of them if it chooses, just to be safe. Besides simplicity and security, that choice allows extensibility of the trust boundary. >>>> Renaming rather than removing solves some issues with debugging and >>>> signature verification, so I'd consider it anyway. >>> >>> True, but the agent removing suspect header fields could also log or >>> otherwise record them as it does so. >> >> That needs to be done cleverly to avoid losing the field's position, >> and is unpractical for signature verification. Another possibility is >> to comment out the field content. Like logging, that allows >> additional explanations with it. If the header was signed with the >> relaxed algorithm there's no need to worry about added whitespace. > > Any modification, including removing or altering in place, risks clobbering > otherwise valid signatures. They aren't different in that regard. Renaming by prefix insertion allows recovery at very small risk, with very simple code: dkim_header(dkim, start + dkim_unrename, eol - start - dkim_unrename); where dkim_unrename is either 0 or the length of the prefix inserted by the upstream agent. Note that the code above doesn't know whether the field is actually signed or not. >> Perhaps the spec can mention the three possibilities, delete, rename, >> and comment-out, and then pretend that the term "remove" means any of >> such dismissals, when used for the A-R header field in the rest of the >> document. However, five times the I-D uses the term "delete" instead. > > Do you know of any extant or proposed implementations of the non-delete > options? I don't think it's appropriate to revise a Proposed Standard by > peppering it with a giant "maybe". Courier-MTA does rename. That will go in Debian and other distros when released. I discussed the A-R issue with Sam Varshavchik and was initially unhappy with the solution he came up with. Now that I have experienced configuring and coding my filter to work that way, I must say he was right: It's simple, secure, and can be undone at will. I'm not proposing to standardize renaming, since that should consider also conventions on what prefix to use, and maybe even how to sign in the presence of such prefix. But I think the standard should avoid a "MUST delete", as dismissals by any other means sort the same effect. From dret@berkeley.edu Thu Mar 28 18:27:32 2013 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 E81FF21F848B for ; Thu, 28 Mar 2013 18:27:32 -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 U5FH8LSk5PXi for ; Thu, 28 Mar 2013 18:27:32 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4B84A21F8488 for ; Thu, 28 Mar 2013 18:27:32 -0700 (PDT) Received: from mobile-166-137-186-003.mycingular.net ([166.137.186.3] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1ULO6L-0001th-7M; Thu, 28 Mar 2013 18:27:30 -0700 Message-ID: <5154EE00.2060404@berkeley.edu> Date: Thu, 28 Mar 2013 18:27:28 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130327023118.32662.16489.idtracker@ietfa.amsl.com> <51525A58.2020803@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-sinnema-xacml-media-type-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, 29 Mar 2013 01:27:33 -0000 hello barry. On 2013-03-28 6:36 , Barry Leiba wrote: > As far as I can tell at a brief glance, this is only a media type > registration, for something that's documented in an OASIS document. Is > that correct? close (XACML is defined in various OASIS specs), but not 100% (there is no single OASIS document tying the various versions together). we do have things in there that are not specified anywhere else, which is why we chose to go the IETF route where we can publish and discuss drafts. > If so, then you needn't even publish this as an RFC at all. You can > make the media type registration on behalf of OASIS directly to IANA, > using the form on the media types IANA page, requesting a registration > in the standards tree for an SDO. that's good to know. for now, we would like to continue the route we have been preparing, if that is possible. our main goal was to have a way how we can make this work public and discuss it before we simply declare it registered. > In any case, you should post a pointer to this I-D to > >, so the media types > crowd can review it. ok, i just did that. please let me know if anything speaks against keeping this on its current path. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From superuser@gmail.com Thu Mar 28 19:24:13 2013 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 3B00E21F8A66 for ; Thu, 28 Mar 2013 19:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DT57iAd7KzdR for ; Thu, 28 Mar 2013 19:24:12 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 04BFD21F8A18 for ; Thu, 28 Mar 2013 19:24:11 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so109843wib.14 for ; Thu, 28 Mar 2013 19:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sF1EAV2LpvJz96nwHLjDQenV0RlVmPMLoM7hhTWovSE=; b=tivfAel2wIfzg0mEUnpc0kA5eHLbVPZK5qYkfPEzgXPQNJnXG40Ctxhh2qkJqmRX1V dqVRkP4XMa+++v5iSKxae/6mLIpEpRUH33DBcX6jEeC4wUaUFMgxJbvytioKUE7hPQAF aRHPWYK6HuDc6d1Nm60hnmjOwU3zKKWTemkC/9q980nHbx3XmPQrgEgG/KEuMA74Jz+b 3ibbp0V4ttAZggVbbVesTlzSq13PtODC84FSm6aNYa8//ah/SfEfstPwqSIaHzy6fzg1 X3C23dWk80YFfWJ7HkX8fcYJxTlPuRe/e5v5E79mwLisSmFi4CTs7dCuybBGc4PPgsfs z/lg== MIME-Version: 1.0 X-Received: by 10.194.134.66 with SMTP id pi2mr989667wjb.51.1364523850943; Thu, 28 Mar 2013 19:24:10 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Thu, 28 Mar 2013 19:24:10 -0700 (PDT) In-Reply-To: <515478F2.9070702@tana.it> References: <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> <51533D3D.20702@tana.it> <515478F2.9070702@tana.it> Date: Fri, 29 Mar 2013 03:24:10 +0100 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e01228fbe6c52c304d906f74a Cc: IETF Apps Discuss Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 29 Mar 2013 02:24:13 -0000 --089e01228fbe6c52c304d906f74a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 28, 2013 at 6:08 PM, Alessandro Vesely wrote: > >> Another reason to review implementations is the version requirement of > >> Section 2.4. Don't you need to say explicitly that the field version > >> being specified is "1"? > > > > The version is indeed 1, but it is optional in the ABNF. > > Fine. But since the spec says: > > if a parser finds a version after an authserv-id > that it does not explicitly know, > > then, a parser designed after 5451bis has to _guess_ that the one it > knows is indeed "1". > Why? This hasn't changed in the -bis document either. > > >> It disables transitive extensions of trust. The assumption that the > >> producer has the same list of trusted identities as the consumer > >> imposes restrictions on the trust boundary. > > > > But this isn't a new requirement. It has always been the case that the > > consumers need to know how to identify the instances produced by its own > > ADMD. > > My point was that the producer needs to know the list trusted by the > consumers, in order to remove spoofed fields. > This too is unchanged, and hasn't been identified as a burden yet. The producers and consumers need to know their own domain names as well (for the obvious reasons) and that's never been considered a problem. > > > I don't think this document (old or new) goes to great lengths to > establish > > transitive trust mechanisms, and shouldn't unless there are > implementations > > that do so. > > I agree that it shouldn't: Section 1.2 is clear about being agnostic > on the trust boundary. However, if the local definition of "trust > boundary" is such that a producer doesn't know the whole trust-list, > then the MUST in the first paragraph of Section 5 is not actionable. > Why would the producer need to know more than one entry in the list? > > Any modification, including removing or altering in place, risks > clobbering > > otherwise valid signatures. They aren't different in that regard. > > Renaming by prefix insertion allows recovery at very small risk, with > very simple code: > > dkim_header(dkim, start + dkim_unrename, > eol - start - dkim_unrename); > > where dkim_unrename is either 0 or the length of the prefix inserted > by the upstream agent. Note that the code above doesn't know whether > the field is actually signed or not. > You're doing this at the wrong layer. This change would cause the DKIM validation code to see something different. It wouldn't cause the version passed to the end user to be different. You need to send the instruction in the other direction, which makes it more complicated. I'm not proposing to standardize renaming, since that should consider > also conventions on what prefix to use, and maybe even how to sign in > the presence of such prefix. But I think the standard should avoid a > "MUST delete", as dismissals by any other means sort the same effect. > > I could also argue that renaming has the same effect as deleting; something looking for "Authentication-Results" as a header field name will simply no longer find it. I'll see if I can write up some compromise text for the next version. -MSK --089e01228fbe6c52c304d906f74a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 28, 2013 at 6:08 PM, Alessandro Vesely <vesely@t= ana.it> wrote:
>> Another reason to= review implementations is the version requirement of
>> Section 2.4. =A0Don't you need to say explicitly that the fiel= d version
>> being specified is "1"?
>
> The version is indeed 1, but it is optional in the ABNF.

Fine. =A0But since the spec says:

=A0 =A0if a parser finds a version after an authserv-id
=A0 =A0that it does not explicitly know,

then, a parser designed after 5451bis has to _guess_ that the one it
knows is indeed "1".

Why?=A0 = This hasn't changed in the -bis document either.
=A0

>> It disables transitive extensions of trust. =A0The assumption that= the
>> producer has the same list of trusted identities as the consumer >> imposes restrictions on the trust boundary.
>
> But this isn't a new requirement. =A0It ha= s always been the case that the
> consumers need to know how to identify the instances produced by its o= wn
> ADMD.

My point was that the producer needs to know the list trusted by the<= br> consumers, in order to remove spoofed fields.

This too is unchanged, and hasn't been identified as a burden ye= t.=A0 The producers and consumers need to know their own domain names as we= ll (for the obvious reasons) and that's never been considered a problem= .
=A0

> I don't think this document (old or new) goes to great lengths to = establish
> transitive trust mechanisms, and shouldn't unless there are implem= entations
> that do so.

I agree that it shouldn't: =A0Section 1.2 is clear about being ag= nostic
on the trust boundary. =A0However, if the local definition of "trust boundary" is such that a producer doesn't know the whole trust-lis= t,
then the MUST in the first paragraph of Section 5 is not actionable.

Why would the producer need to know more than= one entry in the list?
=A0
> Any modification, including removing or altering in place, risks clobb= ering
> otherwise valid signatures. =A0They aren't different in that regar= d.

Renaming by prefix insertion allows recovery at very small risk, with=
very simple code:

=A0 dkim_header(dkim, start + dkim_unrename,
=A0 =A0 =A0eol - start - dkim_unrename);

where dkim_unrename is either 0 or the length of the prefix inserted
by the upstream agent. =A0Note that the code above doesn't know whether=
the field is actually signed or not.

Yo= u're doing this at the wrong layer.=A0 This change would cause the DKIM= validation code to see something different.=A0 It wouldn't cause the v= ersion passed to the end user to be different.=A0 You need to send the inst= ruction in the other direction, which makes it more complicated.

I'm not proposing to standardi= ze renaming, since that should consider
also conventions on what prefix to use, and maybe even how to sign in
the presence of such prefix. =A0But I think the standard should avoid a
"MUST delete", as dismissals by any other means sort the same eff= ect.

<= br>
I could also argue that renaming has the same effect as delet= ing; something looking for "Authentication-Results" as a header f= ield name will simply no longer find it.=A0 I'll see if I can write up = some compromise text for the next version.

-MSK
--089e01228fbe6c52c304d906f74a-- From vesely@tana.it Fri Mar 29 03:33:37 2013 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 309BA21F938B for ; Fri, 29 Mar 2013 03:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 3SIUKzEhDryk for ; Fri, 29 Mar 2013 03:33:36 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF7821F9366 for ; Fri, 29 Mar 2013 03:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364553214; bh=Itxvep3gFkE7QXuIz66ESxtN5yRfQTRKPhJBlCVzTV0=; l=4242; h=Date:From:To:References:In-Reply-To; b=CuL8cPCmwAw6p0yXSwfATM4AwCFeA1YXHmXKIUFg30rIEyYlrDSnXqrpjH92//f8H /g78wz4ecWHXv1vYMfNsJUKgU/3cA09rXoOWlOaoRSpvD8lpu4h/axTKu+6GxXoSrd u6/QABjllKc9QgqActVIAzly13YgpnM9nJVudOjs= Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 29 Mar 2013 11:33:34 +0100 id 00000000005DC04B.0000000051556DFE.000070EF Message-ID: <51556DFF.6000202@tana.it> Date: Fri, 29 Mar 2013 11:33:35 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> <51533D3D.20702@tana.it> <515478F2.9070702@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 29 Mar 2013 10:33:37 -0000 On Fri 29/Mar/2013 03:24:10 +0100 Murray S. Kucherawy wrote: > On Thu, Mar 28, 2013 at 6:08 PM, Alessandro Vesely wrote: > >> >> Another reason to review implementations is the version requirement of >> >> Section 2.4. Don't you need to say explicitly that the field version >> >> being specified is "1"? >> > >> > The version is indeed 1, but it is optional in the ABNF. >> >> Fine. But since the spec says: >> >> if a parser finds a version after an authserv-id >> that it does not explicitly know, >> >> then, a parser designed after 5451bis has to _guess_ that the one it >> knows is indeed "1". > > Why? This hasn't changed in the -bis document either. In RFC 5451 it was indicated as a comment to the "version" production rule, as in the current draft. That might be slightly inappropriate since that rule works also for the methods, which have their own versions. Since -bis has a section on version tokens, readers may expect to find that statement there. BTW, would sender-id have had "2.0" there? >> My point was that the producer needs to know the list trusted by the >> consumers, in order to remove spoofed fields. > > This too is unchanged, and hasn't been identified as a burden yet. The > producers and consumers need to know their own domain names as well (for > the obvious reasons) and that's never been considered a problem. Yeah, producers don't mind extra-ADMD consumers who may want to trust them. >>> I don't think this document (old or new) goes to great lengths >>> to establish transitive trust mechanisms, and shouldn't unless >>> there are implementations that do so. >> >> I agree that it shouldn't: Section 1.2 is clear about being agnostic >> on the trust boundary. However, if the local definition of "trust >> boundary" is such that a producer doesn't know the whole trust-list, >> then the MUST in the first paragraph of Section 5 is not actionable. > > Why would the producer need to know more than one entry in the list? That's usual. Doesn't opendkim take a list of identities and compare each A-R against it? If it doesn't have the whole list --and admins may worry about allowing write access to their remardb to any possible downstream consumer-- then there's nothing it can do about it. As John said, the point of the authserv-id is to allow a system to recognize its own A-R headers. The "its own" part is what limits free extensibility of the trust boundary. >> Renaming by prefix insertion allows recovery at very small risk, with >> very simple code: >> >> dkim_header(dkim, start + dkim_unrename, >> eol - start - dkim_unrename); >> >> where dkim_unrename is either 0 or the length of the prefix inserted >> by the upstream agent. Note that the code above doesn't know whether >> the field is actually signed or not. > > You're doing this at the wrong layer. This change would cause the DKIM > validation code to see something different. Different from what the rest of the system sees, but hopefully not different from what the signer signed. > It wouldn't cause the version passed to the end user to be different. Yup. > You need to send the instruction in the other direction, which makes > it more complicated. What do you mean? I cannot tell the sender that I don't trust it, so it should stop cluttering messages with its A-Rs. An A-R for the auth method, for example, can only be written there. OTOH, it is possible to recognize that a sender/signer is trusted and unrename its A-Rs after verification too, when changes are committed to disk. I'm not going to code such complication, for the time being. >> I'm not proposing to standardize renaming, since that should consider >> also conventions on what prefix to use, and maybe even how to sign in >> the presence of such prefix. But I think the standard should avoid a >> "MUST delete", as dismissals by any other means sort the same effect. > > I could also argue that renaming has the same effect as deleting; something > looking for "Authentication-Results" as a header field name will simply no > longer find it. I'll see if I can write up some compromise text for the > next version. Thank you :-) From superuser@gmail.com Fri Mar 29 12:25:49 2013 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 96EC821F8E94 for ; Fri, 29 Mar 2013 12:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, 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 9MuYG4kxtOPY for ; Fri, 29 Mar 2013 12:25:48 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5AF21F8E87 for ; Fri, 29 Mar 2013 12:25:48 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id o45so538180wer.36 for ; Fri, 29 Mar 2013 12:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Mj/RpdjS0gTNEY2cJVuofM/hqR/fVDK3yxdH4sIrqiA=; b=zf31Z2RS+E8ASrhEvO89KdmWmijSgY7ROUnMnEMNK8xk4l/CTomUh5aZ5FCx7cn53f TUe1iBoZ9p+s44EV7OU23VndW1iFu69ik1BBTCYGCkHGbA1AMbDIvng4MJyFY0teZdE8 EnmEMyq4xvOvfS6/uDEtv1oMgWvMIR2nc2j6VRs2NmrOGg6N/fpylWkEBuHHqpmyWu3H 2wDcWbQI6r0LpUURgK1vPn0Imcv61o46nSyoIb3oe6QeRQcMhsB0L7x7iVAMyIXG0ka2 tS7lEByRlaq+fpNrwZkZ4fztBfkkD+si4/68hi38VHLirtfsQQ9RXE0PhFm2PPnk4/4W sQTg== MIME-Version: 1.0 X-Received: by 10.194.134.66 with SMTP id pi2mr5162414wjb.51.1364585147517; Fri, 29 Mar 2013 12:25:47 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 29 Mar 2013 12:25:47 -0700 (PDT) In-Reply-To: <51556DFF.6000202@tana.it> References: <51458A59.8040206@tana.it> <514DFAC8.7040406@tana.it> <514EEBB7.40205@tana.it> <515040D2.1080409@tana.it> <51519767.4060808@tana.it> <5151F698.60309@tana.it> <5152E2DB.4030807@tana.it> <51533D3D.20702@tana.it> <515478F2.9070702@tana.it> <51556DFF.6000202@tana.it> Date: Fri, 29 Mar 2013 20:25:47 +0100 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e01228fbefbcfeb04d9153cfa Cc: IETF Apps Discuss Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis 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, 29 Mar 2013 19:25:49 -0000 --089e01228fbefbcfeb04d9153cfa Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 29, 2013 at 11:33 AM, Alessandro Vesely wrote: > >> then, a parser designed after 5451bis has to _guess_ that the one it > >> knows is indeed "1". > > > > Why? This hasn't changed in the -bis document either. > > In RFC 5451 it was indicated as a comment to the "version" production > rule, as in the current draft. That might be slightly inappropriate > since that rule works also for the methods, which have their own > versions. Since -bis has a section on version tokens, readers may > expect to find that statement there. > The version production is 1*DIGIT. That's not a comment. > > BTW, would sender-id have had "2.0" there? > No. > > >>> I don't think this document (old or new) goes to great lengths > >>> to establish transitive trust mechanisms, and shouldn't unless > >>> there are implementations that do so. > >> > >> I agree that it shouldn't: Section 1.2 is clear about being agnostic > >> on the trust boundary. However, if the local definition of "trust > >> boundary" is such that a producer doesn't know the whole trust-list, > >> then the MUST in the first paragraph of Section 5 is not actionable. > > > > Why would the producer need to know more than one entry in the list? > > That's usual. Doesn't opendkim take a list of identities and compare > each A-R against it? Yes, when operating as a consumer of the field (for the purpose of identifying the ones that need to be deleted), not a producer of it. > If it doesn't have the whole list --and admins > may worry about allowing write access to their remardb to any possible > downstream consumer-- then there's nothing it can do about it. > It doesn't need the whole list when acting as a producer. It needs one string. > > As John said, the point of the authserv-id is to allow a system to > recognize its own A-R headers. The "its own" part is what limits free > extensibility of the trust boundary. > Consumers get to have a set that they consider "their own". Producers can only insert one string there, obviously. > > >> Renaming by prefix insertion allows recovery at very small risk, with > >> very simple code: > >> > >> dkim_header(dkim, start + dkim_unrename, > >> eol - start - dkim_unrename); > >> > >> where dkim_unrename is either 0 or the length of the prefix inserted > >> by the upstream agent. Note that the code above doesn't know whether > >> the field is actually signed or not. > > > > You're doing this at the wrong layer. This change would cause the DKIM > > validation code to see something different. > > Different from what the rest of the system sees, but hopefully not > different from what the signer signed. > Of course it is. What you're feeding to dkim_header(), by changing it, will invalidate the signature, if that field was signed. > > You need to send the instruction in the other direction, which makes > > it more complicated. > > What do you mean? I cannot tell the sender that I don't trust it, so > it should stop cluttering messages with its A-Rs. An A-R for the auth > method, for example, can only be written there. > > OTOH, it is possible to recognize that a sender/signer is trusted and > unrename its A-Rs after verification too, when changes are committed > to disk. I'm not going to code such complication, for the time being. > I'm totally confused by what you're getting at here. dkim_header() tells the DKIM layer what it's signing or verifying. Why you would want to change that is beyond me. What you're trying to do is alter the name of the field so consumers won't see it. dkim_header() is absolutely the wrong way to do that. Rather, you need to tell the MTA to do the rename operation, which might actually be a delete+insert operation. DKIM has absolutely nothing to do with that. -MSK --089e01228fbefbcfeb04d9153cfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 29, 2013 at 11:33 AM, Alessandro Vesely <vesely@= tana.it> wrote:
>> then, a parser de= signed after 5451bis has to _guess_ that the one it
>> knows is indeed "1".
>
> Why? =A0This hasn't changed in the -bis document either.

In RFC 5451 it was indicated as a comment to the "version" = production
rule, as in the current draft. =A0That might be slightly inappropriate
since that rule works also for the methods, which have their own
versions. =A0Since -bis has a section on version tokens, readers may
expect to find that statement there.

Th= e version production is 1*DIGIT.=A0 That's not a comment.
=A0

BTW, would sender-id have had "2.0" there?
<= br>
No.
=A0

>>> I don't think this document (old or new) goes to great len= gths
>>> to establish transitive trust mechanisms, and shouldn't un= less
>>> there are implementations that do so.
>>
>> I agree that it shouldn't: =A0Section 1.2 is clear about being= agnostic
>> on the trust boundary. =A0However, if the local definition of &quo= t;trust
>> boundary" is such that a producer doesn't know the whole = trust-list,
>> then the MUST in the first paragraph of Section 5 is not actionabl= e.
>
> Why would the producer need to know more than one entry in the list?
That's usual. =A0Doesn't opendkim take a list of identities a= nd compare
each A-R against it?

Yes, when operating as= a consumer of the field (for the purpose of identifying the ones that need= to be deleted), not a producer of it.
=A0
=A0If it doesn't have the whole list --and admins
may worry about allowing write access to their remardb to any possible
downstream consumer-- then there's nothing it can do about it.

It doesn't need the whole list when acting = as a producer.=A0 It needs one string.
=A0

As John said, the point of the authserv-id is to allow a system to
recognize its own A-R headers. =A0The "its own" part is what limi= ts free
extensibility of the trust boundary.

Consumers get to have a set that they consider "their own".= =A0 Producers can only insert one string there, obviously.
=A0
=

>> Renaming by prefix insertion allows recove= ry at very small risk, with
>> very simple code:
>>
>> =A0 dkim_header(dkim, start + dkim_unrename,
>> =A0 =A0 =A0eol - start - dkim_unrename);
>>
>> where dkim_unrename is either 0 or the length of the prefix insert= ed
>> by the upstream agent. =A0Note that the code above doesn't kno= w whether
>> the field is actually signed or not.
>
> You're doing this at the wrong layer. =A0This change would cause t= he DKIM
> validation code to see something different.

Different from what the rest of the system sees, but hopefully not different from what the signer signed.

= Of course it is.=A0 What you're feeding to dkim_header(), by changing i= t, will invalidate the signature, if that field was signed.
=A0
> You need to send the instruction in the= other direction, which makes
> it more complicated.

What do you mean? =A0I cannot tell the sender that I don't trust = it, so
it should stop cluttering messages with its A-Rs. =A0An A-R for the auth method, for example, can only be written there.

OTOH, it is possible to recognize that a sender/signer is trusted and
unrename its A-Rs after verification too, when changes are committed
to disk. =A0I'm not going to code such complication, for the time being= .

I'm totally confused by what you&= #39;re getting at here.

dkim_header() tells the DKIM layer what it&#= 39;s signing or verifying.=A0 Why you would want to change that is beyond m= e.=A0 What you're trying to do is alter the name of the field so consum= ers won't see it.=A0 dkim_header() is absolutely the wrong way to do th= at.=A0 Rather, you need to tell the MTA to do the rename operation, which m= ight actually be a delete+insert operation.=A0 DKIM has absolutely nothing = to do with that.

-MSK

--089e01228fbefbcfeb04d9153cfa-- From superuser@gmail.com Fri Mar 29 19:57:24 2013 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 17BEB21F8EB3; Fri, 29 Mar 2013 19:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.350, 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 S2+D-8MROznP; Fri, 29 Mar 2013 19:57:23 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 224E521F8EB2; Fri, 29 Mar 2013 19:57:19 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so813145wgh.33 for ; Fri, 29 Mar 2013 19:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=Kx8+5JzXyTPVmSUqbmLQRhlMOkTQS4CImrw+Io3qQUs=; b=ClLJGbPxAGvqqisGZ+6/sv7PTp9lAYzoNIl5kJw7Yc7WGqXr42pGqiy88TF96vgIpy jB2YnBIi/+bbVmzZ5J7JAOd7CxWC33EL7GR4RyguHGOBS0rsNeTolTC58CzeI+Tso+Ul U8ockdZJZ3Le+UfpoujohXBWw4xsS4rYKq1Gp622GsNnTa5mpob+tFCViWY8WwxSuJTQ 1bmJxsbTUATMSylDpFB6qkASyf5QK+aBUe4h4UnCcTorgYqR+DpPFXTYwnDp1olvv0qS CujQx3fWbIlx3lUwJcdhykZRcGUYk5KQ/s6LDLVrqd1OYTuho33AYeB08EdB+cdFI8/O sj6A== MIME-Version: 1.0 X-Received: by 10.180.77.226 with SMTP id v2mr900453wiw.33.1364612239327; Fri, 29 Mar 2013 19:57:19 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 29 Mar 2013 19:57:19 -0700 (PDT) Date: Sat, 30 Mar 2013 03:57:19 +0100 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss , draft-saintandre-iana-urn.all@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d043c7f1ac809b704d91b8b94 Cc: The IESG Subject: [apps-discuss] AppsDir review of draft-saintandre-iana-urn 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, 30 Mar 2013 02:57:24 -0000 --f46d043c7f1ac809b704d91b8b94 Content-Type: text/plain; charset=ISO-8859-1 I have been selected as the Applications Area Directorate (appsdir) 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-saintandre-iana-urn Title: A Uniform Resource Name (URN) Namespace for IANA Registries Reviewer: Murray S. Kucherawy Review Date: March 29, 2013 IETF Last Call Date: not known IESG Telechat Date: not known Summary: This draft is ready for publication as an Informational RFC. Major Issues: none. Minor Issues: none. Nits: The designated contact in the specification template (Section 2) is "IANA Department". That seems either incorrect or incomplete. --f46d043c7f1ac809b704d91b8b94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have been selected as the Applications Area Directorate = (appsdir) reviewer for this draft.=A0 (For background on appsdir, please se= e http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsArea= Directorate).

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

Document: draft-saint= andre-iana-urn
Title: A Uniform Resource Name (URN) Namespace for IANA Registries
Revie= wer: Murray S. Kucherawy
Review Date: March 29, 2013
IETF Last Call D= ate: not known
IESG Telechat Date: not known

Summary: This draft = is ready for publication as an Informational RFC.

Major Issues: none.

Minor Issues: none.

Nits: The designa= ted contact in the specification template (Section 2) is "IANA Departm= ent".=A0 That seems either incorrect or incomplete.

--f46d043c7f1ac809b704d91b8b94-- From superuser@gmail.com Fri Mar 29 19:57:33 2013 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 EC8AB21F8EC9; Fri, 29 Mar 2013 19:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=0.311, 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 Urp5CycJb9Zd; Fri, 29 Mar 2013 19:57:33 -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 D042B21F8EC3; Fri, 29 Mar 2013 19:57:32 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id z12so836401wgg.35 for ; Fri, 29 Mar 2013 19:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=1SMO6p36VYA/DGoZsdtDMHQgLJrvV0lJcaHvj+1Qcjo=; b=Om+YKJ6wdXAVY7lFEsX/dMyiuNSRoTXXUoLZDBhZrTqZjnwClgafrxJpbi9xlEtpmK U0Dg+YBnRaH22x4AY7w8KDsxhz6UlKAZbMi7vXAq3aOpse0shARYzVvAy5R5mj64PKCl VqtV1/r2Hxl/RALEmWV9szbQiZbYl7n1FESfPiazstjsfbpJxnbmeOeS0RVkIPSTy0pZ mwOYOYX3crHkEC+BWSoQyp9dCJ3/fKKmc4fdZQG83W0PayJRHEiv8qDhv/pgZAuCvkKf bpnkCNZNPbNjan2ZUAw6uxB3V2GUiVHwi+6rrG5mK2/s8IyAAI6G9+7BBTIwL6CZyF68 7l/Q== MIME-Version: 1.0 X-Received: by 10.180.188.3 with SMTP id fw3mr908453wic.33.1364612252033; Fri, 29 Mar 2013 19:57:32 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 29 Mar 2013 19:57:31 -0700 (PDT) Date: Sat, 30 Mar 2013 03:57:31 +0100 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss , draft-saintandre-urn-example.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c37cdc89e9d504d91b8cc8 Cc: The IESG Subject: [apps-discuss] AppsDir review of draft-saintandre-urn-example 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, 30 Mar 2013 02:57:34 -0000 --001a11c37cdc89e9d504d91b8cc8 Content-Type: text/plain; charset=ISO-8859-1 I have been selected as the Applications Area Directorate (appsdir) 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-saintandre-urn-example Title: A Uniform Resource Name (URN) Namespace for Examples Reviewer: Murray S. Kucherawy Review Date: March 29, 2013 IETF Last Call Date: not known IESG Telechat Date: not known Summary: This document is ready for publication as a BCP, modulo the minor point I bring up below. Major Issues: None. Minor Issues: I understand that it's appropriate to do this; we have examples for other namespaces, so it makes sense to have one here too. But I'm having trouble seeing how this will be used. I'm willing to chalk it up to my unfamiliarity with URNs in general. Citing your example in Section 4, doing something XMPP-related using this technique would mean "urn:example:xmpp:foo", but that's an example-space URN, not an XMPP URN. Wouldn't one rather register example namespace within the existing XMPP namespace for doing things like that? I realize that would mean every existing URN namespace would have to go through this exercise, but it seems like it might be a better fit at least for the case mentioned above. Nits: Sections 2.11 and 2.12: Periods, please. In Section 1, you might also make reference to the RFC that reserves some of the IP address space for examples. It might be RFC2606 or some other; apologies for not digging up the reference myself, but I'm sending this from a place with no net access. Section 6: Pick either "in" or "under". Probably the former. --001a11c37cdc89e9d504d91b8cc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have been selected as the Applications Area Directorate = (appsdir) reviewer for this draft.=A0 (For background on appsdir, please se= e http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsArea= Directorate).

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

Document: draft-saint= andre-urn-example
Title: A Uniform Resource Name (URN) Namespace for Examples
Reviewer: Mu= rray S. Kucherawy
Review Date: March 29, 2013
IETF Last Call Date: no= t known
IESG Telechat Date: not known

Summary: This document is r= eady for publication as a BCP, modulo the minor
point I bring up below.

Major Issues: None.

Minor Issues:
=
I understand that it's appropriate to do this; we have examples for= other namespaces, so it makes sense to have one here too.=A0 But I'm h= aving trouble seeing how this will be used.=A0 I'm willing to chalk it = up to my unfamiliarity with URNs in general.=A0 Citing your example in Sect= ion 4, doing something XMPP-related using this technique would mean "u= rn:example:xmpp:foo", but that's an example-space URN, not an XMPP= URN.=A0 Wouldn't one rather register example namespace within the exis= ting XMPP namespace for doing things like that?=A0 I realize that would mea= n every existing URN namespace would have to go through this exercise, but = it seems like it might be a better fit at least for the case mentioned abov= e.

Nits:

Sections 2.11 and 2.12: Periods, please.

In Section= 1, you might also make reference to the RFC that reserves some of the IP a= ddress space for examples.=A0 It might be RFC2606 or some other; apologies = for not digging up the reference myself, but I'm sending this from a pl= ace with no net access.

Section 6: Pick either "in" or "under".=A0 Probably= the former.
--001a11c37cdc89e9d504d91b8cc8-- From stpeter@stpeter.im Fri Mar 29 21:03:43 2013 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 4060421F8D16; Fri, 29 Mar 2013 21:03:43 -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_34=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 GkBjf31etQLM; Fri, 29 Mar 2013 21:03:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F17E21F8D12; Fri, 29 Mar 2013 21:03:42 -0700 (PDT) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 966E240D4A; Fri, 29 Mar 2013 22:13:11 -0600 (MDT) Message-ID: <5156641B.70302@stpeter.im> Date: Fri, 29 Mar 2013 22:03:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , IETF Apps Discuss , draft-saintandre-urn-example.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-saintandre-urn-example 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, 30 Mar 2013 04:03:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/29/13 8:57 PM, Murray S. Kucherawy wrote: > I have been selected as the Applications Area Directorate > (appsdir) 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-saintandre-urn-example Title: A Uniform Resource > Name (URN) Namespace for Examples Reviewer: Murray S. Kucherawy > Review Date: March 29, 2013 IETF Last Call Date: not known IESG > Telechat Date: not known > > Summary: This document is ready for publication as a BCP, modulo > the minor point I bring up below. > > Major Issues: None. > > Minor Issues: > > I understand that it's appropriate to do this; we have examples for > other namespaces, so it makes sense to have one here too. But I'm > having trouble seeing how this will be used. I'm willing to chalk > it up to my unfamiliarity with URNs in general. Citing your > example in Section 4, doing something XMPP-related using this > technique would mean "urn:example:xmpp:foo", but that's an > example-space URN, not an XMPP URN. Wouldn't one rather register > example namespace within the existing XMPP namespace for doing > things like that? I realize that would mean every existing URN > namespace would have to go through this exercise, but it seems like > it might be a better fit at least for the case mentioned above. Ah, I see the source of confusion. We already have urn:xmpp, so what I'm saying is don't generate urn:example:xmpp:foo as a way to avoid dealing with the authority for urn:xmpp regarding issuance of urn:xmpp:foo. You seem to be suggesting that each authority might want to have its own namespace-specific example space so that folks in the relevant community could generate things like urn:xmpp:example:foo. I have no objections to such practices, but they're really out of scope for this specification (it's not within the remit of this document to recommend whether namespace authorities ought to have their own particular example spaces). Does that make sense? Would it be appropriate to add a sentence about that? For example, under Community Considerations: Naturally, authorities for particular namespaces (say, the 'xmpp' NID) might want to define their own sub-spaces for examples (say, urn:xmpp:example:*); however, such policies are outside the scope of this document. > Nits: > In Section 1, you might also make reference to the RFC that > reserves some of the IP address space for examples. It might be > RFC2606 or some other; apologies for not digging up the reference > myself, but I'm sending this from a place with no net access. Sure, that would be RFC 5737. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRVmQbAAoJEOoGpJErxa2pg/gQAI7M1qDwPaN53hvAJP/xjuxx OH9trFQ1RaRBtrFCJL8oCPf2RDpGGE25KbbJakxprD88uP3G3dOBJ5ky4iI3uThm 7Rq7KYza+8NDk28lEJjX/nF1fdvDAK7dwhWQc+Uh+oNE7yQgnm4j0x3fla6mpixS pm3FzoI2avazlasYRPGD0oyLa7ibn/DpSiCq3e6k0BLBg8o/nmekEfFG4e0txpBo 2W92yIC8pSROFHM3RBw71dF2fzy9OzA7sWmnsqFd/ACEmGeWFJOkLu5oywTyqjgj CT/o4ghorvC7vTcmek/+YHbZoe8G1XhfHEDq+Uoo1vDswExIBXG9V3aoCes1RJr5 jm2/yC1CJ6oXLzlbWw1uR1sOu96eRxcf14T8st26q+9aXdN1GBifvJ7j4nBmfmMw v4I9Jy5kLXYoreqvEVYrzep/D9fJslmsSiMxhWLE1wj/vIhTLv5IaCGLjsSW+nht j/GIR8S5eEqW72vRoi++7llgmvUjOQp2emJg3KrRiv9x460RsQvSF7VwtqISZd4V ZFwN0y0TlsTngJsCA8IAwi0ybeNttfhKWRSuAWIPtSraxn6z9+hB3/pwrt0tuMM1 xMHjj0bdo7OHt8IOTmzQz/mf0EGVzBFcx4WIZiQrv/+qZreNFRgtN+Mn/jeYCrIl LMRtsT4S07I7JIoKI3Ch =uhQE -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Mar 29 21:06:14 2013 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 4931221F8D2D; Fri, 29 Mar 2013 21:06:14 -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 aefgSbfR0KKP; Fri, 29 Mar 2013 21:06:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8569221F8D2C; Fri, 29 Mar 2013 21:06:13 -0700 (PDT) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 53F0240D4A; Fri, 29 Mar 2013 22:15:43 -0600 (MDT) Message-ID: <515664B3.2080202@stpeter.im> Date: Fri, 29 Mar 2013 22:06:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-saintandre-iana-urn.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-saintandre-iana-urn 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, 30 Mar 2013 04:06:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/29/13 8:57 PM, Murray S. Kucherawy wrote: > I have been selected as the Applications Area Directorate > (appsdir) 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-saintandre-iana-urn Title: A Uniform Resource Name > (URN) Namespace for IANA Registries Reviewer: Murray S. Kucherawy > Review Date: March 29, 2013 IETF Last Call Date: not known IESG > Telechat Date: not known > > Summary: This draft is ready for publication as an Informational > RFC. > > Major Issues: none. > > Minor Issues: none. > > Nits: The designated contact in the specification template (Section > 2) is "IANA Department". That seems either incorrect or > incomplete. I'll double-check that with the appropriate authorities. Thanks for the review! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRVmSzAAoJEOoGpJErxa2pG3MQAKiwOZXq5aZlQlNvPAwRE2v8 kOo+TV2s+N5hrJVmywSDUfe73munpEiS63tbp2yCwI7YkmU+YazQ53W9eu2hzCUu 5o79XnrLf/hbLlPdcXYlleVRtGJFM1zwyBlgGDHMt4aNUDbjFr+WijajFvPRmkDs dtD0yC0IGep1Ba0FXgJNrn3kvQz7QCsoFbI3ZlUFFJcJngCg+EP4ECD0A6p34gsn hA5ul9yA499tVMX9KyShbcVSoS7hpPnieI8XFZAMbSbhaYV6cCS78Q3cm1mGDgl4 z4EUWY7+KTecYl/e5lRYQBYBCX1GKUjyWHIgAqORB/pP6jS8Uxaa0Gx/AxiJT5M4 2L6P0YxU9cYb++KWTTGDc6ZWSGdpCLniffFR4RjcC0MvakfCKRGMNWxX5X0eVBan j+eM/SGtnWvvcswB2q5Auqe6FNFo1x/ZjwaMHgNflasRmWRgoIDaAfoLgobOc2f1 FnqReS+VjPJ15/wZ5XexA2OxF9XOXz+UcyOwUjjNSpHUD27HdYFQeAQIAzUjj8bL eOTKLA5fLIZX5pHpa2YRVpk26fSgcSGCXB4a9iqQcx5Sy415iTOeTjQP1kD54u+e qwVFXAskC9QIJSMZB9KlT2uNARbevbfendR/ZrZA8M0iHBPPAmEzsWtTu0ztwN8i b8xNRy2HBDpoIyiEQdSi =Tozz -----END PGP SIGNATURE----- From superuser@gmail.com Fri Mar 29 21:34:20 2013 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 0201121F8E77; Fri, 29 Mar 2013 21:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 VCs0JPCKElQ8; Fri, 29 Mar 2013 21:34:19 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6E49521F8E76; Fri, 29 Mar 2013 21:34:18 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so330735wib.15 for ; Fri, 29 Mar 2013 21:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GnWu+ekMWTMLhf5cgeapowDfXDnobHrz9ogPqJEYHfs=; b=JgAACCuVpqNTuLWm1BzKrU27xM/l5x6D9RIpwGnGhjJREvdVOBkNjqpsO3WCls9Tl4 RQG4KAEn4ZeFIebu8iFjuMOFnXdrqqMMrPJdo8My47XrQAoekQpMs9laUPmFO1unC6Yh iKhnfflhVDcJfDO4XS5AZBqpmKY8ZgM7aaTg/f657Gb0NdOHBNhk4DZV+wG7ft3ExVP8 4y6bFE4DAaku3rAIR2JeGLvmwhO9ngI2FwUZmu1OUX0KxUaoLfaEIxHUGMvwtSgLHE6d C+gRS9zfK9z62TOhE6x6LCzBmi+ABZmlkA+31bIMMK8f0SWZtDR3RfF9fNa0u1x1jnl5 UZCg== MIME-Version: 1.0 X-Received: by 10.180.187.129 with SMTP id fs1mr1192472wic.5.1364618057592; Fri, 29 Mar 2013 21:34:17 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Fri, 29 Mar 2013 21:34:17 -0700 (PDT) In-Reply-To: <5156641B.70302@stpeter.im> References: <5156641B.70302@stpeter.im> Date: Fri, 29 Mar 2013 21:34:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a11c2672293b42c04d91ce6ac Cc: The IESG , IETF Apps Discuss , draft-saintandre-urn-example.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-saintandre-urn-example 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, 30 Mar 2013 04:34:20 -0000 --001a11c2672293b42c04d91ce6ac Content-Type: text/plain; charset=ISO-8859-1 Yes, that's my confusion, and your suggestion handles it nicely. Thanks! On Fri, Mar 29, 2013 at 9:03 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/29/13 8:57 PM, Murray S. Kucherawy wrote: > > I have been selected as the Applications Area Directorate > > (appsdir) 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-saintandre-urn-example Title: A Uniform Resource > > Name (URN) Namespace for Examples Reviewer: Murray S. Kucherawy > > Review Date: March 29, 2013 IETF Last Call Date: not known IESG > > Telechat Date: not known > > > > Summary: This document is ready for publication as a BCP, modulo > > the minor point I bring up below. > > > > Major Issues: None. > > > > Minor Issues: > > > > I understand that it's appropriate to do this; we have examples for > > other namespaces, so it makes sense to have one here too. But I'm > > having trouble seeing how this will be used. I'm willing to chalk > > it up to my unfamiliarity with URNs in general. Citing your > > example in Section 4, doing something XMPP-related using this > > technique would mean "urn:example:xmpp:foo", but that's an > > example-space URN, not an XMPP URN. Wouldn't one rather register > > example namespace within the existing XMPP namespace for doing > > things like that? I realize that would mean every existing URN > > namespace would have to go through this exercise, but it seems like > > it might be a better fit at least for the case mentioned above. > > Ah, I see the source of confusion. We already have urn:xmpp, so what > I'm saying is don't generate urn:example:xmpp:foo as a way to avoid > dealing with the authority for urn:xmpp regarding issuance of > urn:xmpp:foo. You seem to be suggesting that each authority might want > to have its own namespace-specific example space so that folks in the > relevant community could generate things like urn:xmpp:example:foo. I > have no objections to such practices, but they're really out of scope > for this specification (it's not within the remit of this document to > recommend whether namespace authorities ought to have their own > particular example spaces). Does that make sense? Would it be > appropriate to add a sentence about that? For example, under Community > Considerations: > > Naturally, authorities for particular namespaces (say, the 'xmpp' > NID) might want > to define their own sub-spaces for examples (say, > urn:xmpp:example:*); however, > such policies are outside the scope of this document. > > > Nits: > > > In Section 1, you might also make reference to the RFC that > > reserves some of the IP address space for examples. It might be > > RFC2606 or some other; apologies for not digging up the reference > > myself, but I'm sending this from a place with no net access. > > Sure, that would be RFC 5737. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRVmQbAAoJEOoGpJErxa2pg/gQAI7M1qDwPaN53hvAJP/xjuxx > OH9trFQ1RaRBtrFCJL8oCPf2RDpGGE25KbbJakxprD88uP3G3dOBJ5ky4iI3uThm > 7Rq7KYza+8NDk28lEJjX/nF1fdvDAK7dwhWQc+Uh+oNE7yQgnm4j0x3fla6mpixS > pm3FzoI2avazlasYRPGD0oyLa7ibn/DpSiCq3e6k0BLBg8o/nmekEfFG4e0txpBo > 2W92yIC8pSROFHM3RBw71dF2fzy9OzA7sWmnsqFd/ACEmGeWFJOkLu5oywTyqjgj > CT/o4ghorvC7vTcmek/+YHbZoe8G1XhfHEDq+Uoo1vDswExIBXG9V3aoCes1RJr5 > jm2/yC1CJ6oXLzlbWw1uR1sOu96eRxcf14T8st26q+9aXdN1GBifvJ7j4nBmfmMw > v4I9Jy5kLXYoreqvEVYrzep/D9fJslmsSiMxhWLE1wj/vIhTLv5IaCGLjsSW+nht > j/GIR8S5eEqW72vRoi++7llgmvUjOQp2emJg3KrRiv9x460RsQvSF7VwtqISZd4V > ZFwN0y0TlsTngJsCA8IAwi0ybeNttfhKWRSuAWIPtSraxn6z9+hB3/pwrt0tuMM1 > xMHjj0bdo7OHt8IOTmzQz/mf0EGVzBFcx4WIZiQrv/+qZreNFRgtN+Mn/jeYCrIl > LMRtsT4S07I7JIoKI3Ch > =uhQE > -----END PGP SIGNATURE----- > --001a11c2672293b42c04d91ce6ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, that's my confusion, and your suggestion handles = it nicely.=A0 Thanks!


On Fri, Mar 29, 2013 at 9:03 PM, Peter Saint-Andre <stp= eter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/29/13 8:57 PM, Murray S. Kucherawy wrote:
> I have been selected as the Applications Area Directorate
> (appsdir) reviewer for this draft. =A0(For background on appsdir,
> please see
> http://trac.tools.ietf.org/area/app/trac/= wiki/ApplicationsAreaDirectorate).
>
> =A0Please resolve these comments along with any other Last Call
> comments you may receive. =A0Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> Document: draft-saintandre-urn-example Title: A Uniform Resource
> Name (URN) Namespace for Examples Reviewer: Murray S. Kucherawy
> Review Date: March 29, 2013 IETF Last Call Date: not known IESG
> Telechat Date: not known
>
> Summary: This document is ready for publication as a BCP, modulo
> the minor point I bring up below.
>
> Major Issues: None.
>
> Minor Issues:
>
> I understand that it's appropriate to do this; we have examples fo= r
> other namespaces, so it makes sense to have one here too. =A0But I'= ;m
> having trouble seeing how this will be used. =A0I'm willing to cha= lk
> it up to my unfamiliarity with URNs in general. =A0Citing your
> example in Section 4, doing something XMPP-related using this
> technique would mean "urn:example:xmpp:foo", but that's = an
> example-space URN, not an XMPP URN. Wouldn't one rather register > example namespace within the existing XMPP namespace for doing
> things like that? =A0I realize that would mean every existing URN
> namespace would have to go through this exercise, but it seems like > it might be a better fit at least for the case mentioned above.

Ah, I see the source of confusion. We already have urn:xmpp, so= what
I'm saying is don't generate urn:example:xmpp:foo as a way to avoid=
dealing with the authority for urn:xmpp regarding issuance of
urn:xmpp:foo. You seem to be suggesting that each authority might want
to have its own namespace-specific example space so that folks in the
relevant community could generate things like urn:xmpp:example:foo. I
have no objections to such practices, but they're really out of scope for this specification (it's not within the remit of this document to recommend whether namespace authorities ought to have their own
particular example spaces). Does that make sense? Would it be
appropriate to add a sentence about that? For example, under Community
Considerations:

=A0 Naturally, authorities for particular namespaces (say, the 'xmpp= 9;
NID) might want
=A0 to define their own sub-spaces for examples (say,
urn:xmpp:example:*); however,
=A0 such policies are outside the scope of this document.

> Nits:

> In Section 1, you might also make reference to the RFC that
> reserves some of the IP address space for examples. =A0It might be
> RFC2606 or some other; apologies for not digging up the reference
> myself, but I'm sending this from a place with no net access.

Sure, that would be RFC 5737.

Peter

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRVmQbAAoJEOoGpJErxa2pg/gQAI7M1qDwPaN53hvAJP/xjuxx
OH9trFQ1RaRBtrFCJL8oCPf2RDpGGE25KbbJakxprD88uP3G3dOBJ5ky4iI3uThm
7Rq7KYza+8NDk28lEJjX/nF1fdvDAK7dwhWQc+Uh+oNE7yQgnm4j0x3fla6mpixS
pm3FzoI2avazlasYRPGD0oyLa7ibn/DpSiCq3e6k0BLBg8o/nmekEfFG4e0txpBo
2W92yIC8pSROFHM3RBw71dF2fzy9OzA7sWmnsqFd/ACEmGeWFJOkLu5oywTyqjgj
CT/o4ghorvC7vTcmek/+YHbZoe8G1XhfHEDq+Uoo1vDswExIBXG9V3aoCes1RJr5
jm2/yC1CJ6oXLzlbWw1uR1sOu96eRxcf14T8st26q+9aXdN1GBifvJ7j4nBmfmMw
v4I9Jy5kLXYoreqvEVYrzep/D9fJslmsSiMxhWLE1wj/vIhTLv5IaCGLjsSW+nht
j/GIR8S5eEqW72vRoi++7llgmvUjOQp2emJg3KrRiv9x460RsQvSF7VwtqISZd4V
ZFwN0y0TlsTngJsCA8IAwi0ybeNttfhKWRSuAWIPtSraxn6z9+hB3/pwrt0tuMM1
xMHjj0bdo7OHt8IOTmzQz/mf0EGVzBFcx4WIZiQrv/+qZreNFRgtN+Mn/jeYCrIl
LMRtsT4S07I7JIoKI3Ch
=3DuhQE
-----END PGP SIGNATURE-----

--001a11c2672293b42c04d91ce6ac-- From cabo@tzi.org Fri Mar 29 22:32:50 2013 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 91F0A21F8EF1; Fri, 29 Mar 2013 22:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 omVRNof6Mt+Z; Fri, 29 Mar 2013 22:32:49 -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 8AFBE21F8D84; Fri, 29 Mar 2013 22:32:49 -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.4/8.14.4) with ESMTP id r2U5WgjT012855; Sat, 30 Mar 2013 06:32:42 +0100 (CET) Received: from [192.168.217.105] (p5489300F.dip.t-dialin.net [84.137.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F3482378B; Sat, 30 Mar 2013 06:32:41 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Carsten Bormann Date: Sat, 30 Mar 2013 06:32:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org> To: IETF Apps Discuss , draft-ietf-roll-terminology.all@tools.ietf.org X-Mailer: Apple Mail (2.1503) Cc: "roll@ietf.org WG" , The IESG Subject: [apps-discuss] AppsDir review of draft-ietf-roll-terminology-12.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, 30 Mar 2013 05:32:50 -0000 I have been selected as the Applications Area Directorate (appsdir) 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-roll-terminology-12.txt Title: Terminology in Low power And Lossy Networks Reviewer: Carsten Bormann Review Date: March 30, 2013 IETF Last Call Date: March 16, 2013 IESG Telechat Date: not known Summary: This document is NOT ready for publication. After reading this draft, only one conclusion is possible: Neither the author not the working group care about this document. The document mixes up a glossary function (is it really intended to define new ROLL terminology for "Flash Memory"? "RAM"? "ROM"? "HVAC"? "ISA"? "HART"?) with much-needed actual definition of specific terminology for the domain of the working group. Where the latter is intended, there is often failure: MP2P: Multipoint-to-Point is used to describe a particular = traffic pattern (e.g. MP2P flows collecting information from many = nodes flowing upstream towards a collecting sink or an LBR). All we learn is that it is "used to describe" a traffic pattern and an example for one. Now what is the definition of the term? Is it the upstreamness that is characteristic of MP2P or is it the many-to-one relation? But maybe it isn't really to *one*? This is the kind of question that this document must answer, and it almost completely fails. For the glossary function, shouldn't be some coverage of the ROLL documents? E.g., RFC 5548 revolves around the term U-LLN. Why isn't that presumably useful term copied into the glossary part of this document? What about the other terms defined in RFCs 5548, 5673, 5826, 5867, 6206, 6550, 6551, 6552, 6719? There is a quite useful start in this document, but it requires a major cleanup and a lot more detail work before it becomes publishable. As a first step, the document needs structure, with a separation between the glossary function and the defining intent. For the latter, some minimum amount of rigorous thinking needs to be applied. Where terms are by definition wishy-washy, that is also fine, but should be explicit. I'd be happy to review a reworked document in more detail. Gr=FC=DFe, Carsten From adrian@olddog.co.uk Sat Mar 30 03:15:20 2013 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 1396521F852A; Sat, 30 Mar 2013 03:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 nrft3OMJc8AK; Sat, 30 Mar 2013 03:15:19 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 17EB621F8506; Sat, 30 Mar 2013 03:15:18 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2UAFHMe017367; Sat, 30 Mar 2013 10:15:17 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2UAFEmR017353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Mar 2013 10:15:15 GMT From: "Adrian Farrel" To: "'Carsten Bormann'" , "'IETF Apps Discuss'" , References: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org> In-Reply-To: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org> Date: Sat, 30 Mar 2013 10:15:16 -0000 Message-ID: <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVSs5ndaiT3p7zpAliA/Q3NJikw5gvwyCA Content-Language: en-gb Cc: roll@ietf.org, 'The IESG' Subject: Re: [apps-discuss] AppsDir review of draft-ietf-roll-terminology-12.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 10:15:20 -0000 Hi all, I think I see three things in Carsten's review. 1. Separation of glossary from new terms I can see why this might be valuable, but I am not sure it is critical = rather than stylistic. That is, there are two types of term used in the ROLL = work: - terms that have a meaning specific to ROLL (terminology) - terms that have a meaning in ROLL that is identical to their common = meaning (glossary) In both cases, the words have a meaning in ROLL that needs to be = documented. 2. Use of "more definitive" language for the explanation of new terms I believe this may be a linguistic issue (or even cultural :-). I, of course, reviewed the document and had no issue with "X is used to describe..." To me, that is equivalent to "In the context of ROLL, X = is...", or the more simple "X is..." It is, perhaps, more chatty language than some = would use, but I think the meaning is clear: when you see "X" in a ROLL = document you know it means the totality of the paragraph. Now, in the case that Carsten quotes for MP2P, I don't think the issue = should be with "used to describe" but with a transposition of "e.g." for "i.e.". = Thus, this is a specific problem with one paragraph, rather than with the = general text. And the author can sort this out. 3. Further trawling of related documents for terms that should be = included Thanks to Carsten for suggesting U-LLN as a term for inclusion. AFAICS, = RFC 5548 is the only document using this term, and presents it as a documentation abbreviation within the RFC rather than a generic term. So I don't think = it needs to be included. As for "What about the other terms defined in RFCs 5548, 5673, 5826, = 5867, 6206, 6550, 6551, 6552, 6719?" I think we can assume that the author checked = those documents and made a decision about which terms should be included and = which excluded. Also that the WG is well aware of the existence of those = documents. So rather than an open-ended "Please do more work" it would be helpful to = identify which terms are believed to be missing and in need of inclusion. Thanks, Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of > Carsten Bormann > Sent: 30 March 2013 05:33 > To: IETF Apps Discuss; draft-ietf-roll-terminology.all@tools.ietf.org > Cc: roll@ietf.org WG; The IESG > Subject: AppsDir review of draft-ietf-roll-terminology-12.txt >=20 > I have been selected as the Applications Area Directorate (appsdir) > reviewer for this draft. (For background on appsdir, please see > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). >=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 >=20 > Document: draft-ietf-roll-terminology-12.txt > Title: Terminology in Low power And Lossy Networks > Reviewer: Carsten Bormann > Review Date: March 30, 2013 > IETF Last Call Date: March 16, 2013 > IESG Telechat Date: not known >=20 >=20 > Summary: This document is NOT ready for publication. >=20 > After reading this draft, only one conclusion is possible: > Neither the author not the working group care about this document. >=20 > The document mixes up a glossary function (is it really intended to > define new ROLL terminology for "Flash Memory"? "RAM"? "ROM"? > "HVAC"? "ISA"? "HART"?) with much-needed actual definition of > specific terminology for the domain of the working group. >=20 > Where the latter is intended, there is often failure: >=20 > MP2P: Multipoint-to-Point is used to describe a particular = traffic > pattern (e.g. MP2P flows collecting information from many = nodes > flowing upstream towards a collecting sink or an LBR). >=20 > All we learn is that it is "used to describe" a traffic pattern and an > example for one. Now what is the definition of the term? Is it the > upstreamness that is characteristic of MP2P or is it the many-to-one > relation? But maybe it isn't really to *one*? This is the kind of > question that this document must answer, and it almost completely > fails. >=20 > For the glossary function, shouldn't be some coverage of the ROLL > documents? E.g., RFC 5548 revolves around the term U-LLN. Why isn't > that presumably useful term copied into the glossary part of this > document? What about the other terms defined in RFCs 5548, 5673, > 5826, 5867, 6206, 6550, 6551, 6552, 6719? >=20 > There is a quite useful start in this document, but it requires a > major cleanup and a lot more detail work before it becomes > publishable. >=20 > As a first step, the document needs structure, with a separation > between the glossary function and the defining intent. For the > latter, some minimum amount of rigorous thinking needs to be applied. > Where terms are by definition wishy-washy, that is also fine, but > should be explicit. >=20 > I'd be happy to review a reworked document in more detail. >=20 > Gr=FC=DFe, Carsten From cabo@tzi.org Sat Mar 30 06:33:33 2013 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 1AA8921F87F5; Sat, 30 Mar 2013 06:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.176 X-Spam-Level: X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 5NLmOctl9GAP; Sat, 30 Mar 2013 06:33:32 -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 DCE1C21F855A; Sat, 30 Mar 2013 06:33:29 -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.4/8.14.4) with ESMTP id r2UDXQSI028334; Sat, 30 Mar 2013 14:33:26 +0100 (CET) Received: from [192.168.217.135] (p548925A4.dip.t-dialin.net [84.137.37.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 74EFC3812; Sat, 30 Mar 2013 14:33:26 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk> Date: Sat, 30 Mar 2013 14:33:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org> <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1503) Cc: roll@ietf.org, draft-ietf-roll-terminology.all@tools.ietf.org, 'IETF Apps Discuss' , 'The IESG' Subject: Re: [apps-discuss] AppsDir review of draft-ietf-roll-terminology-12.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, 30 Mar 2013 13:33:33 -0000 Hi Adrian, thanks for trying to read my somewhat terse statements, and I apologize = for making them as easy to misunderstand as I did. I didn't pay attention to the discussion that led up to this document. I was trying to read it from scratch as a document that somebody from a = different area would use to gain access to the terminology used in the = ROLL work. With my critique, I was less interested in the stylistic issues but in = the definitional intent. I think we can all agree that terms like "flash memory" or "field = device" are useful in the vocabulary of someone trying understand ROLL = documents. There is no need to "define" these terms, as they already work in their = industry-standard usage. So that would be the glossary aspect of the document: gathering = information about these terms that is focused on the ROLL context. = E.g., highlighting the potential constrainedness of field devices makes = this glossary entry more immediately useful than a Wikipedia entry = (which strangely doesn't exist) would be. Re the coverage: I used U-LLN as an example of a potentially missing = term because draft-tripathi-roll-reactive-applicability-00.txt uses it = as if the reader were expected to know it. Fortunately, its first use there is close to a reference to 5548, so the = definition was easy to find. But. more generally speaking, if the intent is to list terms that are = *not* defined in the RFCs, that would also be a useful way of scoping. I was expecting more definitional intent on the terms that have been = invented or appropriated for and by ROLL. =20 But maybe that is a misunderstanding on my part of what this document is = about (the WG charter did not help me in identifying its objective, and = the introduction reads like there is defining intent). So, in summary, if the WG intends this to be a loose collection of a = number of background terms with a glossary-like intent, there is indeed = only a bit more editorial work remaining, starting with clarifying that = objective. Maybe the alphabetic arrangement should have alerted me that = this might really be the objective. But then, coming from an applications area point of view, I'm still = looking forward to a future ROLL terminology document. Is "MP2P" a = traffic pattern while "P2MP" isn't? What is the relationship between = RFC 4461 "P2MP LSP"s and what is called "P2MP" in RFC 6550? What is the = relationship between RFC 1112's "multicast" and what is called = "multicast" in draft-ietf-roll-trickle-mcast-04.txt, which just = completed WGLC? What is the relationship between RFC 1122's "host"s and = RFC 6550's "host"s? What *is* an LLN? Gr=FC=DFe, Carsten From barryleiba.mailing.lists@gmail.com Sat Mar 30 08:20:43 2013 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 4A4A521F874B; Sat, 30 Mar 2013 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=0.371, 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 iJCnBwU-OEAY; Sat, 30 Mar 2013 08:20:42 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id CFC0021F8735; Sat, 30 Mar 2013 08:20:41 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hx10so1252386vcb.33 for ; Sat, 30 Mar 2013 08:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ns5fqiTzuIYhg3EtIGukdZaHn7ctN9KIxF3j7HK2SNg=; b=dXlZT/8RdJJTPmBtLNJEZWzLxOJWzULrWCaDm8N41sbn/Hgz/UE/HqXWNMBChBSc3v bSDpWQKmnZa8zC7b+JkadVgqWFiU6YUgKbQqgX5BGhyloi1o+bL2UYBOguo7Y1VJzTOm PiuRJbGEPo4yYJHMmlaGUuwpg7Ps4fm2pUXSIuZQEKdk/8k4AHcuC8d0fxcg7yBwMFOo MF4TzV35P4eowCQvR/iA3iNUQL2ioyG5gfuCeHwhtOP9GY3Y0IEaXnkza3MWc38eCy21 3T40GcKbrHc8dXMP8APl3OwTbN7JZcjVIRc7A2/ZSoBxa3RqNQap7E+LyDZ3AJ5YUyb+ TgBA== MIME-Version: 1.0 X-Received: by 10.52.24.229 with SMTP id x5mr3970763vdf.84.1364656841287; Sat, 30 Mar 2013 08:20:41 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 30 Mar 2013 08:20:41 -0700 (PDT) In-Reply-To: <5156641B.70302@stpeter.im> References: <5156641B.70302@stpeter.im> Date: Sat, 30 Mar 2013 11:20:41 -0400 X-Google-Sender-Auth: LZj1AMyoOHLGrwIX4i9KuErWveo Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: The IESG , IETF Apps Discuss , draft-saintandre-urn-example.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-saintandre-urn-example 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, 30 Mar 2013 15:20:43 -0000 > Would it be > appropriate to add a sentence about that? For example, under Community > Considerations: > > Naturally, authorities for particular namespaces (say, the 'xmpp' > NID) might want > to define their own sub-spaces for examples (say, > urn:xmpp:example:*); however, > such policies are outside the scope of this document. I'll stick that in as an RFC Editor note now. >> In Section 1, you might also make reference to the RFC that >> reserves some of the IP address space for examples. It might be >> RFC2606 or some other; apologies for not digging up the reference >> myself, but I'm sending this from a place with no net access. > > Sure, that would be RFC 5737. Why? It already says this: Therefore this document registers a formal namespace identifier of "example", similar to "example.com" and other domain names [RFC2606]. What's the reason for *also* mentioning 5737? The point is already made, isn't it? Barry From superuser@gmail.com Sat Mar 30 10:43:29 2013 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 A7B0021F875C; Sat, 30 Mar 2013 10:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=0.280, 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 4MU9GAH+0yFK; Sat, 30 Mar 2013 10:43:29 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id B2B7D21F8749; Sat, 30 Mar 2013 10:43:28 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so1191280wgh.9 for ; Sat, 30 Mar 2013 10:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JdEb+Wj+abgchNg18US16IJQ2zScKb84k1FOifYij6k=; b=zhnjbpoYQKpXVkfhAtl6iCMgzNJF57W+hIZSo267TnfGtERTCLx15U1/Im7FjCHOVm GVXE6cRF6FUVLNil3H2GNYKHcp5pcGrLd3lI69j5105LHfKIsGgHUcMczzYono4H2AF9 vhRrKbejCQibVFUomiUu+qpqDpmh5abivP+1rfWZMbRf8JkNHoOCero2B1a4/Ee7icdd dfSdkeYlxqami2bNcXmTdqFsy9MVS51t0Ly2Xq6TE6mbr9KDUr5/qachvFW1dFHzhCgz vjCvBWZrcLNzBVyEFFF9EMLY5s5F18phncAFcHybjUoYCEFecwoQV/XMC3hh70a4Gh7/ BoJg== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr3433346wib.1.1364665407922; Sat, 30 Mar 2013 10:43:27 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sat, 30 Mar 2013 10:43:27 -0700 (PDT) In-Reply-To: References: <5156641B.70302@stpeter.im> Date: Sat, 30 Mar 2013 10:43:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d04462e66e0695304d927ec0e Cc: IETF Apps Discuss , The IESG , draft-saintandre-urn-example.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-saintandre-urn-example 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, 30 Mar 2013 17:43:29 -0000 --f46d04462e66e0695304d927ec0e Content-Type: text/plain; charset=ISO-8859-1 I thought it could be useful to show an example namespace that isn't strings, or that this is done in more than just the domain namespace. It's not mandatory; I did say "might". On Sat, Mar 30, 2013 at 8:20 AM, Barry Leiba wrote: > > Would it be > > appropriate to add a sentence about that? For example, under Community > > Considerations: > > > > Naturally, authorities for particular namespaces (say, the 'xmpp' > > NID) might want > > to define their own sub-spaces for examples (say, > > urn:xmpp:example:*); however, > > such policies are outside the scope of this document. > > I'll stick that in as an RFC Editor note now. > > >> In Section 1, you might also make reference to the RFC that > >> reserves some of the IP address space for examples. It might be > >> RFC2606 or some other; apologies for not digging up the reference > >> myself, but I'm sending this from a place with no net access. > > > > Sure, that would be RFC 5737. > > Why? It already says this: > > Therefore this document registers > a formal namespace identifier of "example", similar to "example.com" > and other domain names [RFC2606]. > > What's the reason for *also* mentioning 5737? The point is already > made, isn't it? > > Barry > --f46d04462e66e0695304d927ec0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I thought it could be useful to show an example namespace = that isn't strings, or that this is done in more than just the domain n= amespace.=A0 It's not mandatory; I did say "might".
=


On Sat, Mar 30, 2013 at 8:20 AM, Barry L= eiba <barryleiba@computer.org> wrote:
> Would it be
> appropriate to add a sentence about that? For example, under Community=
> Considerations:
>
> =A0 Naturally, authorities for particular namespaces (say, the 'xm= pp'
> NID) might want
> =A0 to define their own sub-spaces for examples (say,
> urn:xmpp:example:*); however,
> =A0 such policies are outside the scope of this document.

I'll stick that in as an RFC Editor note now.

>> In Section 1, you might also make reference to the RFC that
>> reserves some of the IP address space for examples. =A0It might be=
>> RFC2606 or some other; apologies for not digging up the reference<= br> >> myself, but I'm sending this from a place with no net access.<= br> >
> Sure, that would be RFC 5737.

Why? =A0It already says this:

=A0 =A0Therefore this document registers
=A0 =A0a formal namespace identifier of "example", similar to &qu= ot;example.com" =A0 =A0and other domain names [RFC2606].

What's the reason for *also* mentioning 5737? =A0The point is already made, isn't it?

Barry

--f46d04462e66e0695304d927ec0e-- From stpeter@stpeter.im Sat Mar 30 15:19:39 2013 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 BD57021F872E; Sat, 30 Mar 2013 15:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 vM0gJCAtmSrQ; Sat, 30 Mar 2013 15:19:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48F21F86DC; Sat, 30 Mar 2013 15:19:38 -0700 (PDT) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7C9CA40D4A; Sat, 30 Mar 2013 16:29:10 -0600 (MDT) Message-ID: <515764FD.5030200@stpeter.im> Date: Sat, 30 Mar 2013 16:19:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Barry Leiba References: <5156641B.70302@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: The IESG , IETF Apps Discuss , draft-saintandre-urn-example.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-saintandre-urn-example 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, 30 Mar 2013 22:19:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/30/13 9:20 AM, Barry Leiba wrote: >>> In Section 1, you might also make reference to the RFC that >>> reserves some of the IP address space for examples. It might >>> be RFC2606 or some other; apologies for not digging up the >>> reference myself, but I'm sending this from a place with no net >>> access. >> >> Sure, that would be RFC 5737. > > Why? It already says this: > > Therefore this document registers a formal namespace identifier of > "example", similar to "example.com" and other domain names > [RFC2606]. > > What's the reason for *also* mentioning 5737? The point is > already made, isn't it? Personally I think that mentioning IP addresses just muddies the waters. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRV2T8AAoJEOoGpJErxa2p4B8P/RG8+XEOuBwhiPAeQ8h9qBfm 8M33dJufi3bUUFq83KsIGd+VgOYHzmjN+T3E9RzRRTgWL67RgBMbto4XDQwMlBPw e7A8eSWLvFvikR3daWKEJbIy4xXbg34Pb9XKX+VomTcQefvfwXtCxv4EQgpg2Qzb yw81Q2tKIih9K1Xv1RKvkEWYXxmsr6WC22UVP1Mxs9tAA0rvY9fmTEOfxzYvXFAB 8Qqx/GFhDGAS2GAi6shFY1r0bJ5KmkpOLh5TjHH2IZu/E7lvMSD06QMuRk63xq7U GPTzVZpyWzgCLKQ5HqJ5oxevm/IsZJN8YfA2Cou5RUdPOCkqLV2OEMj9rw99GzKG BktkDtfqxqH5AEanxI1XNhqnYyPZ1Q2VIUuVT4p8FZrXLZzTv6nya8Gnakn0840q flB2HBPbWKnm3wYPsqCXwWLbzorwAo0qCCHCAVJ4mby3kgrJ8pDySZa9SNZlEG/4 TiQODkapiYEpHEuIGYqqQYgSl5tP1NOhdFOT4mvsKoCqU8mtnwr02Q/sxd4HvORr Y0kYCaKXEpWilKxdC1beBamYNudWao9kL/8dHOlvYmp/ddDfbk5OeDPA5PaTYFxP aa/rJtdZu+1LVcBmPG0QawNQdmfc1z/LhpugSolFTuInXewCVPIpRkxJiEzzrZ6B M8PV8krD94q2+qc4wBF7 =B6B3 -----END PGP SIGNATURE----- From dret@berkeley.edu Sat Mar 30 19:02:42 2013 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 7DE6D21F892B for ; Sat, 30 Mar 2013 19:02:42 -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 xtMTNyIyVpGA for ; Sat, 30 Mar 2013 19:02:42 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8104A21F8928 for ; Sat, 30 Mar 2013 19:02:41 -0700 (PDT) Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UM7bS-0001Y1-AX; Sat, 30 Mar 2013 19:02:41 -0700 Message-ID: <51579940.3040406@berkeley.edu> Date: Sat, 30 Mar 2013 19:02:40 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" , Atom-Syntax References: <20130331020006.30816.30540.idtracker@ietfa.amsl.com> In-Reply-To: <20130331020006.30816.30540.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130331020006.30816.30540.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-atom-profile-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: Sun, 31 Mar 2013 02:02:42 -0000 A new version of I-D, draft-wilde-atom-profile-00.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-wilde-atom-profile Revision: 00 Title: Profile Support for the Atom Syndication Format Creation date: 2013-03-30 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-wilde-atom-profile-00.txt Status: http://datatracker.ietf.org/doc/draft-wilde-atom-profile Htmlized: http://tools.ietf.org/html/draft-wilde-atom-profile-00 Abstract: The Atom syndication format is a generic XML format for representing collections. Profiles are one way how Atom feeds can indicate that they support specific extensions. To make this support visible on the media type level, this specification re-registers the Atom media type, and adds a "profile" media type parameter. This allows profiles to become visible at the media type level, so that servers as well as clients can indicate support for specific Atom profiles in conversations, for example when communicating via HTTP. From superuser@gmail.com Sat Mar 30 22:46:18 2013 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 B6EB621F87B7 for ; Sat, 30 Mar 2013 22:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MF0AzaaSbO8D for ; Sat, 30 Mar 2013 22:46:18 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 926EB21F86A5 for ; Sat, 30 Mar 2013 22:46:17 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so1109656wey.11 for ; Sat, 30 Mar 2013 22:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=5CdvisGmLTYsNubOLH1kUi/OT+eYnL+M7tRNWIwfGR4=; b=eXLkQ71pH5aoFBAz5Unch+GJNvLWBik7B98DcMe6SUyqYC953V8W7RAgXqp5PSnD11 M0gm1i3LRzTT3RjcVOpxHxAFfNldHm2+NyURnxRD7TE4VDfkv+HqiyE9lMuwfIwTTtGz 82pRty9uupCfauBMUCtjZJ1J1bmYp/xVnv3hdykVSFO3g3XDWa2WZOc32KDY89JUHbzp ePXnjize+YhpnWRo50PmoZ2Dl7UWxkyGDRiGhmPCP6QkMC4HV0ZQjjQYZLq8wNa+224h 8lD+/QLy0LVZhBZ0IXoaL+ezMrd0G91Acls9dq++X6lKNkME2ysW58vRFv4UaG3JjNWu 5tqw== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr10235523wjc.35.1364708776725; Sat, 30 Mar 2013 22:46:16 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sat, 30 Mar 2013 22:46:16 -0700 (PDT) In-Reply-To: <20130331054430.773.78223.idtracker@ietfa.amsl.com> References: <20130331054430.773.78223.idtracker@ietfa.amsl.com> Date: Sat, 30 Mar 2013 22:46:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e013d1da8dbd15104d93205e4 Subject: [apps-discuss] Fwd: New Version Notification for draft-kucherawy-rfc5451bis-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: Sun, 31 Mar 2013 05:46:18 -0000 --089e013d1da8dbd15104d93205e4 Content-Type: text/plain; charset=ISO-8859-1 Mainly for Dave Cridland and Alessandro, whose feedback has been incorporated. -MSK ---------- Forwarded message ---------- From: Date: Sat, Mar 30, 2013 at 10:44 PM Subject: New Version Notification for draft-kucherawy-rfc5451bis-04.txt To: superuser@gmail.com A new version of I-D, draft-kucherawy-rfc5451bis-04.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository. Filename: draft-kucherawy-rfc5451bis Revision: 04 Title: Message Header Field for Indicating Message Authentication Status Creation date: 2013-03-30 Group: Individual Submission Number of pages: 42 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-rfc5451bis-04.txt Status: http://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis Htmlized: http://tools.ietf.org/html/draft-kucherawy-rfc5451bis-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-kucherawy-rfc5451bis-04 Abstract: This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The IETF Secretariat --089e013d1da8dbd15104d93205e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mainly for Dave Cridland and Alessandro, whose feedba= ck has been incorporated.

-MSK

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sat, Mar 30, 2013 at 10:44 PM
Subject: New Version Notification fo= r draft-kucherawy-rfc5451bis-04.txt
To: superuser@gmail.com



A new version of I-D, draft-kucherawy-rfc5451bis-04.txt
has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-kucherawy-rfc5451bis
Revision: =A0 =A0 =A0 =A004
Title: =A0 =A0 =A0 =A0 =A0 Message Header Field for Indicating Message Auth= entication Status
Creation date: =A0 2013-03-30
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 42
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/i= nternet-drafts/draft-kucherawy-rfc5451bis-04.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dr= aft-kucherawy-rfc5451bis
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-kuche= rawy-rfc5451bis-04
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdif= f?url2=3Ddraft-kucherawy-rfc5451bis-04

Abstract:
=A0 =A0This document specifies a header field for use with electronic mail<= br> =A0 =A0messages to indicate the results of message authentication efforts.<= br> =A0 =A0Any receiver-side software, such as mail filters or Mail User Agents=
=A0 =A0(MUAs), can use this header field to relay that information in a
=A0 =A0convenient and meaningful way to users, or make sorting and filterin= g
=A0 =A0decisions.

=A0 =A0This document is a candidate for Internet Standard status. =A0[RFC =A0 =A0Editor: Please delete this notation, as I imagine it will be
=A0 =A0indicated some other way.]




The IETF Secretariat


--089e013d1da8dbd15104d93205e4-- From salvatore.loreto@ericsson.com Sun Mar 31 04:29:26 2013 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 46D0521F86DC; Sun, 31 Mar 2013 04:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 4yd0TM2JsML8; Sun, 31 Mar 2013 04:29:23 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AE28221F862B; Sun, 31 Mar 2013 04:29:22 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-e6-51581e10ee24 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C4.05.19728.01E18515; Sun, 31 Mar 2013 13:29:21 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Sun, 31 Mar 2013 13:29:21 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7B55A2508; Sun, 31 Mar 2013 14:29:20 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C7AF2548D8; Sun, 31 Mar 2013 14:29:17 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 26DC653147; Sun, 31 Mar 2013 14:29:13 +0300 (EEST) Message-ID: <51581E0A.1000602@ericsson.com> Date: Sun, 31 Mar 2013 13:29:14 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: The IESG , draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Content-Type: multipart/alternative; boundary="------------060602000207050608020103" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvra6gXESgQdsGNovVL1ewWRx8/I7F YsaficwOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8bd4xNZCq55V5zYe4y1gfGQZRcj B4eEgInEzoNxXYycQKaYxIV769m6GLk4hAROMUo0/J/KCpIQEtjAKHFxFyNEYjejxIJp25gh nHWMEvNfP2aFcLYzSry5eZkdpIVXQFviZNtZZpAVLAKqEmc3OoCE2QTMJJ4/3MIMYosKJEtc /f+JBaJcUOLkzCdgtohAmMSMO+fANjMLGEu8+PyaEcQWFnCS2LV2PiNEPEziZsM5Noiz1SSu ntvEDHGplkTv2U6mCYxCs5CMnYWkBcK2lbgw5zpUXF5i+9s5zBC2rsSF/1NQxBcwsq1iZM9N zMxJLzfaxAgM/4NbfqvuYLxzTuQQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjJl273tevS74Znru0hwuEeFY3ucbGjKeL9JiehnQoxQbtSBqXVdnoqcE778vK7Mmqa28 sMb79qpzZ1fan3izbK7K2l1qDC/vhy6eH2V90c117UKvdwsCvX/9ODHv9o57l/Ovuq+al9HI v052g6JwtrZhgKrA57pDykXbpSTTTQLYxRmqftSF+yixFGckGmoxFxUnAgAS5763TQIAAA== Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review: draft-ietf-intarea-nat-reveal-analysis-06 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, 31 Mar 2013 11:29:26 -0000 --------------060602000207050608020103 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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-intarea-nat-reveal-analysis-06 Title: Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments Reviewer: Salvatore Loreto Review Date: March-31-2013 IETF Last Call Date: IESG Telechat Date: placed on agenda for telechat - 2013-04-11 Summary: This draft is ready for publication as Informational. It is a useful collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. Few minor issues needs to be addressed in order to clarify and/or make more consistent the information provided by the draft. Major Issues: 0 Minor Issues: 5 Nits: 0 Minor: ----- - Section 2. On HOST_ID the following paragraph talks about TCP but does not say anything about the other transport protocols, especially UDP that is the most common transport protocol used by NATs: If the HOST_ID is conveyed at the IP level, all packets will have to bear the identifier. If it is conveyed at a higher connection- oriented level, the identifier is only needed once in the session establishment phase (for instance TCP three-way-handshake), then, all packets received in this session will be attributed to the HOST_ID designated during the session opening. - Information consistency among the different listed solutions: The Analysis subsections of the different solutions listed in the Section "4. Detailed Solutions Analysis" does not contain the same information, for example someone explicitly state "This proposal can apply to any transport protocol." while others don't say anything about that (of course that is true for the solution at IP field level, if an option is for a specific transport protocol that is an implicit info) To be useful a comparison the section should list a set of comparable information (even if they are summarized in the table in Section 5), and among those - if a solution can be applied to any transport protocol or not is a relevant one - how a solution would be advertised (e.g. out of band using a special DNS record) and why this would be the best way to adv. - Section 4.4. Inject Application Protocol Message Headers about the possibility insert the info in a 'subset' of application protocols (e.g., HTTP) the section describes exclusively the HTTP however it does talk about how the possibility to insert the HOST_ID info in an HTTP header would interwork with the possibility for HTTP to set the "Do Not Track" option. The analysis subsection should discuss this aspect and provide some guidance and/or conclusion about. - Section 4.5. PROXY Protocol the section should be clarified explaining that it is referring to TCP proxies that can or can not be combined/bundled to HTTP proxies. Moreover it is not completely clear that the solution only works if both the ends are aware of the presence of such proxy in between. - Section 5. Solutions Analysis: Synthesis - Table 1 should include a row indicating the advertisement mechanism required if any - The row "Success Ratio" is quite cryptic as it does not explain how the Ratio is calculated, neither this information is present in the different sub-sections analysis listed in Section 4 where I would suggest to add those explanations. best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------060602000207050608020103 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 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-intarea-nat-reveal-analysis-06
Title: Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments
Reviewer: Salvatore Loreto
Review Date: March-31-2013
IETF Last Call Date: 
IESG Telechat Date: placed on agenda for telechat - 2013-04-11

Summary: This draft is ready for publication as Informational.
It is a useful collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN)
or application proxies are involved in the path.
Few minor issues needs to be addressed in order to clarify and/or make more consistent the information provided by
the draft.

Major Issues: 0
Minor Issues: 5
Nits: 0

Minor:
-----
- Section 2. On HOST_ID

the following paragraph talks about TCP but does not say anything about the other transport protocols,
especially UDP that is the most common transport protocol used by NATs:

If the HOST_ID is conveyed at the IP level, all packets will have to bear the identifier.
If it is conveyed at a higher connection- oriented level, the identifier is only needed once in the session establishment phase
(for instance TCP three-way-handshake), then, all packets received in this session will be attributed to the HOST_ID
designated during the session opening.


- Information consistency among the different listed solutions:
The Analysis subsections of the different solutions listed in the Section "4. Detailed Solutions Analysis"
does not contain the same information, for example someone explicitly state
"This proposal can apply to any transport protocol." while others don't say anything about that
(of course that is true for the solution at IP field level, if an option is for a specific transport protocol that is
an implicit info)
To be useful a comparison the section should list a set of comparable information (even if they are summarized in the table
in Section 5), and among those
- if a solution can be applied to any transport protocol or not is a relevant one
- how a solution would be advertised (e.g. out of band using a special DNS record) and why this would be the best way to adv.


- Section 4.4. Inject Application Protocol Message Headers
about the possibility insert the info in a 'subset' of application protocols (e.g., HTTP) the section describes exclusively the HTTP
however it does talk about how the possibility to insert the HOST_ID info in an HTTP header would interwork with the possibility
for HTTP to set the "Do Not Track" option.
The analysis subsection should discuss this aspect and provide some guidance and/or conclusion about.

- Section 4.5. PROXY Protocol
the section should be clarified explaining that it is referring to TCP proxies that can or can not be combined/bundled to HTTP proxies.
Moreover it is not completely clear that the solution only works if both the ends are aware of the presence of such proxy in between.

- Section 5. Solutions Analysis: Synthesis
- Table 1 should include a row indicating the advertisement mechanism required if any

- The row "Success Ratio" is quite cryptic as it does not explain how the Ratio is calculated, neither this information is present in the
different sub-sections analysis listed in Section 4 where I would suggest to add those explanations.


best regards
Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------060602000207050608020103-- From sm@elandsys.com Sun Mar 31 15:52:31 2013 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 6C96921F86AE for ; Sun, 31 Mar 2013 15:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 QfzT89W8-5B8 for ; Sun, 31 Mar 2013 15:52:30 -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 C5D3121F867D for ; Sun, 31 Mar 2013 15:52:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.144.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2VMqG86019777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 31 Mar 2013 15:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364770348; bh=xNkSd9YT73aUb0sZYDltASrPZ51205YX4qM4JsIVHb4=; h=Date:To:From:Subject:In-Reply-To:References; b=G63N5wffP4PRFFwerAKeODVUtKbZrThyquXeGKAaTnl2WZgCteVDiLetku3GparKE CjzrEHnN3DJq3HPwYblPVMtfgPRXpfAP6ntnTnJRyMsegCMNVFy327viUz5OV2fSD3 XrvFlGHvcBT69brpXOkXaU/nsb/Z3JkJF8hHlcP4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1364770348; i=@elandsys.com; bh=xNkSd9YT73aUb0sZYDltASrPZ51205YX4qM4JsIVHb4=; h=Date:To:From:Subject:In-Reply-To:References; b=vLsJYyILmVNXQCwRl/qfPKZ540l88ZPRR9+877KgTL1dNrKmz6cgE/+kY7/ss5Uof 9VF7clgoHanYwe1J3gM7ppldIX+HcpfTXlZxiUoNWOp8IAIF5wYWh3CZTMzBWEC3JI dROyxjenJRuH5EkEirCXa1VD7+TwY7gC5ZO3Gpmo= Message-Id: <6.2.5.6.2.20130331154836.0a822628@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 31 Mar 2013 15:51:33 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] RFC5451bis processing 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, 31 Mar 2013 22:52:31 -0000 Hello, Can RFC 5451bis be processed through appsawg? I'll volunteer to shepherd if it helps. Regards, S. Moonesamy From mike5guo@gmail.com Sun Mar 31 16:06:55 2013 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 DAFFA21F86CA for ; Sun, 31 Mar 2013 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=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 cpwcyUA14OGX for ; Sun, 31 Mar 2013 16:06:55 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6B60921F86C4 for ; Sun, 31 Mar 2013 16:06:55 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j6so1551471oag.22 for ; Sun, 31 Mar 2013 16:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=wKlFmPTlBkz0awWQGWYEZ1B0P/Uvn84Ttkh3vfqI7T4=; b=RMfDRLjxE0WyAsgD26hDKHW56RPC05+QA7Hu1XBzOtPVY4unjSs8Y5VpLjcG1fHHZO bBw1eTZz64J7wbJTQeTt1UY0t16om5e9yjFb7srygO+GOe3/L3J6zh61YveVTAQIzisR 8KQYgCOzKSxK4Ba938pEOwuIHGUZQOVQe1lk7AA0E4je9pKxRmYeMkHV9bF3Lai70E6R HWPg9/mW6JUSO5SeTtpJrS/Oq8oKVyzQNnzY6UAd5c8+oJqmv/3rDcQIt5qYHFbNiWNr UlldRjp0/muOdUjbukrvRSEfT2uwQ/jG9LTDqiT/CDibQ5Yh2QP7iGeBJg3dtn89mhxU 2MiQ== MIME-Version: 1.0 X-Received: by 10.60.29.161 with SMTP id l1mr3374020oeh.111.1364771214792; Sun, 31 Mar 2013 16:06:54 -0700 (PDT) Received: by 10.182.81.164 with HTTP; Sun, 31 Mar 2013 16:06:54 -0700 (PDT) Date: Mon, 1 Apr 2013 07:06:54 +0800 Message-ID: From: Zhun Guo To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb200fa751fc004d9408f94 Subject: Re: [apps-discuss] The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format 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, 31 Mar 2013 23:06:56 -0000 --e89a8fb200fa751fc004d9408f94 Content-Type: text/plain; charset=ISO-8859-1 Dear All: Maybe cloud office applications are seldom,just Google Docs,Microsoft Office 365,IBM Docs,Zoho Docs, ThinkFree, Cisco WebEx,Evernote,fengoffice, Libre-office- on-line . So it is difficult to have enough people to talk about the topic. But I think it is great ,because it will give a new definition for email and office software,using HTML5 and WebSocket. Then how can we get enough cloud office customs to talk about the interconnection?Thanks! Zhun Guo --e89a8fb200fa751fc004d9408f94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All:
=A0 =A0 Maybe cloud office applications are seldom,just Google Docs,Micro= soft Office 365,IBM Docs,Zoho Docs, ThinkFree, Cisco WebEx,Evernote,fengoff= ice, Libre-office- on-line . =A0So it is difficult to have enough people to= talk about the topic.
=A0 =A0 But I th= ink it is great ,because it will give a new definition for email and office= software,using HTML5 and WebSocket.
=A0 =A0Then how can we get enough cloud office customs to talk about the in= terconnection?Thanks!

Zhun Guo
--e89a8fb200fa751fc004d9408f94-- From johnl@iecc.com Sun Mar 31 16:29:19 2013 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 3A4C921F84AD for ; Sun, 31 Mar 2013 16:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.084 X-Spam-Level: X-Spam-Status: No, score=-110.084 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 YVT3Nz4btTFs for ; Sun, 31 Mar 2013 16:29:18 -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 5349721F84A6 for ; Sun, 31 Mar 2013 16:29:18 -0700 (PDT) Received: (qmail 56503 invoked from network); 31 Mar 2013 23:29:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 31 Mar 2013 23:29:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5158c6cd.xn--btvx9d.k1303; i=johnl@user.iecc.com; bh=8WDUPefHjX1FFTe3Tyw39xyO5xhoP8mv1o/3PZj1HV8=; b=XRuRFHxK9vdQPCm/aYl0StfpHr8rVLPYQxzL1Y8tH5+zNy7GAoSeDnpVSXY+kMBq7rpI49pZmDGp+LXH18xe6xrjRAoJwEAyZKT6gc6pbDxNrzu2WxY9T38gXqAWaMBHZdd8XocZkTzmZCuE7AVkTmwjD2v6vHKb09lFZIkcwkc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5158c6cd.xn--btvx9d.k1303; olt=johnl@user.iecc.com; bh=8WDUPefHjX1FFTe3Tyw39xyO5xhoP8mv1o/3PZj1HV8=; b=KVcvoaBas+34o5Islv5gRNVMHpa2hDy4Z3DUfVbAqPK2OJJXaMBwQg97wFVgXUi7cvPfOUKc3GaDRJdB743QTR3YM8qIUfxDC8FwOrMr9kMV8lnJDXvC6jIYDCaeYjW1VZA/FD708gbWu4phoKHS0XCpz72OdAaPR+z2uK/mRnc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 31 Mar 2013 23:28:55 -0000 Message-ID: <20130331232855.87940.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <6.2.5.6.2.20130331154836.0a822628@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm+ietf@elandsys.com Subject: Re: [apps-discuss] RFC5451bis processing 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, 31 Mar 2013 23:29:19 -0000 >Can RFC 5451bis be processed through appsawg? I'll volunteer to >shepherd if it helps. Seems reasonable to me. It's clearly an apps topic, and quite a few people who are familiar with the A-R header it describes seem to be here. From superuser@gmail.com Sun Mar 31 17:26:00 2013 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 43B7F21F85CE for ; Sun, 31 Mar 2013 17:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ljr0lLUeU+66 for ; Sun, 31 Mar 2013 17:25:59 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C906B21F858B for ; Sun, 31 Mar 2013 17:25:57 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so1742674wgh.3 for ; Sun, 31 Mar 2013 17:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vtrx/zChJWWCs4Y1Spv49lkQtMxcgTmwhB+BhGYgl1s=; b=zcoWxMxfZ8MKtfWnxXb3rs6dP57Od3YUMxrBexwAIRV9QjZCIzqTbvhERk1ceruZBs ZWhX7CPkUCF0c8U/liBPtUXjfXYkr4AaKK0O+cp8UrNJxAlk78qvnSKf29n+Op5thgQN SjSXiwUAbHWkJRebe708n37mI5/V4BIPmb8Z4oky7BwVj1U2Kdtm3j6nFU9POCHiZoUN FaOkbmfKE8HXizQQvu2YJgc4iG0dlMpvB1t8NSp2vj0FgPOZRFTxPspU2icCrraCY6aq 5EaZXLeBk8UleAVL5JY1o64oRiSamuEOHJwONKdOWFo4iw3oaeXreZQSaDMMYaADAxFa Afcg== MIME-Version: 1.0 X-Received: by 10.194.134.66 with SMTP id pi2mr13097028wjb.51.1364775956987; Sun, 31 Mar 2013 17:25:56 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sun, 31 Mar 2013 17:25:56 -0700 (PDT) In-Reply-To: <20130331232855.87940.qmail@joyce.lan> References: <6.2.5.6.2.20130331154836.0a822628@elandnews.com> <20130331232855.87940.qmail@joyce.lan> Date: Sun, 31 Mar 2013 17:25:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e01228fbe1d482204d941aa22 Cc: SM , IETF Apps Discuss Subject: Re: [apps-discuss] RFC5451bis processing 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, 01 Apr 2013 00:26:00 -0000 --089e01228fbe1d482204d941aa22 Content-Type: text/plain; charset=ISO-8859-1 I'm happy to process it through APPSAWG, and of course recuse myself from the processing formalities. Are there any objections? -MSK On Sun, Mar 31, 2013 at 4:28 PM, John Levine wrote: > >Can RFC 5451bis be processed through appsawg? I'll volunteer to > >shepherd if it helps. > > Seems reasonable to me. It's clearly an apps topic, and quite a few > people who are familiar with the A-R header it describes seem to be > here. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e01228fbe1d482204d941aa22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm happy to process it through APPSAWG, and= of course recuse myself from the processing formalities.

Are = there any objections?

-MSK


On Sun, Mar 31, 2013 at 4:28 PM, John Le= vine <johnl@taugh.com> wrote:
>Can RFC 5451bis be processed through appsawg? =A0I= 9;ll volunteer to
>shepherd if it helps.

Seems reasonable to me. =A0It's clearly an apps topic, and quite = a few
people who are familiar with the A-R header it describes seem to be
here.

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

--089e01228fbe1d482204d941aa22-- From superuser@gmail.com Sun Mar 31 22:25:45 2013 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 23DCB21F858B for ; Sun, 31 Mar 2013 22:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=1.149, 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 e+LnWsNT5HOW for ; Sun, 31 Mar 2013 22:25:44 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id BDBB421F84D5 for ; Sun, 31 Mar 2013 22:25:41 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id n12so1754322wgh.31 for ; Sun, 31 Mar 2013 22:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=4X7DN9/HsVTi8KvgWcKU/T1aT1zqxneMUS50tGliYFQ=; b=T/RXzRHY6Dc2SxWQD0GfXTLRsc7V/ByEjXPIytrcvyfWNDE5T+3WSfi8CccXCB3C49 pFOh5V+G3Aj3VAy8JD21+ScMlXR60C6oBswssbmaOv4ysEEJm1B6uk1r/zyzIRgW4Azj GBIg+VeeWFYtfqTchQrhvpwcxwocx242weF0TqAzP7SfNDFcY0d4ofG/Hqtfcr0ykkIm uoLSnjplqTLVqbcIvMmc0hVS5aHfselB+u93VfQxq0pHyRW3burd8y9H1ySvTnRCVXZG aq95QVN3trYlw01bYtFk8emO3Xc0hiWo7LzAK1fpLhK9LaGePmlbeOnRESi99/q4+Ue/ Cnow== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr13764487wjc.35.1364793940945; Sun, 31 Mar 2013 22:25:40 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Sun, 31 Mar 2013 22:25:40 -0700 (PDT) Date: Sun, 31 Mar 2013 22:25:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e013d1da80ab05d04d945da52 Subject: [apps-discuss] DMARC working group charter proposal 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, 01 Apr 2013 05:25:45 -0000 --089e013d1da80ab05d04d945da52 Content-Type: text/plain; charset=ISO-8859-1 At the IETF meeting in Atlanta, Tim Draegen presented a proposal for DMARC, which is an email authentication and reporting layer atop SPF and DKIM. The externally-developed proposal is now in widespread deployment by a number of large-scale providers. The group that developed it is seeking to bring it to the IETF for further development and broad review, and development of operational guidance. A first draft of a charter can be found linked from http://wiki.tools.ietf.org/wg/appsawg/trac/wiki. There is a dmarc@ietf.org list available for discussing the technical contents of the work and also this draft charter. Please follow up there with any charter contents so we don't innundate this list with that discussion. To subscribe to that list: https://www.ietf.org/mailman/listinfo/dmarc -MSK --089e013d1da80ab05d04d945da52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
At the IETF meeting in Atlanta, Tim Draegen= presented a proposal for DMARC, which is an email authentication and repor= ting layer atop SPF and DKIM.=A0 The externally-developed proposal is now i= n widespread deployment by a number of large-scale providers.=A0 The group = that developed it is seeking to bring it to the IETF for further developmen= t and broad review, and development of operational guidance.

A first draft of a charter can be found linked from http://wiki.tools.ietf.org/w= g/appsawg/trac/wiki.

There is a dmarc@ietf.org list available for discussing the technical cont= ents of the work and also this draft charter.=A0 Please follow up there wit= h any charter contents so we don't innundate this list with that discus= sion.=A0 To subscribe to that list:

https://www.iet= f.org/mailman/listinfo/dmarc

-MSK
--089e013d1da80ab05d04d945da52--