From hsantos@isdg.net Sat Feb 1 08:05:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435661A0424 for ; Sat, 1 Feb 2014 08:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_25=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St0ulsgQl690 for ; Sat, 1 Feb 2014 08:05:51 -0800 (PST) Received: from pop3.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 167C81A03E1 for ; Sat, 1 Feb 2014 08:05:50 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5821; t=1391270738; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=LYKWEyt2xL29oqWHHkP+dX0elHU=; b=LvnjKi7+dQtacSr36/DQ KiOODNK3KuL5zceAhuRL5kEFnoPMh5rMoiNSLutgl0QSVXoWBgVDdxuKaPSft7F6 3UQjRjQIYuQ98bgJv/r8ypu29OkdaoC5kltKgLP0ogCoGcTHSub2lt3P86UvBiew EajB3gYWy9SIS22ODXUltwQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 11:05:38 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 553222921.7116.3720; Sat, 01 Feb 2014 11:05:37 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5821; t=1391270140; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Jq1A6pJ bwiAnPmz2/lKm/E8u2YBm992NBNufP8jHCF4=; b=AtjW5RQT0GzS5YPvapC8k1R r7HPgKcq6vb6nqsfIoSwE9qqa/G+tGlXNVYB3LjJfQ9eVJx6NMfw52gVq9nQjB5X u3ZzxsWwNd0cenfR7C45nG6WbOX/YYhWiLtW/dn2WN/+zgslqiY6pD9bx0WQfdS5 mLsPr3iYDctmZjTwuZxM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 10:55:40 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4294486192.9.2976; Sat, 01 Feb 2014 10:55:39 -0500 Message-ID: <52ED1B53.1080701@isdg.net> Date: Sat, 01 Feb 2014 11:05:39 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 16:05:54 -0000 I support the fast adoption of NULLMX as a BCP method. Not as a standard method. As a PS, it may slow it down because *I don't see too many abandoning already long established, well embedded, finely tuned, well greased over many years of implicit MX code, queuing, scheduling outbound mail logic.* Things to consider: Can we be assured that any existing MX=0 records are not just mistakes, and they are indeed "no mail notifications"? Sending mail is "cheap" these days, DNS lookups is "cheap." Sure, its nice to optimized things, but it already is today. It isn't a problem today especially when there is decades of sending "queuing intelligence" already implemented. A failed receivers are generally filtered out pretty fast and it cost nothing. Its all automated. This is about YADDI (yet another domain discovery issue) (again) and there might be better solutions available for sending mail or in principle, contacting a host. In general, worthy changes need to be shown and justified to make it all worthy to consider. This is especially within the IETF that is increasing showing a direction to accepting PS ideas only latter to abandon them and do so less regard for the smaller end of the market place. I would like any new "change" to have more of an cost benefit impact to justify exploration. Something more than just "we don't do mail, so stop" notification. Anyway, I think its a good idea to explore as an BCP rather than a standard. This is keep it really simple. It should also help get it established faster for more rapid consideration by adopters. Labeling it as a proposed standard begins to force things and I don't see too many people dropping their long term engineered implicit MX logic. For example, we long supported a outbound sending rule: SupportNoMXTryOnce When the rule was enabled (ON), it basically set the sending queue maximum attempts to one when a MX lookup was empty. The default as ON long ago, but the default is not OFF and has been for many years now. I believe this change was due to two factors: - Reports of significant retry success with No MX, A records, - lower cost of operations (its "cheap"). I can see how a new MX lookup factor of MX=0 can be used to enable the try once logic: if MX.COUNT = 0 THEN SupportNoMXTryOnce = TRUE I can see this as a BCP suggestion, not as a standard suggestion. -- HLS On 1/30/2014 4:46 PM, Murray S. Kucherawy wrote: > Colleagues, > > This is a formal call for adoption of draft-delany-nullmx into > APPSAWG.� The call will close on February 14, 2014.� The chairs note > that there has already been some expression of support for adoption in > past threads; more feedback is requested. > > As you've heard us say in Vancouver and earlier, we are instituting a > new experimental idea with respect to documents in APPSAWG, namely > "mini-charters" in order to frame discussions, set goals, and secure a > minimal set of reviewers and supporters.� The mini-charter for this > draft appears at the end of this message. > > Please submit comments, concerns, support, etc. for this document's > handling by APPSAWG in reply to this thread by February 14, 2014.� > Note that this is not an indication of support for the document as-is, > only for APPSAWG adopting it for further development. > > The mini-charter lists four people (in addition to the authors) > willing to provide timely reviews and support for the document through > publication.� I'd like to be able to list a couple more.� If you'd > like to be added to that list, please say so in your reply. > > -MSK > > The mini-charter: > > SMTP mail has never provided a way for a domain to state that it does > not receive mail. �If a domain publishes MX records, it definitely > does receive mail. �If it publishes no MX, but does publish A or AAAA > records there is no way to tell whether those records are indended to > identify an "implicit MX". �If a sending host attempts to send to an A > or AAAA, and is unable to connect, there is no way to tell whether the > failure is temporary or permanent, short of repeated retries. > > As a result, if a user attempts to send mail to a mistyped domain, it > can take up to a week (the recommended retry limit) to get back a > failure report. �In principle, a domain could set up a stub mail > server that accepted connections and immediately rejected delivery > attempts, but that is more work than most domains want to do. �Hence > our goal is to provide a cheap way to quickly tell senders not to > bother. �(Note that an SPF record with "-all" says that a domain sends > no mail, which is not necessarily the same as receiving no mail.) > > We propose that an MX record pointing to the root of the DNS, known as > "MX ." means the domain accepts no mail. �This approach has been used > informally for almost a decade, with few if any problems, but has > never been described in an IETF document. �We propose only to assign > the no-mail semantics to "MX ." and not make any other changes to > SMTP. > > There is one draft to adopt: draft-delany-nullmx, to be submitted to > the IESG by the end of May, 2014. > > The following have committed to work on the document through to > publication: > > Murray Kucherawy > > Dave Crocker > > Terry Zink > > Arnt Gulbrandsend > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From hsantos@isdg.net Sat Feb 1 08:12:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8097F1A0424 for ; Sat, 1 Feb 2014 08:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.537 X-Spam-Level: X-Spam-Status: No, score=-100.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_25=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9ri8tQM1LBy for ; Sat, 1 Feb 2014 08:12:50 -0800 (PST) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 773501A0395 for ; Sat, 1 Feb 2014 08:12:50 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=770; t=1391271163; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=oJIoASDBNViiz9XUAnfqBf9x23U=; b=ml8+eWXVVhY0pG68wJLK 2escXAVGKX7fGPyNlUCicYSgUcy65dGx1PIgp3LVfdjpUNSqzzF0ngpYcVSzIAOC wMKjuEu+QRy5cnosmLnz2WVZ4YvlezhK32ABD8uCo2NN3jbTFsn5gFFNV3o3wmAC 9eHE1Oh5RsKaJlDr8+GSAZE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 11:12:43 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 553648102.7116.5988; Sat, 01 Feb 2014 11:12:42 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=770; t=1391270567; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6jn94Xn 0sSVB1k/2PEDZ1N/20RKVCBaKMS/j5Ek6nsM=; b=yeqRPCsXZVIre0aorv1S14Z pOfPGcFwCdPY8NKkJsrldX1zvQHoXJwvZZFvVvMayiALosUvNrsPBx7WKPV3EJ+N Ua/OULqTEx+QirGiS9OaaCOQnU+/a3BFvFU7wyJcFKsTzeX1NgkRv57QA5QFzT6u bDJOe8rhlnWx6F/kl854= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 11:02:47 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4294913364.9.792; Sat, 01 Feb 2014 11:02:46 -0500 Message-ID: <52ED1CFE.30304@isdg.net> Date: Sat, 01 Feb 2014 11:12:46 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <52ED1B53.1080701@isdg.net> In-Reply-To: <52ED1B53.1080701@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 16:12:51 -0000 Correction: On 2/1/2014 11:05 AM, Hector Santos wrote: > > For example, we long supported a outbound sending rule: > > SupportNoMXTryOnce > > When the rule was enabled (ON), it basically set the sending queue > maximum attempts to one when a MX lookup was empty. The default [was] ON > long ago, but the default is [now] OFF and has been for many years now. > I believe this change was due to two factors: > > - Reports of significant retry success with No MX, A records, > - lower cost of operations (its "cheap"). > > I can see how a new MX lookup factor of MX=0 can be used to enable the > try once logic: > > if MX.COUNT = 0 THEN SupportNoMXTryOnce = TRUE > > I can see this as a BCP suggestion, not as a standard suggestion. > > -- HLS From hsantos@isdg.net Sat Feb 1 09:52:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000B41A05BB for ; Sat, 1 Feb 2014 09:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQaznOrNRvdX for ; Sat, 1 Feb 2014 09:52:21 -0800 (PST) Received: from groups.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6862F1A0395 for ; Sat, 1 Feb 2014 09:52:21 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1144; t=1391277133; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PEkAGortGipsBRzFE3wIYaH8xRU=; b=wE5yNvo9QZB00jmC85/6 g1zIHHEtOmO4UuASSZpKYdwo4lLLQGWR7ftlPFMNhRjX26J3PqpNcp2CGf9eJAg6 FKGjYmPXKLBNr7iNvguvi1gLJzNRfhefOU9TDxYaZz9wZFAMh9DNyswwdhgXGnMa hE0t0F+8s4j2a9gBDvztxu4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 12:52:13 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 559618541.7116.1340; Sat, 01 Feb 2014 12:52:13 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1144; t=1391276538; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RspeYmN qyqCL5k7bUygmXxzFH+VQcXxnLGvTSBkwtkE=; b=qIoK93Aw284yuWeHbGC9dGa gXdM6coCobIMam8pq6f7BCdtJmr1V8bi07DCgvd38WRvcWn8DQGHVUJvr4ReT3/3 ezZmQmnTBsHPaA09wYCRNphyUJYtKwotDwv/RaYi7EHX/zSfkhvPqqNLqF2VpjoO zNu29jhQbBkHJSVmo2/Q= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 12:42:18 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 5917224.9.6772; Sat, 01 Feb 2014 12:42:17 -0500 Message-ID: <52ED3452.7040007@isdg.net> Date: Sat, 01 Feb 2014 12:52:18 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 17:52:25 -0000 I am wondering if it worth further pursuing this 2012 draft SMTPGREY SMTP extension proposal. SMTP Service Extension for Greylisting Operations http://tools.ietf.org/html/draft-santos-smtpgrey-02 Abstract GREYLIST is a SMTP extension to formalize the widely supported Greylisting mail filtering method and to help support SMTP rejected transports by following a new formal structured 4yz server temporary rejection response by including a "retry=time-delay" tag string which SMTP clients can use to optimize the rescheduling of the mail delivery attempts. With adoption, network overhead reduction in wasteful mail delivery attempts will be realized. This has been implemented and deployed among our deployed base of WCSMTP installations and has proven to be 100% successful in optimizing Send/Queuing scheduling retry logics. Back in 2012, the plan was to update the draft to rev 03 with interop field practice information. It was already a year in the field with high proof of concept and success rate. But for various reasons, further work and the draft update was put on the back burner. -- HLS From superuser@gmail.com Sat Feb 1 10:03:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1DC1A05BB for ; Sat, 1 Feb 2014 10:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPPzA3owgtLf for ; Sat, 1 Feb 2014 10:03:10 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 27B681A03EC for ; Sat, 1 Feb 2014 10:03:09 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id l18so10234266wgh.11 for ; Sat, 01 Feb 2014 10:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1UAiNY/JIyFHX8D4rzHE6Iw78wd7TpT5L7QjqN0YGEI=; b=J9cYZheStKytgUMQuUQrdkbZKHfZDB0otFvJ8jU0Jyvj1UtAmwMDAiAvM0GrAGJgoq 6s66NJVF9ppBWMvbtLykeGdI6ec3roinakFRut215BN7Snk2IA3csMseYwvx4V3+NWzA xd2BadeM8KlUWmoYVdecdozvthgqOPL6SYRt0I0PpID71EpVH1usT+tZzhkuashnxvsd qDcKRq/EtIlLnr6It92nkudqv7QN3TmTQcjE7dkzPTV5r3t88aNiTsyEOH0foUPqW7o2 VxwjqqxqTuTPS2HU8jmn+4bgsS6FkkOpIGKMrHGT01tetIUFivdwQA19gh6ljxE7DejU cI2Q== MIME-Version: 1.0 X-Received: by 10.180.104.72 with SMTP id gc8mr3160856wib.5.1391277785716; Sat, 01 Feb 2014 10:03:05 -0800 (PST) Received: by 10.180.98.41 with HTTP; Sat, 1 Feb 2014 10:03:05 -0800 (PST) In-Reply-To: <52ED3452.7040007@isdg.net> References: <52ED3452.7040007@isdg.net> Date: Sat, 1 Feb 2014 10:03:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=f46d044282c0339c6704f15c1a4f Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 18:03:11 -0000 --f46d044282c0339c6704f15c1a4f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 1, 2014 at 9:52 AM, Hector Santos wrote: > I am wondering if it worth further pursuing this 2012 draft SMTPGREY SMTP > extension proposal. > [...] > Do you have any implementation or interoperability data you can provide? -MSK, APPSAWG co-chair --f46d044282c0339c6704f15c1a4f Content-Type: text/html; charset=ISO-8859-1
On Sat, Feb 1, 2014 at 9:52 AM, Hector Santos <hsantos@isdg.net> wrote:
I am wondering if it worth further pursuing this 2012 draft SMTPGREY SMTP extension proposal.
[...]

Do you have any implementation or interoperability data you can provide?

-MSK, APPSAWG co-chair
--f46d044282c0339c6704f15c1a4f-- From hsantos@isdg.net Sat Feb 1 10:39:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47FA1A05CF for ; Sat, 1 Feb 2014 10:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm9vOBm4msTT for ; Sat, 1 Feb 2014 10:39:12 -0800 (PST) Received: from groups.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 72E421A044C for ; Sat, 1 Feb 2014 10:39:12 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1168; t=1391279945; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=cOcLB3IMIH6sUBPBDPf3Yf/zQa0=; b=nW2GlsO6wvRD8FEIvdkl cu9Vi65iYIMhIqySPW3rue3AFgwXZ20NScRqqem8hKqFQggqFnDMroylGlKQmnDg En4ZhjCSSE4dxnTc0Oebk8JbVaEg7toY0xj0Z2o1TuWFv5ntK8pzySXa0fNa8/SY EY/woZ6AmfK/mVFu0CheBIg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 13:39:05 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 562428836.7116.4256; Sat, 01 Feb 2014 13:39:03 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1168; t=1391279347; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=w+juwLx 3/97JS9vMo8PZthHH3CtG/NGW9XNEkGiPwEY=; b=n6CVWljgyAxwwB8DpG52l0W OZ4bqujdgIQrZxN0lEe6F+jatJ2XRkK2ghIxwisXp9SKwd1ou3wnrv4kc1o2GZAG EngU8WyKWA6gjVrRvhWXJujhfuC4tSbK42jw/rpvmUH6lW0Or/S3LZc82tv88WZM 81zFrZLflMk5anmJnW5g= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 01 Feb 2014 13:29:07 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 8726193.9.3076; Sat, 01 Feb 2014 13:29:06 -0500 Message-ID: <52ED3F4B.6060803@isdg.net> Date: Sat, 01 Feb 2014 13:39:07 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <52ED3452.7040007@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 18:39:13 -0000 On 2/1/2014 1:03 PM, Murray S. Kucherawy wrote: > On Sat, Feb 1, 2014 at 9:52 AM, Hector Santos > wrote: > > I am wondering if it worth further pursuing this 2012 draft > SMTPGREY SMTP extension proposal. > [...] > > > Do you have any implementation or interoperability data you can provide? For our own implementation and deployments of WCSMTP. No collections from other packages was made from a client standpoint. Many Greylisting servers do issue a time hint in their 45x greylisting responses in various forms. We can only speculate if other clients are parsing this non-standard information and leveraging it for their outbound mail retry scheduling logic. Our client parses for the common format seen out there, including the proposed format. The criteria for proof of concept would be a reduction of retries to a minimum of one try with the minimum amount of delivery delay. I can show that proof of concept with our logs of this occurring. For servers that issues a time hint, we have this minimum set. For others, there are redundant retries and longer delivery times. -- HLS From ned.freed@mrochek.com Sat Feb 1 10:49:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21E21A0576 for ; Sat, 1 Feb 2014 10:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkfP3nHri32i for ; Sat, 1 Feb 2014 10:49:16 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E5CCD1A044C for ; Sat, 1 Feb 2014 10:49:15 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3U8QINICG0045L6@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 1 Feb 2014 10:44:05 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3U385NTM80000AS@mauve.mrochek.com>; Sat, 1 Feb 2014 10:43:56 -0800 (PST) Message-id: <01P3U8QCU18U0000AS@mauve.mrochek.com> Date: Sat, 01 Feb 2014 10:09:59 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 31 Jan 2014 22:08:49 -0800 (PST)" <01P3TJALUVNE0000AS@mauve.mrochek.com> References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com> <01P3T5AP6CES0000AS@mauve.mrochek.com> <52EC3F59.8070608@nostrum.com> <01P3TC4YBNUO0000AS@mauve.mrochek.com> <52EC89D1.8050805@nostrum.com> <01P3TJALUVNE0000AS@mauve.mrochek.com> To: Ned Freed Cc: Ned Freed , draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Feb 2014 18:49:18 -0000 Having thought about this a bit more, it occurs to me that a common thread that underlies at least some of the discussion here isn't the need to provide deep background on the general workings of sieve, but rather that correct use of this extension depends on an understanding of the inherently asynchronous nature of email. In particular, you cannot depend on a message from a list arriving before or after an individual copy, and you cannot depend on alerts from multiple sources arriving in a particular order. Arnt pointed out the list/individual copy issue earlier, and Robert's example where some alerts have critical information attached and others don't touches on the latter issue. And generally it would be easy for users to mistakenly assume that they can depend on message ordering. As a rule I object to reiterating or summarizing technical material in other specifications, mostly because it tends to lose something in the translation. But this is, AFAIK, a new issue: We've defined mechanisms like vacation before that maintain state across messages, but this is the first sieve mechanisms that exposes such a mechanism directly to the end user. My suggestion would be to add an example of how *not* to use duplicate. The obvious one would be a usage that attempts to block individual cc's of list mail. (Such an example can be found in the earlier discussion.) Beyond that, I'm still at a loss as to what, if anything, needs to be added. Ned From cyrus@daboo.name Sat Feb 1 16:52:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783EF1A0018 for ; Sat, 1 Feb 2014 16:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOwMEh1ehEwC for ; Sat, 1 Feb 2014 16:52:14 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF431A0012 for ; Sat, 1 Feb 2014 16:52:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7D8605B4A086; Sat, 1 Feb 2014 19:52:10 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2sNa5e3MucL; Sat, 1 Feb 2014 19:52:08 -0500 (EST) Received: from [192.168.100.110] (unknown [66.201.56.195]) by daboo.name (Postfix) with ESMTPSA id EF9BF5B4A075; Sat, 1 Feb 2014 19:52:07 -0500 (EST) Date: Sat, 01 Feb 2014 16:52:06 -0800 From: Cyrus Daboo To: Ned Freed Message-ID: In-Reply-To: <01P3U8QCU18U0000AS@mauve.mrochek.com> References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com> <01P3T5AP6CES0000AS@mauve.mrochek.com> <52EC3F59.8070608@nostrum.com> <01P3TC4YBNUO0000AS@mauve.mrochek.com> <52EC89D1.8050805@nostrum.com> <01P3TJALUVNE0000AS@mauve.mrochek.com> <01P3U8QCU18U0000AS@mauve.mrochek.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1437 Cc: draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Feb 2014 00:52:17 -0000 Hi Ned, --On February 1, 2014 at 10:09:59 AM -0800 Ned Freed wrote: > My suggestion would be to add an example of how *not* to use duplicate. > The > obvious one would be a usage that attempts to block individual cc's of > list mail. (Such an example can be found in the earlier discussion.) > > Beyond that, I'm still at a loss as to what, if anything, needs to be > added. I think the current spec does the best that it can do to address a common problem at delivery time, but as noted in this thread, that may not be enough to cover more complex situations. What we could do in the future is go a step further and improve handling of duplicates post delivery - i.e. within the mail store (IMAP). So perhaps what is needed is a complementary specification that adds improved duplicate handling to IMAP. The obvious use case is to have IMAP flag changes applies across duplicate messages. This covers the common case of receiving the same message directly and via a list and wanting to "process" it (from the human perspective) only once. I suspect there are a lot of awkward scenarios that would need to be handled (e.g. what if a flag change is done when the first message arrives - should that change automatically apply when the duplicate is delivered). However, this might be worthwhile to consider - though it certainly should not block sieve duplicate from proceeding. -- Cyrus Daboo From ned.freed@mrochek.com Sun Feb 2 09:21:02 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92F41A00F5 for ; Sun, 2 Feb 2014 09:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcDffNBBPvcR for ; Sun, 2 Feb 2014 09:21:01 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE9D1A00ED for ; Sun, 2 Feb 2014 09:21:01 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3VJXJWOI80046ZK@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 2 Feb 2014 09:15:54 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3UKUOF2SG0000CD@mauve.mrochek.com>; Sun, 2 Feb 2014 09:15:49 -0800 (PST) Message-id: <01P3VJXGEU1O0000CD@mauve.mrochek.com> Date: Sun, 02 Feb 2014 09:12:22 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 01 Feb 2014 16:52:06 -0800" References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com> <01P3T5AP6CES0000AS@mauve.mrochek.com> <52EC3F59.8070608@nostrum.com> <01P3TC4YBNUO0000AS@mauve.mrochek.com> <52EC89D1.8050805@nostrum.com> <01P3TJALUVNE0000AS@mauve.mrochek.com> <01P3U8QCU18U0000AS@mauve.mrochek.com> To: Cyrus Daboo Cc: Ned Freed , draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Feb 2014 17:21:02 -0000 > Hi Ned, > --On February 1, 2014 at 10:09:59 AM -0800 Ned Freed > wrote: > > My suggestion would be to add an example of how *not* to use duplicate. > > The > > obvious one would be a usage that attempts to block individual cc's of > > list mail. (Such an example can be found in the earlier discussion.) > > > > Beyond that, I'm still at a loss as to what, if anything, needs to be > > added. > I think the current spec does the best that it can do to address a common > problem at delivery time, but as noted in this thread, that may not be > enough to cover more complex situations. What we could do in the future is > go a step further and improve handling of duplicates post delivery - i.e. > within the mail store (IMAP). > So perhaps what is needed is a complementary specification that adds > improved duplicate handling to IMAP. The obvious use case is to have IMAP > flag changes applies across duplicate messages. This covers the common > case of receiving the same message directly and via a list and wanting to > "process" it (from the human perspective) only once. I suspect there are a > lot of awkward scenarios that would need to be handled (e.g. what if a flag > change is done when the first message arrives - should that change > automatically apply when the duplicate is delivered). However, this might > be worthwhile to consider - though it certainly should not block sieve > duplicate from proceeding. I don't quite see what duplicating flag changes would accomplish - it seems to me that you really need to actually consolidate the two copies of the message in some way - but I am in complete agreement that some kinds of duplicate elimination can only be made to work at the store level. And that's far beyond the purview of hte present draft. Whether or not that's implementable/deployable is another matter, of course. Ned From superuser@gmail.com Sun Feb 2 17:14:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21391A014E for ; Sun, 2 Feb 2014 17:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OdBJj0tITvc for ; Sun, 2 Feb 2014 17:14:40 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDA21A014D for ; Sun, 2 Feb 2014 17:14:40 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id a1so11472384wgh.16 for ; Sun, 02 Feb 2014 17:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ofs/J9PLB1q0mh07b5Fb1IMORPcNn5i+0ZswiQg291g=; b=pSPTweTn7HNghO3K8JdQBbexIHqJPkJPUW/L8p3PjLqERlqvA/XwkNQzONbkWOsPKs gUn9U3SHs4WhWGpD6m8f8B1QabDcVkjKU6TQ4rodCCesVrqRWzjqEHAOtx9nj0AKrhm3 Y962jLzjWaAhN2cyGRbsmLCYinGcwG+g7VrvbYIsRlpaEheUT9VCFr/WQVQ+auu4oQgL u0bj7SOcza4AWrLcUmpnK3cBiLmFrlYKOyXff9N4k7MIraVu6Cvie5J/PH15paO5Xn1e l/PBg9vX/HthliQTTLpg6V0lYL2tEbm49eqi+W9jEf4bpU3Xq1UCc5DABXkH3tuAXj4l w/cg== MIME-Version: 1.0 X-Received: by 10.194.175.66 with SMTP id by2mr6505wjc.59.1391390075183; Sun, 02 Feb 2014 17:14:35 -0800 (PST) Received: by 10.180.98.41 with HTTP; Sun, 2 Feb 2014 17:14:35 -0800 (PST) In-Reply-To: <52ED3F4B.6060803@isdg.net> References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> Date: Sun, 2 Feb 2014 17:14:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=089e013d19f82ce8e104f1763f09 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 01:14:42 -0000 --089e013d19f82ce8e104f1763f09 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos wrote: > For our own implementation and deployments of WCSMTP. > > No collections from other packages was made from a client standpoint. > Does anyone else have current or planned implementations of this draft they'd like to discuss? > Many Greylisting servers do issue a time hint in their 45x greylisting > responses in various forms. We can only speculate if other clients are > parsing this non-standard information and leveraging it for their outbound > mail retry scheduling logic. Our client parses for the common format seen > out there, including the proposed format. > Can you point to some of the server implementations that do this? Are they following the syntax in this draft? --089e013d19f82ce8e104f1763f09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos <hsantos@= isdg.net> wrote:
For our own implementation and deployments o= f WCSMTP.

No collections from other packages was made from a client standpoint.

Does anyone else have current or planned imp= lementations of this draft they'd like to discuss?
=A0
Many Greylisting servers do issue a time hint in their 45x greylisting resp= onses in various forms. =A0 We can only speculate if other clients are pars= ing this non-standard information and leveraging it for their outbound mail= retry scheduling logic. =A0Our client parses for the common format seen ou= t there, including the proposed format.

Can you point to some of the server implem= entations that do this?=A0 Are they following the syntax in this draft?
=
--089e013d19f82ce8e104f1763f09-- From superuser@gmail.com Sun Feb 2 17:16:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EFD1A014E for ; Sun, 2 Feb 2014 17:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxZ4zqX1oQug for ; Sun, 2 Feb 2014 17:16:03 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1D81A014D for ; Sun, 2 Feb 2014 17:16:02 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id y10so11056240wgg.8 for ; Sun, 02 Feb 2014 17:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AjMUEsQfDmii0na15JpbAvpTeB7BsQz0H48dKxY8LR4=; b=AkttWOGx6mm7mw9zTkQ0dy+QLMeLEnqeZlZSwcKswzomKSYWxZRVyd5eC4NjklMGXW mcKqRniQHfNZW1d6PBSUh3mXOWNHfol3HpbGHDHvJz9Urc+tOfCX98hhNpdIFvlp9dFL wQYuPOZd1JPBLXBF4Z3lp5Mf8obaXQJNafgimos22mKI6PrAFa/pVD3ddARG+2l/lG7f fXEFFYahatj6vR2kJS8PybpK26sXQoa4cnCOX37KRNpr1uUTYSeogAAPUITKo7wx5Jbv wQcJOsrLkd406ullCVV4yMepJseVA/0wp8i1sYFF20xBd2emNkwyfo8tgkefRMnkYMkD jlWQ== MIME-Version: 1.0 X-Received: by 10.180.187.16 with SMTP id fo16mr6756923wic.26.1391390158247; Sun, 02 Feb 2014 17:15:58 -0800 (PST) Received: by 10.180.98.41 with HTTP; Sun, 2 Feb 2014 17:15:57 -0800 (PST) In-Reply-To: <52ED1B53.1080701@isdg.net> References: <52ED1B53.1080701@isdg.net> Date: Sun, 2 Feb 2014 17:15:57 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c266c4205d8e04f17644e3 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 01:16:07 -0000 --001a11c266c4205d8e04f17644e3 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 1, 2014 at 8:05 AM, Hector Santos wrote: > I support the fast adoption of NULLMX as a BCP method. Not as a standard > method. As a PS, it may slow it down because *I don't see too many > abandoning already long established, well embedded, finely tuned, well > greased over many years of implicit MX code, queuing, scheduling outbound > mail logic.* > As this describes the exchange of data between two agents (via the DNS), and not merely a common practice, I believe Proposed Standard is the more appropriate status rather than BCP. Any other opinions? -MSK --001a11c266c4205d8e04f17644e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 1, 2014 at 8:05 AM, Hector Santos <hsantos@isd= g.net> wrote:
I support the fast adoption of NULLMX as a B= CP method. Not as a standard method. =A0As a PS, it may slow it down becaus= e *I don't see too many abandoning already long established, well embed= ded, finely tuned, well greased over many years of implicit MX code, queuin= g, scheduling outbound mail logic.*

As this describes the exchange of data bet= ween two agents (via the DNS), and not merely a common practice, I believe = Proposed Standard is the more appropriate status rather than BCP.=A0 Any ot= her opinions?

-MSK
--001a11c266c4205d8e04f17644e3-- From dhc@dcrocker.net Sun Feb 2 20:19:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15941A0099 for ; Sun, 2 Feb 2014 20:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUcy2UOUPtfN for ; Sun, 2 Feb 2014 20:19:31 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B38491A0040 for ; Sun, 2 Feb 2014 20:19:31 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s134JMoe032641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Feb 2014 20:19:26 -0800 Message-ID: <52EF18AD.3080500@dcrocker.net> Date: Sun, 02 Feb 2014 20:18:53 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <52ED1B53.1080701@isdg.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 02 Feb 2014 20:19:26 -0800 (PST) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 04:19:32 -0000 On 2/2/2014 5:15 PM, Murray S. Kucherawy wrote: > As this describes the exchange of data between two agents (via the DNS), > and not merely a common practice, I believe Proposed Standard is the > more appropriate status rather than BCP. Any other opinions? It is absolutely a protocol spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Sun Feb 2 23:30:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AB31A0180 for ; Sun, 2 Feb 2014 23:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O7D3DztiR9J for ; Sun, 2 Feb 2014 23:30:46 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9CADB1A017F for ; Sun, 2 Feb 2014 23:30:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3WDM4BAXC003UMS@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 2 Feb 2014 23:25:40 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3UKUOF2SG0000CD@mauve.mrochek.com>; Sun, 2 Feb 2014 23:25:36 -0800 (PST) Message-id: <01P3WDM2RDYG0000CD@mauve.mrochek.com> Date: Sun, 02 Feb 2014 22:57:39 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 02 Feb 2014 17:14:35 -0800" References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> To: "Murray S. Kucherawy" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 07:30:48 -0000 > On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos wrote: > > For our own implementation and deployments of WCSMTP. > > > > No collections from other packages was made from a client standpoint. > > > Does anyone else have current or planned implementations of this draft > they'd like to discuss? We see greylisting as something best done by a milter, so we're unlikely to implement direct support in our MTA. That said, a milter has the ability to set the SMTP response string to anything it wants. The only problem a milter would have is changing the EHLO response to include the GREYLISTING extension. AFAIK that is not a milter capability. We have a way to do that outside of milter but I don't know if other milter-supporting MTAs do. > > Many Greylisting servers do issue a time hint in their 45x greylisting > > responses in various forms. We can only speculate if other clients are > > parsing this non-standard information and leveraging it for their outbound > > mail retry scheduling logic. Our client parses for the common format seen > > out there, including the proposed format. > > > Can you point to some of the server implementations that do this? Are they > following the syntax in this draft? milter-greylist has the ability to return SMTP responses containing the retry time. The format is settable, so it should be able to generate something that conforms to this RFC. There are various other milters that support greylisting; I don't know about their capabilites. Ned From Claudio.Allocchio@garr.it Sun Feb 2 23:47:59 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125AB1A0175 for ; Sun, 2 Feb 2014 23:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.656 X-Spam-Level: X-Spam-Status: No, score=-0.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHSkIcTN_O7H for ; Sun, 2 Feb 2014 23:47:57 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 05F411A006B for ; Sun, 2 Feb 2014 23:47:56 -0800 (PST) Received: internal info suppressed Date: Mon, 3 Feb 2014 08:47:40 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: dcrocker@bbiw.net In-Reply-To: <52EF18AD.3080500@dcrocker.net> Message-ID: References: <52ED1B53.1080701@isdg.net> <52EF18AD.3080500@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1391413662; bh=YQsaf9W64tDwUvNDiqrxVWSdhbhBBQJmC43FIh2IJiU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O2GR26ZwVLXUxcGF/wh3suu98TiszNwBPo1Yp5ZMf7IZT/Unsv48NeaZuOwDCXFAJ JXkWTUWRqGI2iNgdUqUJMgtsjIhXIoyxsHGG7F7tww02CS4y7mYnT16U+NETCNAir3 RusBqFzAuyLoalS6OBoJBKUL0rrnM7z3LKAEacGI= Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 07:47:59 -0000 On Sun, 2 Feb 2014, Dave Crocker wrote: > On 2/2/2014 5:15 PM, Murray S. Kucherawy wrote: >> As this describes the exchange of data between two agents (via the DNS), >> and not merely a common practice, I believe Proposed Standard is the >> more appropriate status rather than BCP. Any other opinions? > > > It is absolutely a protocol spec. yes! It defines automated machine interaction. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From hsantos@isdg.net Mon Feb 3 05:41:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD171ADBD3 for ; Mon, 3 Feb 2014 05:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twQWIncrdz5n for ; Mon, 3 Feb 2014 05:41:40 -0800 (PST) Received: from ntbbs.santronics.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EB4771ADBD2 for ; Mon, 3 Feb 2014 05:41:39 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2049; t=1391434898; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=pCM4AmClQRsCqYbbpN2nHRlgjgs=; b=uvGFq6ZPdBebHsGlsn4X 1XN/E+EgGYBp3A2N9S2s9LdQriUuxHnOPg1tGM7qs0yllj9myNQ/+IPdy8cL0+2E VUS0dYOb4Vt78VaS71/H/tWPonhj2AsGIDTO3WkYGMh3FVtIrrbYM93EcDmqgIjD UFGLo1x2+G9xyCUSurfkUWY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 03 Feb 2014 08:41:38 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 717380745.10379.5180; Mon, 03 Feb 2014 08:41:37 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2049; t=1391434297; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yrhQ0Pr 9dHqnhmAXjHOiH2H/5oo26Y7WqMJL9LanMWI=; b=fM1p6LkKW5cewy2KYOHfd4Y ZqGiJEKKvu6ykKFjQU9UvccpNZEyeMqg7SsVs01onmy/LD2UvjvruwJfyG0ELImU /S+5pEeLd7hCcFdHS6jkN09kGU+yP3JUdqG7u+HRpRXClEIMlfeIP3lkikc51Dte heb+AhjlSf+LpfmZr3zE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 03 Feb 2014 08:31:37 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 163675974.9.7188; Mon, 03 Feb 2014 08:31:36 -0500 Message-ID: <52EF9C8D.8090909@isdg.net> Date: Mon, 03 Feb 2014 08:41:33 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 13:41:42 -0000 On 2/2/2014 8:14 PM, Murray S. Kucherawy wrote: > On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos > wrote: > > For our own implementation and deployments of WCSMTP. > > No collections from other packages was made from a client standpoint. > > > Does anyone else have current or planned implementations of this draft > they'd like to discuss? I have also wondered if the servers (see below) that do expose time hints have package companion clients that support it. > > Many Greylisting servers do issue a time hint in their 45x > greylisting responses in various forms. � We can only speculate if > other clients are parsing this non-standard information and > leveraging it for their outbound mail retry scheduling logic. �Our > client parses for the common format seen out there, including the > proposed format. > > > Can you point to some of the server implementations that do this?� Are > they following the syntax in this draft? I can't tell you of brands, but section 2.4, summaries the ones I have collected in the wild (from our outbound logs) that issue retry time hints in their temporary reject responses. http://tools.ietf.org/html/draft-santos-smtpgrey-02#section-2.4 421 This server implements greylisting, please try again in # seconds 450 4.7.1 : Recipient address rejected: Greylisted for # minutes 450 4.7.1 : Recipient address rejected: Greylisted for # seconds 451 4.7.1 Greylisting in action, please come back in HH:MM:SS 451 Greylisted for # seconds So the intent is there by greylisting servers to provide "information" for future clients to use when possible. In practice, I have found the servers do honor and are correct with the times. I have not found any instance of the info being wrong. If it said wait X mins, your client waited X mins and there was no more delivery blocks/delays. If I have found any instance where it was just wrong, then I wouldn't had bother with this. Thanks -- HLS From hsantos@isdg.net Mon Feb 3 05:44:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9D41A021B for ; Mon, 3 Feb 2014 05:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7weZQ7UEMC0 for ; Mon, 3 Feb 2014 05:44:27 -0800 (PST) Received: from ntbbs.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BD7881ADE87 for ; Mon, 3 Feb 2014 05:30:41 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2156; t=1391434237; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Oj6wpwXmxeUubAi4ijyb0OI6jds=; b=oeLGXvkOfiQUT/mbmkqe NmwMJzrf8qSdgyiHQu1W8bcV8z295Cjt+pVFoD9M8/G/0l+NPqNDXpv1cWra7izi zgpUcg9qq2WaQ6wXLLIxA+aEcqeT6TVggNMhw0EYLRNnflrStTqVKhE7H/StbYZg BdRdErgUJI7/zBwakEEoAmw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 03 Feb 2014 08:30:37 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 716720502.10379.4356; Mon, 03 Feb 2014 08:30:36 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2156; t=1391433637; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hvsD9H/ J61i3hvPVg+77xKK9uE7Y4qCIh7UQs8JEmOM=; b=lbVKJRf1Sqe8U8ME1NqACt4 xQzOrYRMk/zZFeKJsiO1Xr8iPeOGxyAi8/w4JwXOF1QhExelvKJLV1ZzjIlhggVj s9Mw1r1q+wkOH/dJN1mNeZPhDayfzP6FBp9mEAvsbMCPReTwxAuGvPprUiunRvJo 6NiaAS8dQXBVs2UaPQs0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 03 Feb 2014 08:20:37 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 163016631.9.2096; Mon, 03 Feb 2014 08:20:37 -0500 Message-ID: <52EF99F9.1070908@isdg.net> Date: Mon, 03 Feb 2014 08:30:33 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ned Freed References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> In-Reply-To: <01P3WDM2RDYG0000CD@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 13:44:30 -0000 On 2/3/2014 1:57 AM, Ned Freed wrote: >> On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos wrote: > >>> For our own implementation and deployments of WCSMTP. >>> >>> No collections from other packages was made from a client standpoint. >>> > >> Does anyone else have current or planned implementations of this draft >> they'd like to discuss? > > We see greylisting as something best done by a milter, so we're unlikely to > implement direct support in our MTA. That said, a milter has the ability to set > the SMTP response string to anything it wants. The only problem a milter would > have is changing the EHLO response to include the GREYLISTING extension. AFAIK > that is not a milter capability. We have a way to do that outside of milter but > I don't know if other milter-supporting MTAs do. The service extension keyword was made optional http://tools.ietf.org/html/draft-santos-smtpgrey-02#section-3.1.1 The intent was to offer a method to expose a retry=time-delay (the blocking time) via the keyword and not depend on servers adding and clients parsing of 45x response text. >>> Many Greylisting servers do issue a time hint in their 45x greylisting >>> responses in various forms. We can only speculate if other clients are >>> parsing this non-standard information and leveraging it for their outbound >>> mail retry scheduling logic. Our client parses for the common format seen >>> out there, including the proposed format. >>> > >> Can you point to some of the server implementations that do this? Are they >> following the syntax in this draft? > > milter-greylist has the ability to return SMTP responses containing the retry > time. The format is settable, so it should be able to generate something that > conforms to this RFC. > > There are various other milters that support greylisting; I don't know about > their capabilites. Yes, for servers, getting the response in is the easy part. The benefit is for the client to leverage it for their existing rescheduling logic. Those that do should see a benefit in minimizing retries and delivery delays. -- HLS From johnl@iecc.com Mon Feb 3 10:15:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689791A017E for ; Mon, 3 Feb 2014 10:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.043 X-Spam-Level: * X-Spam-Status: No, score=1.043 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o_LnSt45BgK for ; Mon, 3 Feb 2014 10:15:16 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id D0AA81A01D6 for ; Mon, 3 Feb 2014 10:15:15 -0800 (PST) Received: (qmail 32448 invoked from network); 3 Feb 2014 18:15:15 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Feb 2014 18:15:15 -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; s=52efdcb3.xn--30v786c.k1402; i=johnl@user.iecc.com; bh=cQgMsFqAk0S8AUUf/pWNlvmmnB+0+fIuCGeBjmAPt4w=; b=EAbeHgsIPqid3feY3QfK9sWpYyQqlwTjKCQF8BvscjMf0tMlUmSy1qM/pEGcZdyq8mE6Nr/gNPvobu/SnTFrq9SWVOFaQVQPeoJ7pw4krGzdZYKqTYD4L5uZsYUQWFx6ITvUwiCVluAGYUzYVjxyWt5t4fWeZVeEHG45ZGoqNRpZz2mkPd6JcNGoTJ8snMwgUJfbATS8r7G53wDmv5ZMCgc+dENrD5yuxpDk1b5BuQlOouOOLq0zGXR0qHu5walv 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; s=52efdcb3.xn--30v786c.k1402; bh=cQgMsFqAk0S8AUUf/pWNlvmmnB+0+fIuCGeBjmAPt4w=; b=VBiHl9nmUF9wZZSGaLn0ALvuDsRK3r4BcJDTM2FJTtRflWkzxbksMI253wUTHgrEL6dopr+hEIiwSBjxL2sfV6ka9cRxKgpAEmp1MeYDIL954WgTB6ubhHMfFCLsWMPwv1duYAS9YSIu/wqUJ3FNcvHld3cgZr/yQwtWZc9nMbOD15ZNt46wWyxyOfwZNGF7Ixnrsld4PMibebvaqKONQIYr6MS79HZH11q0o519CSsVO1F73GEKKP5NYFqsObi5 Date: 3 Feb 2014 18:14:52 -0000 Message-ID: <20140203181452.8569.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01P3WDM2RDYG0000CD@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 18:15:17 -0000 >There are various other milters that support greylisting; I don't know about >their capabilites. My greylister calls out to a daemon, which just returns one bit, accept or softfail. I couldn't implement this even if I thought it were a good idea. R's, John From ned.freed@mrochek.com Mon Feb 3 11:18:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F341A01D6 for ; Mon, 3 Feb 2014 11:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ppg23Jk4E7Q for ; Mon, 3 Feb 2014 11:18:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 95AD21A016D for ; Mon, 3 Feb 2014 11:18:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3X2CKJSZ4002TUD@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 3 Feb 2014 11:13:24 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3UKUOF2SG0000CD@mauve.mrochek.com>; Mon, 3 Feb 2014 11:13:21 -0800 (PST) Message-id: <01P3X2CJ52RA0000CD@mauve.mrochek.com> Date: Mon, 03 Feb 2014 09:06:50 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 03 Feb 2014 08:30:33 -0500" <52EF99F9.1070908@isdg.net> References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> To: Hector Santos Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 19:18:28 -0000 Sorry, I should have commented on the client rescheduling aspect of this in my first response. First of all, this is trivially easy for us to implement, at least in principle. All we have to do is parse out the value from the response and then make a single subroutine call. It really is just that easy with our queue manager. But as always, the devil is in the details. Obviously you can't fully trust the value you get since there are obviously ways small (or large) values could be used to enhance a service denial attack. So there have to be allowed ranges for the values. But is that enough control? I don't know if it is or not. In particular, should MT-PRIORITY be tied into this, and if so, how should it be done? (Different allowed ranges for different priorities is the obvious answer, and may be a reasonable starting point.) And then there's the message versus host issue. We have the ability to either reschedule this one message or reschedule all the messages headed to a particular host. Which one makes sense depends on what sort of greylisting is being done: Is it purely based on the sending host or is it based on some characteristics of the specific message? And before anyone says that you can determine that by the phase at which the greylisting occurs, sorry, no you can't. In my experience it's not at all uncommon for IP-level greylisting to happen as late as RCPT TO phase, and I wouldn't be surprised if it can happen at the end of data. And if you get this one wrong use of this extension could easily increase rather than decrease delivery times with greylisting schemes that penalize overly aggressive retries at the sending host level. The obvious way to address this is to add some enhanced status codes to say whether or not the retry value is intended to apply to this one message or to the sending host as a whole. But I have to wonder if people setting this up would understand the distinction, and I also have to wonder if other queue managers are capable of making use of it. And finally, we have to take the least astonishment principle into account. For whatever reason some sites obsess over the predictability of message retry intervals: Any time they see what they regard as unusual behavior in this regard, they get very excited and demand an analysis be done. Our support people then have to waste time digging in to what invariably turns out to be have a perfectly reasonable explanation: a queue backlog, an unresponsive destination, bad configuration setting, etc. etc. Unfortunately, given their obsession with delivery times such sites are likely to be first in line to enable such functionality if it is available. The possible consequences of this in terms of support time should be obvious. The bottom line is that if this is standardized, given how easy this is for us to support we'd probably implement it. But given the risks we might have to make it a restricted option, which would substantially lessen the liklihood of sites actually using it. Finally, I missed the optional nature of the GREYLIST extension. I have to say I'm not comfortable with assigning semantics to the content of a response line absent a clear indication of what the contents of that line mean. Ned From hsantos@isdg.net Mon Feb 3 13:05:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267B71A024D for ; Mon, 3 Feb 2014 13:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33sZKvM05uWb for ; Mon, 3 Feb 2014 13:05:33 -0800 (PST) Received: from ntbbs.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 183CB1A0237 for ; Mon, 3 Feb 2014 13:05:32 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1907; t=1391461523; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=NXNm62fisnocUQpxalrFild88c8=; b=huEXSiiq+6VPciFEqvHI a7fFjlS6NQYbeYsI9+5ZHhpwiWtB0PwED0hQ8DKFyUoD+ioHlUS1LKMPvW+AzilO 1WEzyYPOd4Xm0Ig0wAQOiLMvaYdRKxkYpkqo1rC/iffHTaB8M9seVXmzhOH95Nys C24LDCCqCbcJ3Scd9s2Q2Ww= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 03 Feb 2014 16:05:23 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 744006107.10379.5944; Mon, 03 Feb 2014 16:05:22 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1907; t=1391460924; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=3vxrYVv erAim+EDmSaWgxUZ9QQhm6NcenTSFtv2VeEQ=; b=1p0quXSCDfR+0EG77eUxiYq tzOJgqIanNbQEY94J3SkXKJwpn9t/hoJARwYlz0L8fgrFwhVKQRGWfNaleWryv9j bzolq5H1HcJx4oUPkgoYWpvgfAlTb2heuojGcajQWdsZhHc6hY6u13sk+vFlDXX6 YBF7kPU6mZFSN2EApwIQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 03 Feb 2014 15:55:24 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 190303834.9.2340; Mon, 03 Feb 2014 15:55:24 -0500 Message-ID: <52F00491.2090000@isdg.net> Date: Mon, 03 Feb 2014 16:05:21 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: <20140203181452.8569.qmail@joyce.lan> In-Reply-To: <20140203181452.8569.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: apps-discuss@ietf.org Cc: ned.freed@mrochek.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 21:05:36 -0000 On 2/3/2014 1:14 PM, John Levine wrote: >> There are various other milters that support greylisting; I don't know about >> their capabilites. > > My greylister calls out to a daemon, which just returns one bit, > accept or softfail. > Keep in mind there are two parts to this: 1) Helping OTHER systems improve delivery, 2) Helping YOUR system improve delivery. For #1, you can do this by changing your response to include a fixed blocking time related to your GreyList mfilter setup. This is mostly an administrator, sysop level work requirement. For #2, that is more software work on the sender-MTA where you parse/extract the time hint, if any, from the temporary reject responses and pass that TIME to your MTA Send/Queuing logic and algorithm. So this requires code change most likely, code developers, systems folks, even administrators. Except for the response template change, it wouldn't have anything to do with a GREYLIST mfilter, shim, callout, blackbox true/false process, handling of incoming calls. It is about the mail sender who is getting hit with other greylisting server forcing delays. Its about improving SENDER QUEUE/RETRY LOGIC and minimizing delivery delays in dealing with a current reality and wide existence of Greylisting Servers. All good and practical ideas to consider if delays is something you wish to address associated to forced temporary reject block delays. Most systems have a progressive retry logic where delays increase or vary with more tries. This proposed method has proven to shown over time to reduce all delays to the bare minimum number of retries which is two with no extra time delays than necessary. > I couldn't implement this even if I thought it were a good idea. Your reasoning would be insightful. Would there be a technical problem, a security problem and/or feasibility problem? -- HLS From derek.diget+apps-discuss@wmich.edu Mon Feb 3 14:25:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E771A0248 for ; Mon, 3 Feb 2014 14:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.75 X-Spam-Level: *** X-Spam-Status: No, score=3.75 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSfJfDMuNF4T for ; Mon, 3 Feb 2014 14:25:03 -0800 (PST) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id D40201A015D for ; Mon, 3 Feb 2014 14:25:03 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0N0F008DCY9MET10@mta01.service.private> for apps-discuss@ietf.org; Mon, 03 Feb 2014 17:25:03 -0500 (EST) X-WMU-Spam: Gauge=X, Probability=10% on Mon Feb 3 17:25:03 2014, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2014.2.3.221514 - Mon Feb 3 17:25:02 2014 Date: Mon, 03 Feb 2014 17:24:58 -0500 (EST) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: IETF Apps Discuss In-reply-to: <01P3WDM2RDYG0000CD@mauve.mrochek.com> Message-id: References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 03 Feb 2014 22:25:05 -0000 On Feb 2, 2014 at 22:57 -0800, Ned Freed wrote: =>> On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos wrote: =>> > For our own implementation and deployments of WCSMTP. =>> > =>> > No collections from other packages was made from a client standpoint. => =>> Does anyone else have current or planned implementations of this draft =>> they'd like to discuss? => =>We see greylisting as something best done by a milter, so we're unlikely to =>implement direct support in our MTA. That said, a milter has the ability to set =>the SMTP response string to anything it wants. The only problem a milter would =>have is changing the EHLO response to include the GREYLISTING extension. AFAIK =>that is not a milter capability. We have a way to do that outside of milter but =>I don't know if other milter-supporting MTAs do. FYI, we use Ned's software and have the following defined in our ORIG_MAIL_ACCESS mapping (based on the Comms Suite Greylisting Wiki page at ) ! Check the source IP address only using the first three octets in the ! string passed to MeterMaid, sender (canonicalized via X-CORRESPONDENT ! mapping recursion lookup), and recipient in MeterMaid's greylist ! table. ! ! If the call to greylisting() returns success, then Messaging Server ! should return a temporary rejection. If the call fails, then the ! greylisting check has passed and other access control checks can continue TCP|$@*|$@*|$D*.$D*.$D*.$@*|$@*|SMTP$@*|MAIL|tcp_mx|*|l|*|true $C$[IMTA_LIB:check_metermaid.so,greylisting,greylist,$0.$1.$2|$|X-CORRESPONDENT;$3||$4]$N$X4.7.1|Temporary$ greylist$ rejection$ -$ retry$ in$ retry=00:03:00$ $E Which causes the following SMTP response: 451 4.7.1 Temporary greylist rejection - retry in retry=00:03:00 : RECIPIENT@RECIPIENT-DOMAIN I don't have any data on how many clients then following our suggestion. I know we are less than a grain of sand on the mail flow beach, but thought that I would speak up as one receiver. :) -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From hsantos@isdg.net Mon Feb 3 21:42:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0471A01F9 for ; Mon, 3 Feb 2014 21:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.55 X-Spam-Level: X-Spam-Status: No, score=-94.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gt3XYmFTYX2 for ; Mon, 3 Feb 2014 21:42:39 -0800 (PST) Received: from news.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E42611A02D6 for ; Mon, 3 Feb 2014 21:42:38 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2426; t=1391492545; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=E1v20OhSq5JQAPIJ4IGBmVFLDr0=; b=iaddiQrNp/4Y0fSa//B8 beMnhXy0XancVMotwhnLnqzSPz3w7E3ZAtECf2wq1PHH757HWRGfiMkvGGkeUN0A a9gWn87nLTt2B373WJhCmzpzA+ENopwl+yqzFl+lOH86IvqwW5t+eR0SZEZ1mJIF 9Uu0rXBED/BKzJQ+ZEFeQIs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 04 Feb 2014 00:42:25 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 775026796.10379.4744; Tue, 04 Feb 2014 00:42:23 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2426; t=1391491942; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GkfjI1Y FJhzqmjRmDMVhXLRI3DJ+Su5k0kWCWdFyyRA=; b=mgfcg9qL0L60xXLczqQzcgP wEzQRuEbcOlHqDQOViOBsCIMm/WlZ44aioqfdPeHOVrCLm70628P8NEgdRDh/lu4 lcAU00kDJGgppbHK52w4CRimNqEMrvxquSleR1z2H4Xj/MaV7RG8nRQGavorPj0O G4N5WLSFZsLu22kKKlzY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 04 Feb 2014 00:32:22 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 221320459.9.6852; Tue, 04 Feb 2014 00:32:20 -0500 Message-ID: <52F07DBB.9060204@isdg.net> Date: Tue, 04 Feb 2014 00:42:19 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Derek Diget References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 05:42:43 -0000 Hi Derek, any mail being sent from our clients (Wildcat! SMTP) to receivers using Ned's software would honor this assuming retry=HH:MM:SS format for scheduling the next (2nd) attempt. On 2/3/2014 5:24 PM, Derek Diget wrote: > > On Feb 2, 2014 at 22:57 -0800, Ned Freed wrote: > =>> On Sat, Feb 1, 2014 at 10:39 AM, Hector Santos wrote: > =>> > For our own implementation and deployments of WCSMTP. > =>> > > =>> > No collections from other packages was made from a client standpoint. > => > =>> Does anyone else have current or planned implementations of this draft > =>> they'd like to discuss? > => > =>We see greylisting as something best done by a milter, so we're unlikely to > =>implement direct support in our MTA. That said, a milter has the ability to set > =>the SMTP response string to anything it wants. The only problem a milter would > =>have is changing the EHLO response to include the GREYLISTING extension. AFAIK > =>that is not a milter capability. We have a way to do that outside of milter but > =>I don't know if other milter-supporting MTAs do. > > FYI, we use Ned's software and have the following defined in our > ORIG_MAIL_ACCESS mapping (based on the Comms Suite Greylisting Wiki page > at > ) > > ! Check the source IP address only using the first three octets in the > ! string passed to MeterMaid, sender (canonicalized via X-CORRESPONDENT > ! mapping recursion lookup), and recipient in MeterMaid's greylist > ! table. > ! > ! If the call to greylisting() returns success, then Messaging Server > ! should return a temporary rejection. If the call fails, then the > ! greylisting check has passed and other access control checks can continue > > TCP|$@*|$@*|$D*.$D*.$D*.$@*|$@*|SMTP$@*|MAIL|tcp_mx|*|l|*|true $C$[IMTA_LIB:check_metermaid.so,greylisting,greylist,$0.$1.$2|$|X-CORRESPONDENT;$3||$4]$N$X4.7.1|Temporary$ greylist$ rejection$ -$ retry$ in$ retry=00:03:00$ $E > > > Which causes the following SMTP response: > > 451 4.7.1 Temporary greylist rejection - retry in retry=00:03:00 : RECIPIENT@RECIPIENT-DOMAIN > > > I don't have any data on how many clients then following our suggestion. > > > I know we are less than a grain of sand on the mail flow beach, but > thought that I would speak up as one receiver. :) > -- HLS From superuser@gmail.com Mon Feb 3 22:13:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95921A0366 for ; Mon, 3 Feb 2014 22:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIzDZm4-mn6K for ; Mon, 3 Feb 2014 22:13:04 -0800 (PST) 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 D346D1A0360 for ; Mon, 3 Feb 2014 22:13:03 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so3963722wgh.4 for ; Mon, 03 Feb 2014 22:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9z9t+Mv8r577yIyLjAWoeNTKSO0A88CrjiE6utS/9mA=; b=1EyPCbojJHkzLVM3MsvwFaLCaEdXK1OjM4XtmKK5g6TDiAb4RArChHESTp5EHVqE5D wbvLfftJGLxmozPeBHRgoCq5LYZJePTMvYJZ6l/36t9b6jGiTr4gMs3Nz/GOLGcl5H/1 FuZXzNqQ4FmGQSGfv6c3IEuZbjTdgCj02Bg5LP0iFSuCI3nbRayKLi1BDHup4MskEnIx rb+z0BqzONghyH2B/iIV6dOHzDa+dMyrMlDLvD/9zkLixCFABZgr12KkZc4pq/VNUS+V s7+xvwP+sYHng+12p80/MjwJjHahjBk9evZH5Gtf++efT0EwWtdwATFng2fWlVRa4r2+ 33DQ== MIME-Version: 1.0 X-Received: by 10.194.119.168 with SMTP id kv8mr457859wjb.41.1391494383103; Mon, 03 Feb 2014 22:13:03 -0800 (PST) Received: by 10.180.90.132 with HTTP; Mon, 3 Feb 2014 22:13:02 -0800 (PST) In-Reply-To: <01P3X2CJ52RA0000CD@mauve.mrochek.com> References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> Date: Mon, 3 Feb 2014 22:13:02 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e01176b1d69736404f18e8825 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 06:13:05 -0000 --089e01176b1d69736404f18e8825 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 3, 2014 at 9:06 AM, Ned Freed wrote: > And finally, we have to take the least astonishment principle into > account. For > whatever reason some sites obsess over the predictability of message retry > intervals: Any time they see what they regard as unusual behavior in this > regard, they get very excited and demand an analysis be done. Our support > people then have to waste time digging in to what invariably turns out to > be > have a perfectly reasonable explanation: a queue backlog, an unresponsive > destination, bad configuration setting, etc. etc. > So is it your view that undertaking standardization work here would help you with this pain point (predictable retries), or make it worse (something new for everyone to understand)? If you can't tell, I'm fishing for some answers to the predictable "Should APPSAWG consider taking on this work?" question. -MSK --089e01176b1d69736404f18e8825 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 3, 2014 at 9:06 AM, Ned Freed <ned.freed@= mrochek.com> wrote:
And finally, we have to take the least aston= ishment principle into account. For
whatever reason some sites obsess over the predictability of message retry<= br> intervals: Any time they see what they regard as unusual behavior in this regard, they get very excited and demand an analysis be done. Our support people then have to waste time digging in to what invariably turns out to b= e
have a perfectly reasonable explanation: a queue backlog, an unresponsive destination, bad configuration setting, etc. etc.

=
So is it your view that undertaking standardization work here wo= uld help you with this pain point (predictable retries), or make it worse (= something new for everyone to understand)?

If you can't tell, I'm fishing for some answers to t= he predictable "Should APPSAWG consider taking on this work?" que= stion.

-MSK
--089e01176b1d69736404f18e8825-- From ned.freed@mrochek.com Tue Feb 4 09:42:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B521E1A00EC for ; Tue, 4 Feb 2014 09:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x26zdx_WJdwZ for ; Tue, 4 Feb 2014 09:42:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38F1A0158 for ; Tue, 4 Feb 2014 09:42:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3YD9ZXTMO004ATN@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 4 Feb 2014 09:37:28 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3YALJ2S7K0000CD@mauve.mrochek.com>; Tue, 4 Feb 2014 09:37:25 -0800 (PST) Message-id: <01P3YD9Y1GLK0000CD@mauve.mrochek.com> Date: Tue, 04 Feb 2014 09:28:51 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 03 Feb 2014 22:13:02 -0800" References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 17:42:32 -0000 > On Mon, Feb 3, 2014 at 9:06 AM, Ned Freed wrote: > > And finally, we have to take the least astonishment principle into > > account. For > > whatever reason some sites obsess over the predictability of message retry > > intervals: Any time they see what they regard as unusual behavior in this > > regard, they get very excited and demand an analysis be done. Our support > > people then have to waste time digging in to what invariably turns out to > > be > > have a perfectly reasonable explanation: a queue backlog, an unresponsive > > destination, bad configuration setting, etc. etc. > > > So is it your view that undertaking standardization work here would help > you with this pain point (predictable retries), or make it worse (something > new for everyone to understand)? My point was that respecting retry values intrduces yet another variable that support will have to deal with. I don't think this is an argument for or against standardization, however. The overarching goal of improving timely delivery of mail trumps the cost of dealing with the obsessions some sites have. IMO this protocol needs to be assessed almost entirely on the basis of whether or not it improves the situation surrounding greylisting. > If you can't tell, I'm fishing for some answers to the predictable "Should > APPSAWG consider taking on this work?" question. I think taking it on is a good idea. Whether or not it turns into a standard depends on how the discussion goes. And while I agree that our time is valuable and should not be wasted, I'm not sure I'd go as far as to say that WGs should only ever take on work when the production of a standard at the end is practically guaranteed. Sometimes crippling problems only emerge after close scrutiny. Mind you, email is sufficiently mature and we have sufficient experience with greylisting that such an outcome is unlikely here. But we've been surprised before. Ned From superuser@gmail.com Tue Feb 4 11:30:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AC11A01BE for ; Tue, 4 Feb 2014 11:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMoJnv8eKKX5 for ; Tue, 4 Feb 2014 11:30:33 -0800 (PST) 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 CA53E1A0167 for ; Tue, 4 Feb 2014 11:30:32 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id x55so4700666wes.32 for ; Tue, 04 Feb 2014 11:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=19kijzNNexVXH3OKJMJatMPpf/vfzGo5OSyzi9HOIMo=; b=Q6WjVwnMu75azmcMVdiVuG3rDIcxRSkQoE8asWGFAZeQJ8DZfWWak+4HQeFJ/Brucf 9D6WdoIC2jyIBVl6taSWzBjUVw0E4KiNc3wi+UCatLTfINWv5dM2T8Uhx3H3LhZpDQZo B/Q1aIMKiIQKx11pTgipZdhz0KpZFgMjlCLAlbtp+H5/bANEprSmFIWDlwuYHVYJl1aC YFwbZcbTtFZNXtj6gwWGitMIw0gL1NmdKa+HUMzPlFxQiMd/L1kKrwtG/EUzlVHrD2Gs bySnhv3mtlPI9vJLJ3OgZMMEV8lBjgcsh++Ud7y24edkafDnjYUB9Yzm2WzTt77SgGg3 o5+g== MIME-Version: 1.0 X-Received: by 10.180.35.36 with SMTP id e4mr13873830wij.8.1391542231909; Tue, 04 Feb 2014 11:30:31 -0800 (PST) Received: by 10.180.90.132 with HTTP; Tue, 4 Feb 2014 11:30:31 -0800 (PST) In-Reply-To: <01P3YD9Y1GLK0000CD@mauve.mrochek.com> References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> Date: Tue, 4 Feb 2014 11:30:31 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=e89a8f64352e6c4f2c04f199ac5a Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 19:30:35 -0000 --e89a8f64352e6c4f2c04f199ac5a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 9:28 AM, Ned Freed wrote: > > And while I agree that our time is valuable and should not be wasted, I'm > not > sure I'd go as far as to say that WGs should only ever take on work when > the > production of a standard at the end is practically guaranteed. Sometimes > crippling problems only emerge after close scrutiny. Mind you, email > is sufficiently mature and we have sufficient experience with greylisting > that such an outcome is unlikely here. But we've been surprised before. > My concern is more that we've taken on work in which interest has petered out leaving us with nearly dead documents. One way to avoid doing that is to favor taking on work that addresses a real pain point for more than just a couple of people, and for which we can find people dedicated to seeing the work through to completion, and for which there is ample support (e.g., implementations, for something on the standards track). I believe something lacking that kind of support should really be looking at the ISE or AD sponsorship rather than APPSAWG. -MSK --e89a8f64352e6c4f2c04f199ac5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2014 at 9:28 AM, Ned Freed <ned.freed@= mrochek.com> wrote:

And while I agree that our time is valuable and should not be wasted, I'= ;m not
sure I'd go as far as to say that WGs should only ever take on work whe= n the
production of a standard at the end is practically guaranteed. Sometimes crippling problems only emerge after close scrutiny. Mind you, email
is sufficiently mature and we have sufficient experience with greylisting that such an outcome is unlikely here. But we've been surprised before.=

My concern i= s more that we've taken on work in which interest has petered out leavi= ng us with nearly dead documents.=A0 One way to avoid doing that is to favo= r taking on work that addresses a real pain point for more than just a coup= le of people, and for which we can find people dedicated to seeing the work= through to completion, and for which there is ample support (e.g., impleme= ntations, for something on the standards track).=A0 I believe something lac= king that kind of support should really be looking at the ISE or AD sponsor= ship rather than APPSAWG.

-MSK
--e89a8f64352e6c4f2c04f199ac5a-- From johnl@iecc.com Tue Feb 4 11:33:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E361A0127 for ; Tue, 4 Feb 2014 11:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qPIzFmkAb-e for ; Tue, 4 Feb 2014 11:33:38 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 205CA1A0035 for ; Tue, 4 Feb 2014 11:33:37 -0800 (PST) Received: (qmail 5434 invoked from network); 4 Feb 2014 19:33:35 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Feb 2014 19:33:35 -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; s=52f1408f.xn--9vv.k1402; i=johnl@user.iecc.com; bh=dUuzOvi5sXMO+IAPnX9C3K25JeTcxcnY4EgytK54Xx8=; b=rAGb9BF3w15JH6A2c6dpo9RA/HZpWGzrlmTWbMv5FK7P5HYR5/tdwnYzXsjbEXJuq3cGSesTILnZY2cl8FvAUrm+TZQLRGuOtoRSoQcCPoj1MWQjuU3yRTObCe52t/DvKu4XXvvP8ZxH4XJL7H6PPdQ1ysfTRU0MdEbxv54dhUjZJYLyfTI8gntYqSxxnAwKUgfqgksnNQSDw6bYlhDCvcFtvPD4KCYtYq0ogW1U5H4d+ZogUgRncoTKgEAqJeYY 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; s=52f1408f.xn--9vv.k1402; bh=dUuzOvi5sXMO+IAPnX9C3K25JeTcxcnY4EgytK54Xx8=; b=c1SoWUMPSow9Ozeky9ZV8AGf1v9E2VAK+rw/Br3JQRJCJdNyxvDuhCUtZx/v2racnmK0/lJgU1mfMLUnXAGbHIzmlZgzFkBDZlz50URoZuxivutcaLkpaaFqqSTtRwqmX+hebqAx+kWZ5dCUeER7PQRS78TSVEXRs4X00/igOW+7BuR65tbfgnoEiPbUdDYaND3It/eRh2CVHkUUzvuZupVjtlLxkf0S1umUJ5kel5JhtTGMgURNAy/LZlLNfzK6 Date: 4 Feb 2014 19:33:12 -0000 Message-ID: <20140204193312.56742.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01P3YD9Y1GLK0000CD@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 19:33:39 -0000 >I don't think this is an argument for or against standardization, however. The >overarching goal of improving timely delivery of mail trumps the cost of >dealing with the obsessions some sites have. IMO this protocol needs to be >assessed almost entirely on the basis of whether or not it improves the >situation surrounding greylisting. In my experience, the amount of real mail that is delayed at all by a reasonable greylister is insignificant. Once you know that an IP has successfully retried, there's no point in further greylisting, so you add it to the greylist whitelist (pale grey list?) This means that the only non-bot mail that gets greylisted is the first one or two from an IP that hasn't sent mail before, and that just isn't very many IPs or very much mail. It's certainly not worth a new SMTP extension and extra state in mail servers. I realize there are extreme greylisters that greylist everything on the theory that a mail server might be sharing its IP with a bot, or if they wait long enough the sender will show up on a blacklist, or something. That's certainly not a basis to standardize anything. R's, John From hsantos@isdg.net Tue Feb 4 12:45:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20C41A010F for ; Tue, 4 Feb 2014 12:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TiMl8Ye1r98 for ; Tue, 4 Feb 2014 12:45:05 -0800 (PST) Received: from ntbbs.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A02E21A01A6 for ; Tue, 4 Feb 2014 12:45:01 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4599; t=1391546690; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1JlReUnMGpoago0o+dTfzMCuO/0=; b=V61jY4yrEqla7oEWTfmc r9N3KoBnUgNb1jSY0eXxjjHKDv7Ylfq53SaeuGKcByoe+IpXTJjQZFcmTH6tCB3l VSsN1oOnsAa0R4bRjIj+gqO0JTF3B9kftPxxZ2IgWnErNS9YLYraK5zeofxhmyzk MS3yNgih51VLgABguRs+fiA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 04 Feb 2014 15:44:50 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 829172278.11693.1980; Tue, 04 Feb 2014 15:44:50 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4599; t=1391546090; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VucTxnr InKtS9Wkpus4Vt9JdNyUDsGqI+7xzrZoJJjg=; b=AOesYAvbqa6YWzwA6VRAq4G d7MhvCtMfY+Kja9OICzNVwPzH+jlIsyzUj8MZDYnvLW7Lth1NfM1ObG3CcQL2MIG RSnmOgt1W9OfmlipMdSesK1ZiAgGndjUNMg+BY2PUNXVKs25FZBXj82N0EML1eqJ eVAKm2mW4ejDrDuZ/iq4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 04 Feb 2014 15:34:50 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 275469256.9.9644; Tue, 04 Feb 2014 15:34:49 -0500 Message-ID: <52F15142.3080009@isdg.net> Date: Tue, 04 Feb 2014 15:44:50 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140204193312.56742.qmail@joyce.lan> In-Reply-To: <20140204193312.56742.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 20:45:10 -0000 On 2/4/2014 2:33 PM, John Levine wrote: >> I don't think this is an argument for or against standardization, however. The >> overarching goal of improving timely delivery of mail trumps the cost of >> dealing with the obsessions some sites have. IMO this protocol needs to be >> assessed almost entirely on the basis of whether or not it improves the >> situation surrounding greylisting. > > In my experience, the amount of real mail that is delayed at all by a > reasonable greylister is insignificant. This spec only attempts to document the basic framework of greylisting based on [HARRIS] and also offers a method to minimize GLS (GreyListing Server) forced client mail delivery delays. > Once you know that an IP has successfully retried, there's no point in > further greylisting, so you add it to the greylist whitelist (pale > grey list?) It might be good if the growing amount GLS out there would permanently IP whitelist the sender from future unnecessary GL based delays. However, this is not generally the case. SMTPGREY includes a concept of an expiration period which was part the original 2003 [HARRIS] greylisting specification where most systems, if not all, were based on. So its more of a temporary whitelisting concept. Your suggestion would be this make this a permanent whitelist. I think this would be local level policy idea for GL implementators to offer to operators -- make it optional. GL can help feed into these additional automated white listing intelligence. Perhaps also couple it with a DKIM signature requirement before it can get pass a greylist requirement. I think these considerations could be part of an appendix, but not the basic protocol. I will venture that most systems that have implemented Greylisting has done so with plug and play fashion, using best establish values for blocking and expiring. There is much experiences in these values and the values have worked out of the box. Operators don't usually adjust the defaults. But if they have, that would be something to learn about. > This means that the only non-bot mail that gets > greylisted is the first one or two from an IP that hasn't sent mail > before, and that just isn't very many IPs or very much mail. It's > certainly not worth a new SMTP extension and extra state in mail > servers. None of this is a problem -- it is an optimization to minimize mail delivery delays that is increasingly caused my GL servers. With bulk transmissions, there are more IP congestion/load limits and following retry hints has helped remove some of the randomness in retry/bulk mail delivery delays. Its not a problem because retry/bulk strategies are necessary w/o greylisting. SMTPGREY addresses a certain portion of the temporary rejection spectrum that do cause mail delivery delays by design. The mail will get out eventually, maybe after 3-5 wasted attempts over long extended mins, even hours. SMTPGREY has proven to show to cut all waste to the bare minimum, which can be an extra retry at the lowest possible time offered by the server. Keep in mind NULLMX proposal is not a problem and we about to take on this work as a standard. In fact, if NULLMX, why not SMTPGREY while we are in a SMTP CHANGE mode mindset. One suggest a successful MX lookup with PREFERENCE=0 as a means to remove a queued item from the outbound queue and immediately activate a bounce process. The other suggest a RETRY HINT from the temporary rejection GL server as a way to override the next delivery attempt time with a shared client/server handshake time value. Both are good ideas to do help improve with mail delivery and queuing strategies. > I realize there are extreme greylisters that greylist everything on > the theory that a mail server might be sharing its IP with a bot, or > if they wait long enough the sender will show up on a blacklist, or > something. That's certainly not a basis to standardize anything. This proposal attempts to not deal with the poor implementations of greylisting. It uses [HARRIS] as the original method most GL systems are based on to document the basic framework and its options available. SMTPGREY deals with what exist in the market place - a higher degree of hitting HARRIS-like GL servers with temporary rejections and many of the different GL servers already provide a Retry Hint which client can leverage. -- HLS [HARRIS] Harris, E., "The Next Step in the Spam Control War: Greylisting", 2003, . From superuser@gmail.com Tue Feb 4 13:59:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278141A012C for ; Tue, 4 Feb 2014 13:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpKxlbVhRHL9 for ; Tue, 4 Feb 2014 13:59:18 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3D91F1A0167 for ; Tue, 4 Feb 2014 13:59:18 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so8511wiw.15 for ; Tue, 04 Feb 2014 13:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=edhJ6zm1pqtJwjtltnbmDLZSYtJc6mBoyQmOonou5Vw=; b=I8JURWIXkbvFaFHnpNRoIwmKB203wcYM3MS2VZ3qrsJY/knVKnpLqdBP4anCeeZk3J L+KtTndb7puSD+Th3UUHVWG1U1WV/GTGW6HRHjMqGRyOC5lSWcnlo0rmT33fzLtQZYOC tM8no1LfJL+K0XSMId2DYFsEOH9imQzfD5xxi59NbuFb5WH9ZFFQYqzR/y4E7en0rWkT GtGsUwWTSVErWDSRnR1AcEGsk1FLuVXPy8LADDKjm/Unu8KBgIbXSth4DjdFwSPFKHi7 d9j3bwLgZteJWUqKMf+YPufJ3ZG+h/DfFwqvO8el576Y203bZ1aLZ/lxM8np7sqwwkDp G0mA== MIME-Version: 1.0 X-Received: by 10.180.12.233 with SMTP id b9mr1932277wic.8.1391551157079; Tue, 04 Feb 2014 13:59:17 -0800 (PST) Received: by 10.180.90.132 with HTTP; Tue, 4 Feb 2014 13:59:16 -0800 (PST) In-Reply-To: <52F15142.3080009@isdg.net> References: <20140204193312.56742.qmail@joyce.lan> <52F15142.3080009@isdg.net> Date: Tue, 4 Feb 2014 13:59:16 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c241146798c004f19bc05c Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2014 21:59:23 -0000 --001a11c241146798c004f19bc05c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 12:44 PM, Hector Santos wrote: > Keep in mind NULLMX proposal is not a problem and we about to take on this > work as a standard. In fact, if NULLMX, why not SMTPGREY while we are in a > SMTP CHANGE mode mindset. > > Two points on this: (1) The issue is not the current mode (or mood) of the working group, but rather (a) whether there's room in the WG for this new work (currently there is not) and (b) whether there is adequate support for accepting and working on it. The nullmx draft is still in an open call for adoption, although so far there clearly appears to be support for working on it in appsawg. (2) It's not necessary for this document to be in a "done" state or close to it to be adopted. It might need a lot of work, but it only needs to be a good starting point for what the WG will ultimately produce via the usual consensus process. -MSK --001a11c241146798c004f19bc05c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2014 at 12:44 PM, Hector Santos <hsantos@= isdg.net> wrote:
Keep in mind NULLMX proposal is not a proble= m and we about to take on this work as a standard. =A0In fact, if NULLMX, w= hy not SMTPGREY while we are in a SMTP CHANGE mode mindset.


Two points on this:

= (1) The issue is not the current mode (or mood) of the working group, but r= ather (a) whether there's room in the WG for this new work (currently t= here is not) and (b) whether there is adequate support for accepting and wo= rking on it.=A0 The nullmx draft is still in an open call for adoption, alt= hough so far there clearly appears to be support for working on it in appsa= wg.=A0

(2) It's not necessary for this document to be in a "done"= ; state or close to it to be adopted.=A0 It might need a lot of work, but i= t only needs to be a good starting point for what the WG will ultimately pr= oduce via the usual consensus process.

-MSK
--001a11c241146798c004f19bc05c-- From ned.freed@mrochek.com Tue Feb 4 18:14:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5461A0190 for ; Tue, 4 Feb 2014 18:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGXcLNXMXP_e for ; Tue, 4 Feb 2014 18:14:10 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6591A0196 for ; Tue, 4 Feb 2014 18:14:10 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3YV5CFVR40047KQ@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 4 Feb 2014 18:09:07 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3YUMQUL3K0000CD@mauve.mrochek.com>; Tue, 4 Feb 2014 18:09:03 -0800 (PST) Message-id: <01P3YV59Z9R80000CD@mauve.mrochek.com> Date: Tue, 04 Feb 2014 18:02:33 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 04 Feb 2014 11:30:31 -0800" References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 02:14:13 -0000 > On Tue, Feb 4, 2014 at 9:28 AM, Ned Freed wrote: > > > > And while I agree that our time is valuable and should not be wasted, I'm > > not > > sure I'd go as far as to say that WGs should only ever take on work when > > the > > production of a standard at the end is practically guaranteed. Sometimes > > crippling problems only emerge after close scrutiny. Mind you, email > > is sufficiently mature and we have sufficient experience with greylisting > > that such an outcome is unlikely here. But we've been surprised before. > > > My concern is more that we've taken on work in which interest has petered > out leaving us with nearly dead documents. One way to avoid doing that is > to favor taking on work that addresses a real pain point for more than just > a couple of people, and for which we can find people dedicated to seeing > the work through to completion, and for which there is ample support (e.g., > implementations, for something on the standards track). I believe > something lacking that kind of support should really be looking at the ISE > or AD sponsorship rather than APPSAWG. I think we may have somewhat different standards for what constitutes sufficient interest. I checked and there appear to be six active documents at present, and every one of them has been at least 5 times since it was initially posted. (Yes, there's a -00 and a -01 in the mix, but this fails to count the versions that came out before the document was adopted by the WG. I categorically reject the notion that attention paid prior to WG adoption, possibly on some other list, doesn't count.) As far as I'm concerned these numbers make a prima facie case for sufficient interest. That said, opinions appear to be mixed about the likely utility of this draft. But I've said my piece; time for others to weigh in. Ned From superuser@gmail.com Tue Feb 4 18:28:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDCD1A0196 for ; Tue, 4 Feb 2014 18:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO7KrtTGpzQk for ; Tue, 4 Feb 2014 18:28:35 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB271A0190 for ; Tue, 4 Feb 2014 18:28:35 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so117260wib.13 for ; Tue, 04 Feb 2014 18:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VDdZzfWL/zS3Nkq3ILwDKz7RCTZ7PJq0+E+EPvx57k4=; b=rysTvHftc+7UQXbqrPViGcdM0EyL2Us23u1Zc/NP0iWHHi/NbFqjlAIvoEvW/Avcf8 ZXJXjrIyhXssThoi7V0KEcs6TSzUjmobyvPGoGEuiMsft6+kCvuHPhDhW8CYcbng+xT0 2GgA6hYJzMfOnOjG3LO2LmbAuMqLiQcY8MFd6oNL80PhmbXlqd5uj4bgQ5xaG8OJLmU0 bgmEVXto0D1HpQDhQgI9wLlWEbEKqyFexZS7z3nExXOI7KjUCkRNzovxdQjTf94rPpRB 2IqE0jamlyjaGiRTEpT3I5Yb4EnKYAhENHe0w1TPNG6psJgasCLHl5VEjjpIPGkHUFnO Etkw== MIME-Version: 1.0 X-Received: by 10.180.12.233 with SMTP id b9mr2507935wic.8.1391567314469; Tue, 04 Feb 2014 18:28:34 -0800 (PST) Received: by 10.180.90.132 with HTTP; Tue, 4 Feb 2014 18:28:34 -0800 (PST) In-Reply-To: <01P3YV59Z9R80000CD@mauve.mrochek.com> References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> <01P3YV59Z9R80000CD@mauve.mrochek.com> Date: Tue, 4 Feb 2014 18:28:34 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=001a11c2411475ca8304f19f8318 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 02:28:37 -0000 --001a11c2411475ca8304f19f8318 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 6:02 PM, Ned Freed wrote: > > I think we may have somewhat different standards for what constitutes > sufficient interest. I checked and there appear to be six active documents > at > present, and every one of them has been at least 5 times since it was > initially > posted. (Yes, there's a -00 and a -01 in the mix, but this fails to count > the > versions that came out before the document was adopted by the WG. I > categorically reject the notion that attention paid prior to WG adoption, > possibly on some other list, doesn't count.) As far as I'm concerned these > numbers make a prima facie case for sufficient interest. > > That said, opinions appear to be mixed about the likely utility of this > draft. > But I've said my piece; time for others to weigh in. > Those aren't the only metrics in play here. Attention on other lists is wonderful, but a WGLC that draws not even a simple "Looks good, let's go" from a single person on any list doesn't exactly make us feel comfortable with the notion that it's ready to go to the IESG or that we could demonstrate WG consensus behind the current content if asked. There could be fifty versions that demonstrate ample past work and interest on this or some other list, but that doesn't automatically imply this WG (the one processing it, after all) is happy with it in its current form. This is especially true if there's current unanswered feedback from someone posted to the list, or if an author said "You're right, I'll put that in the next version" but that hasn't appeared. Of course, this begs the question of how those documents became WG items in the first place, an issue we aim to address with the current "mini-charter" experiment. Anything short of requiring some or all of the above, and we're essentially just an abject end-run around AD sponsorship, which seems utterly bogus to me. So: Are we wrong to have such criteria? -MSK --001a11c2411475ca8304f19f8318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2014 at 6:02 PM, Ned Freed <ned.freed@= mrochek.com> wrote:

I think we may have somewhat different standards for what const= itutes
sufficient interest. I checked and there appear to be six active documents = at
present, and every one of them has been at least 5 times since it was initi= ally
posted. (Yes, there's a -00 and a -01 in the mix, but this fails to cou= nt the
versions that came out before the document was adopted by the WG. I
categorically reject the notion that attention paid prior to WG adoption, possibly on some other list, doesn't count.) As far as I'm concerne= d these
numbers make a prima facie case for sufficient interest.

That said, opinions appear to be mixed about the likely utility of this dra= ft.
But I've said my piece; time for others to weigh in.

Those aren&#= 39;t the only metrics in play here.

Attention on other li= sts is wonderful, but a WGLC that draws not even a simple "Looks good,= let's go" from a single person on any list doesn't exactly ma= ke us feel comfortable with the notion that it's ready to go to the IES= G or that we could demonstrate WG consensus behind the current content if a= sked.=A0 There could be fifty versions that demonstrate ample past work and= interest on this or some other list, but that doesn't automatically im= ply this WG (the one processing it, after all) is happy with it in its curr= ent form.=A0 This is especially true if there's current unanswered feed= back from someone posted to the list, or if an author said "You're= right, I'll put that in the next version" but that hasn't app= eared.=A0 Of course, this begs the question of how those documents became W= G items in the first place, an issue we aim to address with the current &qu= ot;mini-charter" experiment.

Anything short of requiring some or all of the above, and we= 're essentially just an abject end-run around AD sponsorship, which see= ms utterly bogus to me.

So: Are we wrong to have such cri= teria?

-MSK
--001a11c2411475ca8304f19f8318-- From ned.freed@mrochek.com Tue Feb 4 19:39:52 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174621A001B for ; Tue, 4 Feb 2014 19:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_mTC0JzfEhL for ; Tue, 4 Feb 2014 19:39:50 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3F71A0019 for ; Tue, 4 Feb 2014 19:39:50 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3YY5IXXFK004CI3@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 4 Feb 2014 19:34:47 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3YUMQUL3K0000CD@mauve.mrochek.com>; Tue, 4 Feb 2014 19:34:43 -0800 (PST) Message-id: <01P3YY5H1I9I0000CD@mauve.mrochek.com> Date: Tue, 04 Feb 2014 18:40:21 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 04 Feb 2014 18:28:34 -0800" References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> <01P3YV59Z9R80000CD@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 03:39:52 -0000 > On Tue, Feb 4, 2014 at 6:02 PM, Ned Freed wrote: > > I think we may have somewhat different standards for what constitutes > > sufficient interest. I checked and there appear to be six active documents > > at > > present, and every one of them has been at least 5 times since it was > > initially > > posted. (Yes, there's a -00 and a -01 in the mix, but this fails to count > > the > > versions that came out before the document was adopted by the WG. I > > categorically reject the notion that attention paid prior to WG adoption, > > possibly on some other list, doesn't count.) As far as I'm concerned these > > numbers make a prima facie case for sufficient interest. > Those aren't the only metrics in play here. > Attention on other lists is wonderful, but a WGLC that draws not even a > simple "Looks good, let's go" from a single person on any list doesn't > exactly make us feel comfortable with the notion that it's ready to go to > the IESG or that we could demonstrate WG consensus behind the current > content if asked. Sorry, I don't buy this _at_ _all_. If a document has seen extensive discussion somewhere else, isn't it just faintly possible that it's in good shape and people don't see the need for further commentary? (Mind you, I'm not saying that this applies to the entire current crop of documents. I'm talking about general criteria here.) IETF management also appears to be more than a little confused about what's needed or wanted here. It wasn't too long ago that Pete Resnick got all hot and bothered about "empty expressions of support" on this very list - from me in particular - even going so far as to say that he simply ignores such things and at least implying that he expects others to do so as well. Yet that's exactly what you're asking people to provide here. I can't speak for anyone else, but I was told that such things would be ignored I basically stopped posting all straightforward expressions of support of drafts nearing or during last call. So if you were expecting me to post a "seems OK" comment about, say, draft-ietf-appsawg-xml-mediatypes - and yes, I have read it carefully and have nothing further to say about it - sorry, that wasn't about to happen. > There could be fifty versions that demonstrate ample > past work and interest on this or some other list, but that doesn't > automatically imply this WG (the one processing it, after all) is happy > with it in its current form. I'd buy this argument with most WGs, which are chartered for a specific purpose and goal. In such contexts it's important that all of the drafts that receive WG blessing have a certain degree of self-consistency. But this is the Apps Area WG, which is chartered to process stuff that doesn't quite fit anywhere else and which doesn't merit a WG of its own. And sure enough, if we look at the current set of active drafts, we have one on URI design principles, one on XML media types, one defining an XML patch format, one defining a JSON patch format, one defining the form data format, and one defining a Sieve extension. And soon to be a draft about MX record handling and perhaps one on greylisting. If there's a theme there other than "random apps stuff" I'm not seeing it. I therefore see the notion that there's a common WG understanding acting as a gating factor for inchoate collection as nothing short of absurd. > This is especially true if there's current > unanswered feedback from someone posted to the list, or if an author said > "You're right, I'll put that in the next version" but that hasn't > appeared. What does this have to do with the topic at hand? A document that's "waiting for revision" is obviously not ready to go. And incidentally, has clearly seen some review by the WG... > Of course, this begs the question of how those documents became > WG items in the first place, an issue we aim to address with the current > "mini-charter" experiment. > Anything short of requiring some or all of the above, and we're essentially > just an abject end-run around AD sponsorship, which seems utterly bogus to > me. Sorry, this sort of stuff never really resonated with me when I was an AD, and it means absolutely nothing to me now. All I care about is getting work done; just provide me with a reasonable and consistent process and a little guidance for how to operate it and I could not care less about the details. Tell me to use a special WG and that's what I'll do, tell me to spin up a mini-WG, that's fine too, tell me I need to seek AD sponsorship, then that's what I'll ask for. > So: Are we wrong to have such criteria? Given the situation as it stands, yes, you absolutely are. More generally, IETF management has provided what are effectively contradictory guidelines for what's expected from participants, and is now reaping what it sowed. My sympathy level is low. Ned From superuser@gmail.com Tue Feb 4 21:07:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A7E1A002D for ; Tue, 4 Feb 2014 21:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSau0iu2B9aX for ; Tue, 4 Feb 2014 21:07:28 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 57C551A0029 for ; Tue, 4 Feb 2014 21:07:28 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id x13so13954979wgg.9 for ; Tue, 04 Feb 2014 21:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T+NIgudtUEcUyqWnD3V11WzIUf/foxzsBF0ZtRz+u1A=; b=QbJDTBv47z7HxJBM3XmxDhm5sOd58Qx99gcxDn8OrzH6Yo9mi0lJp549se/CYgg53J n/kHnmFrSzTul/MozN33sY5nb4Pe99PJpUF2qHUnAY0Xs3oggIw/IgV94234WVuoOL3z ZqWMVbgLibxtUFPa5D1MqGE9FnUwE3K6xY+WVqud11GQx10Nceo98PuFAgQCcUMQyvpH kePNm4BJaB0JI6NgIG1yvhFycbh9YjkME8y6Lam4HdcN8YTMepIeOSd6RRqKITuaTypH gB+45WA+LrK8h6abVo7z3vyL2PZOe41xz+DEjB9aFUUTFwIhV/cMnRfetPfXfrWSeLHH zfOg== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr15223695wib.5.1391576847171; Tue, 04 Feb 2014 21:07:27 -0800 (PST) Received: by 10.180.90.132 with HTTP; Tue, 4 Feb 2014 21:07:26 -0800 (PST) In-Reply-To: <01P3YY5H1I9I0000CD@mauve.mrochek.com> References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> <01P3YV59Z9R80000CD@mauve.mrochek.com> <01P3YY5H1I9I0000CD@mauve.mrochek.com> Date: Tue, 4 Feb 2014 21:07:26 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=00248c0d7938a74cbf04f1a1bb05 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 05:07:30 -0000 --00248c0d7938a74cbf04f1a1bb05 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 6:40 PM, Ned Freed wrote: > > Attention on other lists is wonderful, but a WGLC that draws not even a > > simple "Looks good, let's go" from a single person on any list doesn't > > exactly make us feel comfortable with the notion that it's ready to go to > > the IESG or that we could demonstrate WG consensus behind the current > > content if asked. > > Sorry, I don't buy this _at_ _all_. If a document has seen extensive > discussion > somewhere else, isn't it just faintly possible that it's in good shape and > people don't see the need for further commentary? (Mind you, I'm not saying > that this applies to the entire current crop of documents. I'm talking > about > general criteria here.) > Sure, it's faintly possible. But I also think it's ambiguous when there's not an iota of feedback after a new version is posted even if only to confirm that all previous raised issues have been addressed. I think it's telling if an entire WG can't even be arsed to write two or three words doing that or expressing any kind of support whatsoever for the progress of a document. I certainly don't feel comfortable handing such a thing to the IESG claiming "this has consensus" in those conditions. If we have this completely wrong and the ADs want to correct us, fine. But this is where my experience with the IETF and other working groups has led me, and I'll be surprised if the guidance is "If nobody says anything when you ask if it's ready, the only logical conclusion is that it's ready." If instead the WG simply can't be bothered, we send it up and it comes back with a stack of DISCUSSes, then what? I am aware of Pete's rants about useless feedback. I'm sympathetic to the idea that "+1" is pretty useless on its own, but I don't think a slightly more detailed reply like "I read the -xx version of this draft, and prior issues A, B, and C were all addressed. I think it's ready." is at all useless. Absent that, why should I as co-chair or shepherd not conclude that those issues are possibly still of concern, especially if it's subject matter with which I'm not familiar? But this is the Apps Area WG, which is chartered to process stuff that > doesn't > quite fit anywhere else and which doesn't merit a WG of its own. And sure > enough, if we look at the current set of active drafts, we have one on URI > design principles, one on XML media types, one defining an XML patch > format, > one defining a JSON patch format, one defining the form data format, and > one > defining a Sieve extension. And soon to be a draft about MX record > handling and > perhaps one on greylisting. > > If there's a theme there other than "random apps stuff" I'm not seeing it. > I > therefore see the notion that there's a common WG understanding acting as a > gating factor for inchoate collection as nothing short of absurd. > Huh? I'm not claiming the current set of documents is inappropriate or out of charter. I'm saying the absence of review and support comments is a problem. The charter lists these bullet points (among others) as criteria for accepting work: * Whether there is a core team of WG participants with sufficient energy and expertise to advance the proposed work item according to the proposed schedule. * Whether there are enough WG participants who are willing to review the work produced by the document authors or editors. It seems to me that your silence-is-golden notion is at odds with those; specifically, I interpret silence as the absence of "sufficient energy" and "willing to review". -MSK --00248c0d7938a74cbf04f1a1bb05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 4, 2014 at 6:40 PM, Ned Freed <ned.freed@= mrochek.com> wrote:
> Attention on other l= ists is wonderful, but a WGLC that draws not even a
> simple "Looks good, let's go" from a single person on an= y list doesn't
> exactly make us feel comfortable with the notion that it's ready t= o go to
> the IESG or that we could demonstrate WG consensus behind the current<= br> > content if asked.

Sorry, I don't buy this _at_ _all_. If a document has seen extens= ive discussion
somewhere else, isn't it just faintly possible that it's in good sh= ape and
people don't see the need for further commentary? (Mind you, I'm no= t saying
that this applies to the entire current crop of documents. I'm talking = about
general criteria here.)

Sure, it's faint= ly possible.=A0 But I also think it's ambiguous when there's not an= iota of feedback after a new version is posted even if only to confirm tha= t all previous raised issues have been addressed.=A0 I think it's telli= ng if an entire WG can't even be arsed to write two or three words doin= g that or expressing any kind of support whatsoever for the progress of a d= ocument.=A0 I certainly don't feel comfortable handing such a thing to = the IESG claiming "this has consensus" in those conditions.

If we have this completely wrong and the ADs want to correct us, = fine.=A0 But this is where my experience with the IETF and other working gr= oups has led me, and I'll be surprised if the guidance is "If nobo= dy says anything when you ask if it's ready, the only logical conclusio= n is that it's ready."=A0 If instead the WG simply can't be bo= thered, we send it up and it comes back with a stack of DISCUSSes, then wha= t?

I am aware = of Pete's rants about useless feedback.=A0 I'm sympathetic to the i= dea that "+1" is pretty useless on its own, but I don't think= a slightly more detailed reply like "I read the -xx version of this d= raft, and prior issues A, B, and C were all addressed.=A0 I think it's = ready." is at all useless.=A0 Absent that, why should I as co-chair or= shepherd not conclude that those issues are possibly still of concern, esp= ecially if it's subject matter with which I'm not familiar?

But this is the Apps Area WG, which is chartered to process stuff that does= n't
quite fit anywhere else and which doesn't merit a WG of its own. And su= re
enough, if we look at the current set of active drafts, we have one on URI<= br> design principles, one on XML media types, one defining an XML patch format= ,
one defining a JSON patch format, one defining the form data format, and on= e
defining a Sieve extension. And soon to be a draft about MX record handling= and
perhaps one on greylisting.

If there's a theme there other than "random apps stuff" I'= ;m not seeing it. I
therefore see the notion that there's a common WG understanding acting = as a
gating factor for inchoate collection as nothing short of absurd.

Huh?=A0 I'm not claiming the current set of = documents is inappropriate or out of charter.=A0 I'm saying the absence= of review and support comments is a problem.

The charter lists these bullet points (among others) as crit= eria for accepting work:

* Whether there is a core team of WG partic= ipants with sufficient energy
and expertise to advance the proposed work item according to the proposed=
schedule.

* Whether there are enough WG participants who are willing to review
the work produced by the document authors or editors.

I= t seems to me that your silence-is-golden notion is at odds with those; spe= cifically, I interpret silence as the absence of "sufficient energy&qu= ot; and "willing to review".

-MSK
--00248c0d7938a74cbf04f1a1bb05-- From Claudio.Allocchio@garr.it Tue Feb 4 23:27:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A521A0056 for ; Tue, 4 Feb 2014 23:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.786 X-Spam-Level: * X-Spam-Status: No, score=1.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_WEIGHT2=2.442, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKhVS8Sr8x2t for ; Tue, 4 Feb 2014 23:27:02 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB8B1A0055 for ; Tue, 4 Feb 2014 23:27:01 -0800 (PST) Received: internal info suppressed Date: Wed, 5 Feb 2014 08:26:58 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Ned Freed In-Reply-To: <01P3YY5H1I9I0000CD@mauve.mrochek.com> Message-ID: References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> <01P3YV59Z9R80000CD@mauve.mrochek.com> <01P3YY5H1I9I0000CD@mauve.mrochek.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1391585218; bh=EojnUoNeA9kdpVPMmyVXpIq5OsGuIlHzIFtltwo3fg8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UFaZMz57yaVWrBopzlIxE4qpbLLzhQkngO2nBeHSXA+3zDcKuudXIURAc/t6lIRBh xuFjfoo0uzCbk9efg+VlhxDBldjue/ApTorWNjiOH03Mfuc6upGI69ImXimbQNdXCT AMP3VyP7xwYsqUIPnAbrW6IGz8ON3OniFSwPlFPc= Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 07:27:04 -0000 Let me add a little detail to the discussion: if you check the statistics of the Apps WG list and see what's proposed on it, you will notice that practially all "SMTP related" stuff ends up here. There is a valid reason for this, whichi is: - there is no (and there is no need for a specific) SMTP updates/maintenance WG in the IETF; - most of the people interested in the topic are actually on Apps WG itself. The real problem is manpower to follow up the drafts after people gives enough +1s to adopt them. As we are chartered quite openly (and this is ok for THIS WG) and of course are a mix of all Apps Area expertises, of course I do not presume that 60% of WG people stand up and work an any specific draft, just because it does not fit their own expertise area: I'd not stand up for an XML draft for actual work, just because I do not feel I'm the righ person to do that for example, but I'll put my +1 on XML drafts I believe are worth... and the expect the XML experts to contribute. Given this personal humble assumption, I'm not saying that we should formally "wheight" the +1s according the people's expertise area, but at least to think about this when we take adotion decisions. Again, the mail problem to face, not only in the specifi Apps WG, is the actual manpower avilable... I've the unpleaseant feeling, also coordinating the AppsDir, that it is decreasing because of various reasons. my little 2 cents... all the best ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From salvatore.loreto@ericsson.com Wed Feb 5 00:08:56 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F16F1A00B5 for ; Wed, 5 Feb 2014 00:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.541 X-Spam-Level: X-Spam-Status: No, score=0.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_WEIGHT2=2.442, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5X-26Ai5P7l for ; Wed, 5 Feb 2014 00:08:55 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 741C21A00A8 for ; Wed, 5 Feb 2014 00:08:54 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-20-52f1f1954535 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 38.0F.04249.591F1F25; Wed, 5 Feb 2014 09:08:53 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.236]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 09:08:52 +0100 From: Salvatore Loreto To: Claudio Allocchio Thread-Topic: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations Thread-Index: AQHPH3ZdZRRkVQ+F70qn4NM3W+ibqJqgoAWAgAAKEYCAAgDTgIAAeeHNgABTv4CAAHIB1YAAphcAgADRbRiAAA1jgIAAgZX0///zOACAACS1IYAALqsAgAALtoA= Date: Wed, 5 Feb 2014 08:08:51 +0000 Message-ID: References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> <01P3YV59Z9R80000CD@mauve.mrochek.com> <01P3YY5H1I9I0000CD@mauve.mrochek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvje7Ujx+DDI6sE7NY/XIFm8XCO5vZ LdavnMbmwOyx9d07Ro8lS34yefybu509gDmKyyYlNSezLLVI3y6BK+Pvm4fsBfeFK75uesve wLiWv4uRg0NCwERi5YrsLkZOIFNM4sK99WxdjFwcQgJHGCVWT97CAuEsZpS4c+IUO0gVm4CZ xPOHW5hBbBEBQ4mz1zazgQxiFgiSaGmqBgkLC2RKzP2+gRWiJEvixrFuRpA5IgJdjBJnfnay gCRYBFQkdq3oBSviFbCXuDV7ASPEsjOsEnff7gUbyingKvFoTghIDSPQdd9PrWECsZkFxCVu PZnPBHG1gMSSPeeZIWxRiZeP/7FC2EoSK7ZfYoSo15FYsPsTG4RtLXFpZSfUHG2JZQtfM0Pc IChxcuYTlgmM4rOQrJiFpH0WkvZZSNpnIWlfwMi6ipGjOLU4KTfdyGATIzDSDm75bbGD8fJf m0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgLJktbc5T9qxh3gYNyZlX z+gdPeamUOTyZ6f6SSGFs5fPb09+rLzJw+M6v1yOp5Uy7/TPEhsjU7SfZ9xMXfKsR/dh2dSy PlWlK4EKW8WDJIMm15xaOj3RTqr+BYemcnLHUi1Pg/veAq1bvgfwCN5VX+dj1v4vKew/e/eC Rbb7vncVv+XjffZeiaU4I9FQi7moOBEAPPUwRYICAAA= Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 08:08:56 -0000 exactly here the issue is to understand how many people are really interest= ed in the issue and especially if the ones interested they can spend enough cycles to revie= w and provide comments so to let the draft progress=20 /Salvatore On Feb 5, 2014, at 9:26 AM, Claudio Allocchio w= rote: >=20 > Let me add a little detail to the discussion: >=20 > if you check the statistics of the Apps WG list and see what's proposed o= n it, you will notice that practially all "SMTP related" stuff ends up here= . There is a valid reason for this, whichi is: >=20 > - there is no (and there is no need for a specific) SMTP updates/maintena= nce WG in the IETF; >=20 > - most of the people interested in the topic are actually on Apps WG itse= lf. >=20 > The real problem is manpower to follow up the drafts after people gives e= nough +1s to adopt them. As we are chartered quite openly (and this is ok f= or THIS WG) and of course are a mix of all Apps Area expertises, of course = I do not presume that 60% of WG people stand up and work an any specific dr= aft, just because it does not fit their own expertise area: I'd not stand u= p for an XML draft for actual work, just because I do not feel I'm the righ= person to do that for example, but I'll put my +1 on XML drafts I believe = are worth... and the expect the XML experts to contribute. Given this perso= nal humble assumption, I'm not saying that we should formally "wheight" the= +1s according the people's expertise area, but at least to think about thi= s when we take adotion decisions. >=20 > Again, the mail problem to face, not only in the specifi Apps WG, is the = actual manpower avilable... I've the unpleaseant feeling, also coordinating= the AppsDir, that it is decreasing because of various reasons. >=20 > my little 2 cents... >=20 > all the best >=20 > -------------------------------------------------------------------------= ----- > Claudio Allocchio G A R R Claudio.Allocchio@ga= rr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=3DClaudio; S=3DAll= occhio; > fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr; = C=3Dit; >=20 > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From hsantos@isdg.net Wed Feb 5 05:41:15 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9131A0145 for ; Wed, 5 Feb 2014 05:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.638 X-Spam-Level: X-Spam-Status: No, score=-98.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_WEIGHT2=2.442, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNEkKdav47Td for ; Wed, 5 Feb 2014 05:41:12 -0800 (PST) Received: from catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AB24E1A012D for ; Wed, 5 Feb 2014 05:41:12 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2633; t=1391607663; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=jX4jzvJOle5on0Qho0qU9hr1KJQ=; b=M4f1T8V9zddUjrSIkAAU uYQf6q1HLgkENfVviG++aocIdcSI4afCnWU6s36bGyvlpXjOadjFuBulUQMv+e7P 6haIb22IRysNTQvR/KC0OWbejKlFX3AwLZzMJQe0kbOX+CzB6A6lm5wx5oCeijR2 fYxkOtyAA+i13yzwNcz2xrQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 05 Feb 2014 08:41:03 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 890143709.12853.2716; Wed, 05 Feb 2014 08:41:02 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2633; t=1391607058; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=V77jdJj cryfZL9mybFnYMHRMFJsj7yCQ4cFxB7/bIE8=; b=Q4ajAQNHQDqcinBWfuD/nJS FXRk0ogg8YwTqGo/K1UiXn7m+82aFO/rWp/Tm8ewi50Lu5Fomj1TtiEsFJZyAV/S nvwJgYobyuOUsRWtjkabAZu65fqz4JegqrZAyWs8qw4Ixb1ihk7MXgnQqoo70oG5 wRamUO4Kw3M2UHWD2a/E= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 05 Feb 2014 08:30:58 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 336437662.9.6804; Wed, 05 Feb 2014 08:30:58 -0500 Message-ID: <52F23F6C.1030308@isdg.net> Date: Wed, 05 Feb 2014 08:41:00 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Salvatore Loreto References: <52ED3452.7040007@isdg.net> <52ED3F4B.6060803@isdg.net> <01P3WDM2RDYG0000CD@mauve.mrochek.com> <52EF99F9.1070908@isdg.net> <01P3X2CJ52RA0000CD@mauve.mrochek.com> <01P3YD9Y1GLK0000CD@mauve.mrochek.com> <01P3YV59Z9R80000CD@mauve.mrochek.com> <01P3YY5H1I9I0000CD@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] draft-santos-smtpgrey-02: SMTP Service Extension for Greylisting Operations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2014 13:41:15 -0000 I see it as a "marketing" problem. On 2/5/2014 3:08 AM, Salvatore Loreto wrote: > exactly here the issue is to understand how many people are really interested in the issue > and especially if the ones interested they can spend enough cycles to review and provide > comments so to let the draft progress > > /Salvatore > > > > On Feb 5, 2014, at 9:26 AM, Claudio Allocchio wrote: > >> >> Let me add a little detail to the discussion: >> >> if you check the statistics of the Apps WG list and see what's proposed on it, you will notice that practially all "SMTP related" stuff ends up here. There is a valid reason for this, whichi is: >> >> - there is no (and there is no need for a specific) SMTP updates/maintenance WG in the IETF; >> >> - most of the people interested in the topic are actually on Apps WG itself. >> >> The real problem is manpower to follow up the drafts after people gives enough +1s to adopt them. As we are chartered quite openly (and this is ok for THIS WG) and of course are a mix of all Apps Area expertises, of course I do not presume that 60% of WG people stand up and work an any specific draft, just because it does not fit their own expertise area: I'd not stand up for an XML draft for actual work, just because I do not feel I'm the righ person to do that for example, but I'll put my +1 on XML drafts I believe are worth... and the expect the XML experts to contribute. Given this personal humble assumption, I'm not saying that we should formally "wheight" the +1s according the people's expertise area, but at least to think about this when we take adotion decisions. >> >> Again, the mail problem to face, not only in the specifi Apps WG, is the actual manpower avilable... I've the unpleaseant feeling, also coordinating the AppsDir, that it is decreasing because of various reasons. >> >> my little 2 cents... >> >> all the best >> >> ------------------------------------------------------------------------------ >> Claudio Allocchio G A R R Claudio.Allocchio@garr.it >> Senior Technical Officer >> tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; >> fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; >> >> PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca >> _______________________________________________ >> 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 > > -- HLS From internet-drafts@ietf.org Thu Feb 6 10:36:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5AC1A0274; Thu, 6 Feb 2014 10:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CUuB7SXo4Rp; Thu, 6 Feb 2014 10:36:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3DE1A0445; Thu, 6 Feb 2014 10:36:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 10:36:42 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 18:36:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : XML Media Types Authors : Henry S. Thompson Chris Lilley Filename : draft-ietf-appsawg-xml-mediatypes-07.txt Pages : 31 Date : 2014-02-06 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-xml-mediatypes-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dret@berkeley.edu Thu Feb 6 13:33:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7DA1A0258 for ; Thu, 6 Feb 2014 13:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTxrR2rXHDG4 for ; Thu, 6 Feb 2014 13:33:48 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id B520A1A0133 for ; Thu, 6 Feb 2014 13:33:47 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] 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 1WBWZt-0002LN-BB for apps-discuss@ietf.org; Thu, 06 Feb 2014 13:33:47 -0800 Message-ID: <52F3FFB7.7020008@berkeley.edu> Date: Thu, 06 Feb 2014 22:33:43 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20140206211518.8522.68306.idtracker@ietfa.amsl.com> In-Reply-To: <20140206211518.8522.68306.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-accept-post-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2014 21:33:50 -0000 biggest change: more implementation reports in the respective section. On 2014-02-06, 22:15 , internet-drafts@ietf.org wrote: > A new version of I-D, draft-wilde-accept-post-02.txt > has been successfully submitted by Erik Wilde and posted to the > IETF repository. > > Name: draft-wilde-accept-post > Revision: 02 > Title: The Accept-Post HTTP Header > Document date: 2014-02-07 > Group: Individual Submission > Pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-wilde-accept-post-02.txt > Status: https://datatracker.ietf.org/doc/draft-wilde-accept-post/ > Htmlized: http://tools.ietf.org/html/draft-wilde-accept-post-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-accept-post-02 > > Abstract: > This specification defines a new HTTP response header field Accept- > Post, which indicates server support for specific media types for > entity bodies in HTTP POST requests. > > Note to Readers > > This draft should be discussed on the apps-discuss mailing list [1]. > > Online access to all versions and files is available on github [2]. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From yangkun2005@gmail.com Thu Feb 6 18:53:05 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93E81A059E for ; Thu, 6 Feb 2014 18:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJwqeFvHQ8R7 for ; Thu, 6 Feb 2014 18:53:05 -0800 (PST) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id E196D1A0237 for ; Thu, 6 Feb 2014 18:53:04 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id i4so3480688oah.41 for ; Thu, 06 Feb 2014 18:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0lN5YX5oFQXLlcU06FlCRuftdnWw1SLzCpcs8v7iPdA=; b=OO8R4kVqH7LVJksBKBtZnWIpDKodNoAvRDUY+UWDeveisXroFTblRwBi2L3vdX7QvJ r6nPAbwsZVnesiZ3yDSHtocLxYnucQponbBiVH3LCwe5TBTc2+i4Wl5QY3KPqansW7O7 0CWCGPK6BxgmGXzzdN0gwm7Lfpk9U26aFOq9/GZTV8ctJmXoX2IEMJMzZIJR+pEurUAL B5x1d2LyXi90GPVsx8BTx9OXLPzpA5q3k1hycEw0JXb5dN0WwHUKmWvieF3xTEPuIoOx b02GUZenR/NCGLmbzhIwjCRqD/hKoAsKn69Q7mAKO6maCTrbyZoIHfZRFEuKnzOhBKnG oGRw== MIME-Version: 1.0 X-Received: by 10.60.70.239 with SMTP id p15mr10219328oeu.26.1391741583574; Thu, 06 Feb 2014 18:53:03 -0800 (PST) Received: by 10.76.85.131 with HTTP; Thu, 6 Feb 2014 18:53:03 -0800 (PST) Date: Fri, 7 Feb 2014 10:53:03 +0800 Message-ID: From: Kun Yang To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a113311e6b54b5704f1c816cb Subject: [apps-discuss] Remove my email. X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 02:53:05 -0000 --001a113311e6b54b5704f1c816cb Content-Type: text/plain; charset=ISO-8859-1 Please remove my email from apps-discuss@ietf.org. I don't receive emails from it any more and I don't know how to do it. Thank you very much. Kun Yang yangkun2005@gmail.com --001a113311e6b54b5704f1c816cb Content-Type: text/html; charset=ISO-8859-1
Please remove my email from apps-discuss@ietf.org. I don't receive emails from it any more and I don't know how to do it.

Thank you very much.

Kun Yang
--001a113311e6b54b5704f1c816cb-- From ht@inf.ed.ac.uk Fri Feb 7 04:14:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256801A1E0E for ; Fri, 7 Feb 2014 04:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7Bn4g4uvpHZ for ; Fri, 7 Feb 2014 04:14:11 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 463DE1A1DFA for ; Fri, 7 Feb 2014 04:14:10 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s17CDsFo002296 for ; Fri, 7 Feb 2014 12:13:59 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s17CDrkC011946 for ; Fri, 7 Feb 2014 12:13:53 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s17CDqu8011767 for ; Fri, 7 Feb 2014 12:13:52 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s17CDqhN011763; Fri, 7 Feb 2014 12:13:52 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org References: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 07 Feb 2014 12:13:52 +0000 In-Reply-To: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Thu\, 06 Feb 2014 10\:36\:42 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 07 Feb 2014 12:14:14 -0000 As usual, a disposition of comments against the previous draft is available at http://www.w3.org/XML/2012/10/3023bis/06-comments.html and an author's diff is at http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-07_diff.html This draft has few changes from version 6, almost all as a result of a review by Larry Masinter, for which thanks. The only change even close to substantive is a summary RECOMMENDATION near the beginning of section 3, Encoding Considerations, which says The use of UTF-8, without a BOM, is RECOMMENDED for all XML MIME entities. See the 06-comments document for a summary of the discussion about this. The level of comments on this draft has shifted from substantive to rhetorical/editorial, and I think it's now pretty much fully-baked. I'd very much welcome some endorsements of its readiness, so that we can move it up and out of here. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From tbray@textuality.com Sat Feb 8 11:46:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59E21A018C for ; Sat, 8 Feb 2014 11:46:04 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsNQ7hdhCPfa for ; Sat, 8 Feb 2014 11:46:01 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD671A00FE for ; Sat, 8 Feb 2014 11:46:01 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id m10so3718985vbh.32 for ; Sat, 08 Feb 2014 11:46:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6q5B4Igt2tVg2wfR/4VioG7lJCsvprTAA2EMQx2Ned4=; b=IXb1h+EMrwKietuH/3qJbgbIv4yuBhI7ubS+6/aHpzn1vzBFzfIW/gVtoje971jsLW c4Qz9COoD5raEmEs5hw6LrW6n5kkHi9R5LacJPAmT6Ro7jzILSe/A7YeUMduOT7WI4F6 pYSDOl+hKpj9KvtQQ+8ULZKl1CLvCDuCqN29qQ3XiLbDkc0YOVcGDKafQHvuxQC3nu3F enpQclLNlDoZV1zHzBtQkFpCijK1YwV0IH+xN0eSQQTOCYPsYqcj9+0BkergV5a4k+5v whDo8VHnwDQG94awo6w5S9ak2RLBgieZcJAgC+hFxhDiayUGuHLIWG1ZVuMsatVHxzC4 U/wg== X-Gm-Message-State: ALoCoQlA8xaQaqCJcfsVdyZnFtKMRpIaF6uQIEc1nlh6HqO32YXyU6GoVSjS2X4xWc2BkXco3yy1 MIME-Version: 1.0 X-Received: by 10.58.37.67 with SMTP id w3mr2271555vej.22.1391888761392; Sat, 08 Feb 2014 11:46:01 -0800 (PST) Received: by 10.220.98.73 with HTTP; Sat, 8 Feb 2014 11:46:01 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> Date: Sat, 8 Feb 2014 11:46:01 -0800 Message-ID: From: Tim Bray To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=089e013a0d4230ab3d04f1ea5b91 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2014 19:46:04 -0000 --089e013a0d4230ab3d04f1ea5b91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Disclosure: This is the first draft of xml-mediatypes I=E2=80=99ve read in = years, so probably is a little lacking in context. 2.2: =E2=80=9C[UNICODE] defines three "encoding forms", which are independe= nt of serialization=E2=80=9D - what does =E2=80=9Cindependent of serialization=E2= =80=9D mean? I think the UTF-* are actually serializations of unicode codepoints. I suppose UTF-16 is sort-of semi-independent of serialization, but UTF-8 never is. 2nd last para of 3.1, beginning =E2=80=9CXML MIME producers are RECOMMENDED= to provide means for XML MIME entity authors to determine what value=E2=80=9D = baffles me. I just read it 3 times and I don=E2=80=99t get it. Could we have an = example or something? I also think I disagree with my guess as what it=E2=80=99s t= rying to say. I tend to think the tools are going to do a better job of figuring out the right charset labeling than your typical document author. The crucial =E2=80=9C this specification sets the priority as follows:=E2= =80=9D indented para in 3.2. I think a little more is needed. The crucial corner case is when you=E2=80=99ve got a MIME-header charset that is just wrong but an XML= -aware receiver can in fact sort things out based on the encoding declaration. What does being =E2=80=9Cauthoritative=E2=80=9D mean concretely? Is it the= RFC=E2=80=99s recommendation that the receiver SHOULD refuse to parse the the XML even though it could? If so, we should say so explicitly. Then in the example in 9.8, draft says =E2=80=9Call processors will treat t= he enclosed entity as iso-8859-1 encoded. That is, the "UTF-8" encoding declaration will be ignored.=E2=80=9D Is this really true in practice? I = suspect not; so perhaps you should say =E2=80=9Call processors which conform to thi= s specification will=E2=80=9D. Hm, or perhaps the real issue is that in this= case, you can=E2=80=99t predict what will happen; some implementations will ignor= e the MIME header, others will drop-kick the XML because of the inconsistency. Section 3.3 typo, =E2=80=9CthatUTF-16=E2=80=9D, space needed, also =E2=80= =9Centitiesnot=E2=80=9D in the same sentence. Also some spacing problems in the NOTE: in 8.1 On Fri, Feb 7, 2014 at 4:13 AM, Henry S. Thompson wrote: > As usual, a disposition of comments against the previous draft is > available at > > http://www.w3.org/XML/2012/10/3023bis/06-comments.html > > and an author's diff is at > > > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-0= 7_diff.html > > This draft has few changes from version 6, almost all as a result of a > review by Larry Masinter, for which thanks. > > The only change even close to substantive is a summary RECOMMENDATION > near the beginning of section 3, Encoding Considerations, which says > > The use of UTF-8, without a BOM, is RECOMMENDED for all XML MIME > entities. > > See the 06-comments document for a summary of the discussion about > this. > > The level of comments on this draft has shifted from substantive to > rhetorical/editorial, and I think it's now pretty much fully-baked. > I'd very much welcome some endorsements of its readiness, so that we > can move it up and out of here. > > ht > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-444= 0 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged > spam] > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e013a0d4230ab3d04f1ea5b91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Disclosure: This is the first draft of xml-mediatypes I=E2= =80=99ve read in years, so probably is a little lacking in context.
2.2: =E2=80=9C[UNICODE] defines three "encoding forms"= ;, which are independent of serialization=E2=80=9D - what does =E2=80=9Cind= ependent of serialization=E2=80=9D mean? =C2=A0I think the UTF-* are actual= ly serializations of unicode codepoints. =C2=A0I suppose UTF-16 is sort-of = semi-independent of serialization, but UTF-8 never is.

2nd last para of 3.1, beginning =E2=80=9CXML MIME produ= cers are RECOMMENDED to provide means for XML MIME entity authors to determ= ine what value=E2=80=9D baffles me. =C2=A0I just read it 3 times and I don= =E2=80=99t get it. =C2=A0 Could we have an example or something? =C2=A0I al= so think I disagree with my guess as what it=E2=80=99s trying to say. =C2= =A0I tend to think the tools are going to do a better job of figuring out t= he right charset labeling than your typical document author.

The crucial =E2=80=9C this specification sets the prior= ity as follows:=E2=80=9D indented para in 3.2. =C2=A0I think a little more = is needed. The crucial corner case is when you=E2=80=99ve got a MIME-header= charset that is just wrong but an XML-aware receiver can in fact sort thin= gs out based on the encoding declaration. =C2=A0What does being =E2=80=9Cau= thoritative=E2=80=9D mean concretely? Is it the RFC=E2=80=99s recommendatio= n that the receiver SHOULD refuse to parse the the XML even though it could= ? =C2=A0If so, we should say so explicitly.

Then in the example in 9.8, draft says =E2=80=9Call pro= cessors will treat the enclosed entity as iso-8859-1 encoded. =C2=A0 That i= s, the "UTF-8" encoding declaration will be ignored.=E2=80=9D =C2= =A0Is this really true in practice? =C2=A0I suspect not; so perhaps you sho= uld say =E2=80=9Call processors which conform to this specification will=E2= =80=9D. =C2=A0Hm, or perhaps the real issue is that in this case, you can= =E2=80=99t predict what will happen; some implementations will ignore the M= IME header, others will drop-kick the XML because of the inconsistency.

Section 3.3 typo, =E2=80=9CthatUTF-16=E2=80=9D, space n= eeded, also =E2=80=9Centitiesnot=E2=80=9D in the same sentence.
<= br>
Also some spacing problems in the NOTE: in 8.1

=








On Fri, Feb 7, 2= 014 at 4:13 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
As usual, a disposition of comments against = the previous draft is
available at

=C2=A0 http://www.w3.org/XML/2012/10/3023bis/06-comments.html=

and an author's diff is at

=C2=A0 http://www.w3.org/XML/2012/1= 0/3023bis/draft-ietf-appsawg-xml-mediatypes-07_diff.html

This draft has few changes from version 6, almost all as a result of a
review by Larry Masinter, for which thanks.

The only change even close to substantive is a summary RECOMMENDATION
near the beginning of section 3, Encoding Considerations, which says

=C2=A0 The use of UTF-8, without a BOM, is RECOMMENDED for all XML MIME ent= ities.

See the 06-comments document for a summary of the discussion about
this.

The level of comments on this draft has shifted from substantive to
rhetorical/editorial, and I think it's now pretty much fully-baked.
I'd very much welcome some endorsements of its readiness, so that we can move it up and out of here.

ht
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Henry S. Thompson, School of Informatics, Univer= sity of Edinburgh
=C2=A0 =C2=A0 =C2=A0 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44= ) 131 650-4440
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax: (44) 131 650-4= 587, e-mail: ht@inf.ed.ac.uk
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0URL: h= ttp://www.ltg.ed.ac.uk/~ht/
=C2=A0[mail from me _always_ has a .sig like this -- mail without it is for= ged spam]
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e013a0d4230ab3d04f1ea5b91-- From ht@inf.ed.ac.uk Mon Feb 10 02:07:51 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601EC1A07D5 for ; Mon, 10 Feb 2014 02:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p19E6523kDNs for ; Mon, 10 Feb 2014 02:07:48 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id BDA8F1A05DE for ; Mon, 10 Feb 2014 02:07:46 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s1AA7VQT008002; Mon, 10 Feb 2014 10:07:36 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1AA7UmZ002947; Mon, 10 Feb 2014 10:07:30 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1AA7Tk3022249; Mon, 10 Feb 2014 10:07:29 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s1AA7ThM022245; Mon, 10 Feb 2014 10:07:29 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Tim Bray References: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 10 Feb 2014 10:07:29 +0000 In-Reply-To: (Tim Bray's message of "Sat\, 8 Feb 2014 11\:46\:01 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 10 Feb 2014 10:07:51 -0000 Tim Bray writes: > Disclosure: This is the first draft of xml-mediatypes I=E2=80=99ve read i= n years, > so probably is a little lacking in context. Thanks for taking the time to review. > 2.2: =E2=80=9C[UNICODE] defines three "encoding forms", which are indepen= dent of > serialization=E2=80=9D - what does =E2=80=9Cindependent of serialization= =E2=80=9D mean? I think > the UTF-* are actually serializations of unicode codepoints. I suppose > UTF-16 is sort-of semi-independent of serialization, but UTF-8 never is. The three encoding forms (UTF-8, -16 and -32) allow for at least 7 serializations between them. And the text does go on to say that UTF-8 has only one serialization. So I don't think there's anything wrong here, and it is following the UNICODE spec itself. > 2nd last para of 3.1, beginning =E2=80=9CXML MIME producers are RECOMMEND= ED to > provide means for XML MIME entity authors to determine what value=E2=80= =9D baffles > me. I just read it 3 times and I don=E2=80=99t get it. Could we have a= n example > or something? Sure, sorry if this was obscure. I was trying to avoid having to give an application-specific example, but .htaccess AddType or IIS Mime type configuration is what this is about. I'll try to improve this. > I also think I disagree with my guess as what it=E2=80=99s trying to > say. I tend to think the tools are going to do a better job of figuring > out the right charset labeling than your typical document author. Really? Neither of the above-mentioned tools will do the 'right' thing with my XHTML by default, for example. > The crucial =E2=80=9C this specification sets the priority as follows:=E2= =80=9D indented > para in 3.2. I think a little more is needed. The crucial corner case is > when you=E2=80=99ve got a MIME-header charset that is just wrong but an X= ML-aware > receiver can in fact sort things out based on the encoding declaration. There's nothing this document, or any processor, can do to always get it right when there is conflicting encoding information. The overall aim of section 3 is to focus on MIME, and to push hard on the proposition that a charset parameter should only be supplied if it is known to be correct. It is then consistent to say that when it _is_ present (and there is no BOM), it is authoritative. > What does being =E2=80=9Cauthoritative=E2=80=9D mean concretely? Is it t= he RFC=E2=80=99s > recommendation that the receiver SHOULD refuse to parse the the XML even > though it could? If so, we should say so explicitly. No -- 'authoritative' means 'answers the question "how to determine the encoding with which to attempt to process the entity"'. So the RFC is telling you how to process the entity, which is its job, after all. > Then in the example in 9.8, draft says =E2=80=9Call processors will treat= the > enclosed entity as iso-8859-1 encoded. That is, the "UTF-8" encoding > declaration will be ignored.=E2=80=9D Is this really true in practice? = I suspect > not; so perhaps you should say =E2=80=9Call processors which conform to t= his > specification will=E2=80=9D. I could make it 'conformant processors', but the whole point of a media type specification is to describe the behaviour of conformant processors. . . > Hm, or perhaps the real issue is that in this case, you can=E2=80=99t > predict what will happen; some implementations will ignore the MIME > header, others will drop-kick the XML because of the inconsistency. In practice, that's right. The crucial point, as section 3 concludes by emphasising, this whole problem _only_ arises when a non-conforming _producer_ has screwed up. The primary thrust of the spec is to clarify what producers must to, so that the practical relevance of the impossibility of consumers getting it right is minimised. > Section 3.3 typo, =E2=80=9CthatUTF-16=E2=80=9D, space needed, also =E2=80= =9Centitiesnot=E2=80=9D in the > same sentence. > > Also some spacing problems in the NOTE: in 8.1 Thanks, will be fixed in next draft. ht --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From mnot@mnot.net Mon Feb 10 23:03:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05351A08CF for ; Mon, 10 Feb 2014 23:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHPwzQmfHUy6 for ; Mon, 10 Feb 2014 23:03:47 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 534B11A08D7 for ; Mon, 10 Feb 2014 23:03:47 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.47.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B3AD722E1F3 for ; Tue, 11 Feb 2014 02:03:40 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> Date: Tue, 11 Feb 2014 18:03:35 +1100 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 07:03:49 -0000 I've been in an on-again, off-again discussion with some of the WEIRDS = folks about their work and its relationship to = . That seemed to precipitate = , which = describes a way to "bootstrap" a WEIRDS interaction, and I've been asked = for feedback. Reading through it, I have some issues, but I since uri-get-off-my-lawn = is a product of this WG, not just my draft, I'd rather get a sense of = what the WG thinks overall, rather than just giving my own feedback. AIUI, the bootstrap draft uses a number of IANA registries to contain a = mapping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to = URLs for their RDAP services.=20 Those URLs are then used as base URIs for further interactions; for = example, if example.com had a registry value of = "http://example.com/lookup", you'd look up "foo.example.com" as = "http://example.com/lookup/domain/foo.example.com". To me, this seems better than the previous solution (where you assumed = that example.com had something available at a certain path), but it = still "bakes" URLs into the spec, relative to that base URI. I.e., the = "/domain/whatever" bit above is locked into the spec and unchangeable, = AIUI. So, while they avoid collisions (probably), they still risk the other = problems that the "get off my lawn" draft cautions against, AFAICT. If I were doing this protocol and I still wanted to use a registry = (questionable IMHO), I'd allow each entry to contain a set of URL = templates, identified by link relations, that allows a one-step lookup = without baking in any URLs.=20 E.g.,=20 domain: example.com rel: domainlookup href-template: = http://example.com/lookup/{domain} I'm very curious to hear what other APPS folks think about this -- = especially those of a Web bent. We're trying to line up some = conversations about this in London, and I'd like to inform them with the = WG's perspective, rather than just my own. Cheers, -- Mark Nottingham http://www.mnot.net/ From tbray@textuality.com Mon Feb 10 23:28:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8F81A07A2 for ; Mon, 10 Feb 2014 23:28:10 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQYM2p5CwNfB for ; Mon, 10 Feb 2014 23:28:05 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C21A0772 for ; Mon, 10 Feb 2014 23:28:05 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id oz11so5738758veb.21 for ; Mon, 10 Feb 2014 23:28:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mgqqAV2QtdwICSU9agP3IAwQTlqWU8emWGf4YGPJX/Q=; b=hneYXb1ECN5ceFV9ei4KbWC3IZb7ZYrR21OMp0hqxrXEkwumrnS/3x5/IsL7rgbTRv NmjsgHNh4sH3qP71q8SOyqfC7mCAYauVugNfkQSsHZq2xXdde25MlWRKtDS2w/NoYHSL 1emMhntydSZYqUHB4RcyLE33Zx+jIdd5EQvEUCGVJaHSSscuJLHKnzdOpAO4mBkZD2IL r6CuTPqqcGbBMxgTWHz1VR3lm+JSExO6MbJ8hicZ2W8xgiVIOOfsmeOd2J/odSV8p0MH 6erNtRYvAFvqN4OB8SBY7B7v0rOX6VBT6TuABXAyxQFcoRkv9rxl6pNYBxz+1h+bjUxX 376A== X-Gm-Message-State: ALoCoQnSouY0cc92kiPW+DKgb/GBDoa+esggojROeAsBR0CnQSHtc6JkO0EdD/b/e24TNMhnxfuz MIME-Version: 1.0 X-Received: by 10.52.243.102 with SMTP id wx6mr22873351vdc.12.1392103684827; Mon, 10 Feb 2014 23:28:04 -0800 (PST) Received: by 10.220.98.73 with HTTP; Mon, 10 Feb 2014 23:28:04 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> Date: Mon, 10 Feb 2014 23:28:04 -0800 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a1133ec969ffeb304f21c65eb Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 07:28:10 -0000 --001a1133ec969ffeb304f21c65eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I reviewed it I=E2=80=99d identify that as a major issue and scream loud= ly. It would be helpful if we had an RFC to lean on saying =E2=80=9Cdon=E2=80=99t = do that=E2=80=9D. So, if my site requirements mean that my service needs to be at =E2=80=9C https://example.com?service=3Dweirds that /lookup/whatever is not going to sit happily on the end of it. On Mon, Feb 10, 2014 at 11:03 PM, Mark Nottingham wrote: > I've been in an on-again, off-again discussion with some of the WEIRDS > folks about their work and its relationship to < > http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn>. > > That seemed to precipitate < > http://tools.ietf.org/html/draft-ietf-weirds-bootstrap-00>, which > describes a way to "bootstrap" a WEIRDS interaction, and I've been asked > for feedback. > > Reading through it, I have some issues, but I since uri-get-off-my-lawn i= s > a product of this WG, not just my draft, I'd rather get a sense of what t= he > WG thinks overall, rather than just giving my own feedback. > > AIUI, the bootstrap draft uses a number of IANA registries to contain a > mapping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to UR= Ls > for their RDAP services. > > Those URLs are then used as base URIs for further interactions; for > example, if example.com had a registry value of "http://example.com/looku= p", > you'd look up "foo.example.com" as " > http://example.com/lookup/domain/foo.example.com". > > To me, this seems better than the previous solution (where you assumed > that example.com had something available at a certain path), but it still > "bakes" URLs into the spec, relative to that base URI. I.e., the > "/domain/whatever" bit above is locked into the spec and unchangeable, AI= UI. > > So, while they avoid collisions (probably), they still risk the other > problems that the "get off my lawn" draft cautions against, AFAICT. > > If I were doing this protocol and I still wanted to use a registry > (questionable IMHO), I'd allow each entry to contain a set of URL > templates, identified by link relations, that allows a one-step lookup > without baking in any URLs. > > E.g., > > domain: example.com > rel: domainlookup href-template: http://example.com/lookup/{domain= } > > I'm very curious to hear what other APPS folks think about this -- > especially those of a Web bent. We're trying to line up some conversation= s > about this in London, and I'd like to inform them with the WG's > perspective, rather than just my own. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a1133ec969ffeb304f21c65eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I reviewed it I=E2=80=99d identify that as a major issu= e and scream loudly. It would be helpful if we had an RFC to lean on saying= =E2=80=9Cdon=E2=80=99t do that=E2=80=9D. =C2=A0So, if my site requirements= mean that my service needs to be at =E2=80=9Chttps://example.com?service=3Dweirds that /lookup/w= hatever is not going to sit happily on the end of it.


On Mon, Feb 1= 0, 2014 at 11:03 PM, Mark Nottingham <mnot@mnot.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I've been in an on-again, off-again discussion with some of the WEIRDS = folks about their work and its relationship to <htt= p://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn>.

That seemed to precipitate <http://tools.ietf.org/html/draf= t-ietf-weirds-bootstrap-00>, which describes a way to "bootstra= p" a WEIRDS interaction, and I've been asked for feedback.

Reading through it, I have some issues, but I since uri-get-off-my-lawn is = a product of this WG, not just my draft, I'd rather get a sense of what= the WG thinks overall, rather than just giving my own feedback.

AIUI, the bootstrap draft uses a number of IANA registries to contain a map= ping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to URLs fo= r their RDAP services.

Those URLs are then used as base URIs for further interactions; for example= , if example.com had a= registry value of "http://example.com/lookup", you'd look up "foo.example.com" as = "http://example.com/lookup/domain/foo.example.com".

To me, this seems better than the previous solution (where you assumed that= example.com had somet= hing available at a certain path), but it still "bakes" URLs into= the spec, relative to that base URI. I.e., the "/domain/whatever"= ; bit above is locked into the spec and unchangeable, AIUI.

So, while they avoid collisions (probably), they still risk the other probl= ems that the "get off my lawn" draft cautions against, AFAICT.
If I were doing this protocol and I still wanted to use a registry (questio= nable IMHO), I'd allow each entry to contain a set of URL templates, id= entified by link relations, that allows a one-step lookup without baking in= any URLs.

E.g.,

domain: example.com =C2=A0 =C2=A0 rel: domainlookup =C2=A0 =C2=A0href-template: http://example.com/lookup= /{domain}

I'm very curious to hear what other APPS folks think about this -- espe= cially those of a Web bent. We're trying to line up some conversations = about this in London, and I'd like to inform them with the WG's per= spective, rather than just my own.

Cheers,

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

--001a1133ec969ffeb304f21c65eb-- From dret@berkeley.edu Tue Feb 11 05:39:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6201A0302 for ; Tue, 11 Feb 2014 05:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxi0G0qE8Ylu for ; Tue, 11 Feb 2014 05:39:15 -0800 (PST) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id CDCA21A01F5 for ; Tue, 11 Feb 2014 05:39:15 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] 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 1WDDYQ-00062E-8G; Tue, 11 Feb 2014 05:39:15 -0800 Message-ID: <52FA27FE.1070400@berkeley.edu> Date: Tue, 11 Feb 2014 14:39:10 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mark Nottingham , IETF Apps Discuss References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> In-Reply-To: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 13:39:18 -0000 hello mark. On 2014-02-11, 8:03 , Mark Nottingham wrote: > If I were doing this protocol and I still wanted to use a registry (questionable IMHO), I'd allow each entry to contain a set of URL templates, identified by link relations, that allows a one-step lookup without baking in any URLs. > > E.g., > > domain: example.com > rel: domainlookup href-template: http://example.com/lookup/{domain} > > I'm very curious to hear what other APPS folks think about this -- especially those of a Web bent. We're trying to line up some conversations about this in London, and I'd like to inform them with the WG's perspective, rather than just my own. i certainly like the idea of URI templates; they usually help to decrease coupling and make things clearer. but i think there still is some hesitation to use that particular spec. i think in part that's because it's not very easy to absorb when you just want to do simple things such as the one you're proposing. in part i think it's because there's an adoption problem: everybody is waiting for somebody else to be early adopters. i am wondering how/where the variable {domain} would end up being "declared". your link hints draft and my link descriptions draft try to establish some way how this could be done, but afaict, currently that would be informal and maybe in the definition of the link relation? [[ side note for a possible revision of RFC5988: currently, URI template is not even mentioned in "Web Linking", which makes sense, because it predates URI template. maybe a revision should change that. ]] i only brief skimmed the draft-ietf-weirds-bootstrap draft, but it seemed to me that the spec really needing URI template help is http://tools.ietf.org/html/draft-ietf-weirds-rdap-query; section 3 has quite a bit of baked URI structure. so maybe getting the URI segments out of that draft would be the thing to look at? ------- feel free to skip, just a side note after skimming the draft: on an unrelated angle, i am wondering about this part of the draft (the one you linked to): "IANA should make sure that the service of those registries is able to cope with a larger demand and should take appropriate measures such as caching and load balancing." afaict, most IANA registries are not really intended for runtime access. as is well-known (such as with W3C's HTML DTD URIs), even when a spec says that clients shouldn't blindly re-fetch every single time, there may be enough doing it anyway to have serious consequences. anyway, that's not the question you were asking, but was a rather curious part of that particular draft. 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 marc.blanchet@viagenie.ca Tue Feb 11 05:58:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F9B1A030C for ; Tue, 11 Feb 2014 05:58:41 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrpbB5HsKAKG for ; Tue, 11 Feb 2014 05:58:39 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D19F1A00BC for ; Tue, 11 Feb 2014 05:58:39 -0800 (PST) Received: from [IPv6:2620::230:c000:294d:8cc1:5380:4d0c] (unknown [IPv6:2620:0:230:c000:294d:8cc1:5380:4d0c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6ABFE40447; Tue, 11 Feb 2014 08:58:38 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Blanchet In-Reply-To: <52FA27FE.1070400@berkeley.edu> Date: Tue, 11 Feb 2014 08:58:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9E3C776F-CD7B-4D45-A1E7-0B413FAB85F2@viagenie.ca> References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> <52FA27FE.1070400@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1827) Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 13:58:41 -0000 Le 2014-02-11 =E0 08:39, Erik Wilde a =E9crit : > ------- feel free to skip, just a side note after skimming the draft: >=20 > on an unrelated angle, i am wondering about this part of the draft = (the one you linked to): >=20 > "IANA should make sure that the service of those registries is able to = cope with a larger demand and should take appropriate measures such as = caching and load balancing." >=20 > afaict, most IANA registries are not really intended for runtime = access. as is well-known (such as with W3C's HTML DTD URIs), even when a = spec says that clients shouldn't blindly re-fetch every single time, = there may be enough doing it anyway to have serious consequences. = anyway, that's not the question you were asking, but was a rather = curious part of that particular draft. - This has been discussed with IANA and they already have this = capability: they just need to initiate it for that registry. However, it = is not appropriate to discuss the details in this document, therefore = the wording is vague. - moreover, a new rev of the document due this week (local copy already = have text) will contain text about how the implementations should = behave. (and at the same time, the backend, as stated above, being able = to cope with bad implementations). Marc. >=20 > cheers, >=20 > dret. >=20 > --=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 | >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From marc.blanchet@viagenie.ca Tue Feb 11 06:09:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2373A1A0311 for ; Tue, 11 Feb 2014 06:09:47 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1SAtrmwq5J4 for ; Tue, 11 Feb 2014 06:09:44 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D11B51A0310 for ; Tue, 11 Feb 2014 06:09:43 -0800 (PST) Received: from [IPv6:2620::230:c000:294d:8cc1:5380:4d0c] (unknown [IPv6:2620:0:230:c000:294d:8cc1:5380:4d0c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1A7B740447; Tue, 11 Feb 2014 09:09:43 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Blanchet In-Reply-To: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> Date: Tue, 11 Feb 2014 09:09:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D6BE438-4886-44EC-963C-0F7EC20284A0@viagenie.ca> References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1827) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 14:09:47 -0000 Le 2014-02-11 =E0 02:03, Mark Nottingham a =E9crit : > I've been in an on-again, off-again discussion with some of the WEIRDS = folks about their work and its relationship to = . >=20 > That seemed to precipitate = , no. it did not precipitate. this bootstrap discussion has been on going = for quite some time and in parallel of the URI discussion. > which describes a way to "bootstrap" a WEIRDS interaction, and I've = been asked for feedback. >=20 > Reading through it, I have some issues, but I since = uri-get-off-my-lawn is a product of this WG, not just my draft, I'd = rather get a sense of what the WG thinks overall, rather than just = giving my own feedback. >=20 > AIUI, the bootstrap draft uses a number of IANA registries to contain = a mapping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to = URLs for their RDAP services.=20 >=20 > Those URLs are then used as base URIs for further interactions; for = example, if example.com had a registry value of = "http://example.com/lookup", you'd look up "foo.example.com" as = "http://example.com/lookup/domain/foo.example.com". >=20 > To me, this seems better than the previous solution (where you assumed = that example.com had something available at a certain path), actually, the previous solution was not addressing the bootstrap = problem. > but it still "bakes" URLs into the spec, relative to that base URI. = I.e., the "/domain/whatever" bit above is locked into the spec and = unchangeable, AIUI. >=20 > So, while they avoid collisions (probably), they still risk the other = problems that the "get off my lawn" draft cautions against, AFAICT. >=20 > If I were doing this protocol and I still wanted to use a registry = (questionable IMHO), I'd allow each entry to contain a set of URL = templates, identified by link relations, that allows a one-step lookup = without baking in any URLs.=20 >=20 > E.g.,=20 >=20 > domain: example.com > rel: domainlookup href-template: = http://example.com/lookup/{domain} yes. that is another way. it provides an additional level of indirection = to remove the url component out from the spec. but it actually overload = the registry with more data than typically necessary, and pretty = repetitive. i.e. most likely every registry will have rel: domainlookup = href-template: http://exampleregistry1.com/lookup/{domain}, rel: = domainlookup href-template: = http://exampleregistry2.com/lookup/{domain}, rel: domainlookup = href-template: http://exampleregistry3.com/lookup/{domain}. Given the = number of TLDs and that there are about 10 objects, we are multiplying = the entries by 10, becomes pretty large registry operationally to parse. >=20 > I'm very curious to hear what other APPS folks think about this -- = especially those of a Web bent. We're trying to line up some = conversations about this in London, and I'd like to inform them with the = WG's perspective, rather than just my own. btw, "them/they", "we": we are the same IETF people. Why are we talking = the "them" and "we" perspective? Marc. >=20 > Cheers, >=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 From ht@inf.ed.ac.uk Tue Feb 11 07:24:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264DB1A0414 for ; Tue, 11 Feb 2014 07:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W005L_MuvB9y for ; Tue, 11 Feb 2014 07:24:25 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2D1A0412 for ; Tue, 11 Feb 2014 07:24:24 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s1BFNuQQ010015; Tue, 11 Feb 2014 15:23:56 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1BFNtRO019633; Tue, 11 Feb 2014 15:23:55 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1BFNsVS029691; Tue, 11 Feb 2014 15:23:54 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s1BFNsG2029687; Tue, 11 Feb 2014 15:23:54 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: S Moonesamy References: <6.2.5.6.2.20140110142955.0ac73048@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 11 Feb 2014 15:23:54 +0000 In-Reply-To: <6.2.5.6.2.20140110142955.0ac73048@elandnews.com> (S. Moonesamy's message of "Fri\, 10 Jan 2014 15\:57\:23 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: Chris Lilley , apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-xml-mediatypes-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 15:24:29 -0000 S Moonesamy writes: > I have a few comments on draft-ietf-appsawg-xml-mediatypes-06. Sorry I missed these in my review for draft -07! > In Section 3.1: > > "XML-unaware MIME producers MUST NOT supply a charset parameter with > an XML MIME entity unless the entity's character encoding is reliably > known." > > The title of that section is "XML MIME producers". The above states a > (RFC 2119) requirement for a "XML-unaware MIME producer". Can an > agent which is not capable of processing XML MIME entities and > detecting the XML encoding declaration follow the requirement, and > does the requirement even apply given that the requirements being > specified are for XML MIME producers? So, good point -- There's a subtle issue here which I should try to clarify. We have MIME agents (producers or consumers) 1) Which are also XML processors, i.e. XML-aware 2) Which are not XML processors, i.e. not XML-aware 2a) Which are none-the-less good MIME citizens, i.e. they try to conform to _all_ media-type registrations to the extent that they can, and they are therefore trying to conform to this one. 2b) The real ignorant remnant, for whom by definition nothing here is relevant. How much detail is needed in this regard in the spec? > As a nit, the unless clause in the requirement (sentence) seems odd. > It may be simpler to set requirements for "XML-aware" MIME producers > only. Maybe, as for the following para., this is just too much of an in-crowd thing. What it _means_ to those of us who have struggled with this situation for the last 10 years is "Sysadmins: do _not_ configure your apache servers to serve XML and/or XHTML with a charset param of iso-8859-1 by default unless you _really_ know what your users are shipping" > "XML MIME producers are RECOMMENDED to provide means for XML MIME > entity authors to determine what value, if any, is given to charset > parameters for their entities, for example by enabling user-level > configuration of filename-to-Content-Type-header mappings on a file- > by-file or suffix basis." > > The "entity authors" in the above is not clear. Is it a person or an agent? Person, but see reply to Tim Bray and above. > "The use of UTF-32 is NOT RECOMMENDED for XML MIME entities." > > I suggest having a short explanation about why the use of UTF-32 is > not recommended instead of only saying that it is not recommended. Care to suggest some wording? Seriously, my understanding is that the main reason is that most (all?) of the major browsers have removed support for UTF-32, often citing security considerations which I don't fully understand. . . So, is something along the following lines sufficient? UTF-32 is not widely supported, and security concerns about its use have been raised. Accordingly, the use of [as before]. > "XML-aware consumers MUST follow the requirements in section 4.3.3 > of [XML] that directly address this case." > > This is a requirement by reference to an external specification. I am > listing this as it is unusual. I could repeat it, but I hate duplicating normative prose. . . > "XML-unaware MIME consumers SHOULD NOT assume a default encoding in > this case." > > Would a XML-unaware MIME consumer be following this specification? I hope so, see above. > In Section 4.2: > > 'Interoperability considerations: XML has proven to be interoperable > across both generic and task-specific applications and for import > and export from multiple XML authoring and editing tools. > Validating processors provide maximum interoperability. Although > non-validating processors may be more efficient, they are not > required to handle all features of XML. For further information, > see sub-section 2.9 "Standalone Document Declaration" and section > 5 "Conformance" of [XML].' > > The paragraph is about interoperability considerations. The text > comes out as saying that "XML is great". :-) Are there any > interoperability issues to consider? That's what the reader might > wish to know. Fair enough. This is very old prose, which I hadn't touched. At least the UTF-8 advice should be repeated. > In Section 8.1: > > "Media subtypes that do not represent XML MIME entities > MUST NOT be allowed to register with a '+xml' suffix." > > It would be easier to say that the "+xml" suffix can only be > registered for media subtypes that represent XML MIME entities. I'll get rid of the double negation. > Section 8.1 is about IANA registrations. I would read it as guidance > for IANA and people requesting a registration. I suggest phrasing the > relevant text from that perspective and moving that text into the IANA > Considerations section. Good idea -- I'll leave an introductory bit, so the 8.2 doesn't come completely out of the blue. > In Section 8.3: > > 'Registrations for new XML-based media types which do _not_ use the > '+xml' suffix SHOULD, in specifying the charset parameter and > encoding considerations, define them as: "Same as [charset parameter > / encoding considerations] of application/xml as specified in RFC > XXXX."' > > Why is this a RFC 2119 "should"? > > "These registrations SHOULD also make reference to RFC XXXX in > specifying magic numbers, base URIs, and use of the BOM." > > I suggest rephrasing this as guidance and not as a RFC 2119 > recommendation. Please note that I do not have a strong opinion about > this as it may be a matter of style. You're probably right, in both cases. > "These registrations MAY reference the application/xml registration in > RFC XXXX in specifying interoperability and fragment identifier > considerations, if these considerations are not overridden by issues > specific to that media type." > > Why is this a RFC 2119 "may"? And this one. > I suggest moving the examples in Section 9 to an appendix. They were in a main section in 3023, and I'd rather not -- do you feel strongly? Does anyone else, either way? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From andy@hxr.us Tue Feb 11 09:05:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB0F1A0635 for ; Tue, 11 Feb 2014 09:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuLX80LLL66g for ; Tue, 11 Feb 2014 09:05:20 -0800 (PST) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 497881A0633 for ; Tue, 11 Feb 2014 09:05:20 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y10so7747581pdj.12 for ; Tue, 11 Feb 2014 09:05:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NJ3/ADku3SBQkypd+XscD96kaJ0I0ktZFU+b+Yqunu8=; b=ZgAUMwx8W+s3I5NFse0rqG4lphknZJOvl2gG5LvjhcgWX4ZEL1NYU+/3vdrz4dqrkR L0pN3djuaMO5I80OYgzRJ4COsUZP/zsIgOAUXdD0kGWX2HQVSKTL56VQMBAVkM+pSBFe 516/D9neOCet7UovMIJBRP3zvcyRqtmKr9Xz6Xkfc99j5aTN3rjfW3A4r/oHRKo1m9hx Nm/7mvHGJW21cyPtIi/c8FS3HjlMl0KKJk60MLBDDPKPO/IGjPrTbxQokOZZrXWZWN+x 0HiyCQczjycSpxMTIjZbgBOTsKvXbbYGkvmZrhZdX/Iz6X+rOzioD9ezl39DXjmKGLJ3 baIg== X-Gm-Message-State: ALoCoQm+ndgSaDhsZjCnL3N425IbWMyeKsYPvakk3lUthdHW+xBAQTzMJUrF+zFd0JkGZJl6nGO8 MIME-Version: 1.0 X-Received: by 10.68.234.230 with SMTP id uh6mr11758550pbc.161.1392137964141; Tue, 11 Feb 2014 08:59:24 -0800 (PST) Received: by 10.68.143.4 with HTTP; Tue, 11 Feb 2014 08:59:24 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> Date: Tue, 11 Feb 2014 11:59:24 -0500 Message-ID: From: Andrew Newton To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 17:05:22 -0000 Mark, Thank you for looking into this and for being proactive. With regard to your idea to use templates in the registry, it seems to me the current specification is already doing an implicit template of the sort http://example.com/blah/{rest-of-weirds-uri}. As one of the participants of the WEIRDS effort, I think your idea is worth consideration. While the group has looked at templates but not found favor with them, I believe what you are suggesting does not have the issue to which the group objected to previously. As for baked URIs, there was a suggestion to use .well-known with which the WEIRDS group is struggling (very interrelated to bootstrapping). Would you still suggest the use of .well-known with a registry? Is the use of .well-known not just to avoid collisions but to also allow applications to identify URIs by application type without the need for creating a new URI scheme? -andy On Tue, Feb 11, 2014 at 2:03 AM, Mark Nottingham wrote: > I've been in an on-again, off-again discussion with some of the WEIRDS fo= lks about their work and its relationship to . > > That seemed to precipitate , which describes a way to "bootstrap" a WEIRDS interaction, a= nd I've been asked for feedback. > > Reading through it, I have some issues, but I since uri-get-off-my-lawn i= s a product of this WG, not just my draft, I'd rather get a sense of what t= he WG thinks overall, rather than just giving my own feedback. > > AIUI, the bootstrap draft uses a number of IANA registries to contain a m= apping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to URLs = for their RDAP services. > > Those URLs are then used as base URIs for further interactions; for examp= le, if example.com had a registry value of "http://example.com/lookup", you= 'd look up "foo.example.com" as "http://example.com/lookup/domain/foo.examp= le.com". > > To me, this seems better than the previous solution (where you assumed th= at example.com had something available at a certain path), but it still "ba= kes" URLs into the spec, relative to that base URI. I.e., the "/domain/what= ever" bit above is locked into the spec and unchangeable, AIUI. > > So, while they avoid collisions (probably), they still risk the other pro= blems that the "get off my lawn" draft cautions against, AFAICT. > > If I were doing this protocol and I still wanted to use a registry (quest= ionable IMHO), I'd allow each entry to contain a set of URL templates, iden= tified by link relations, that allows a one-step lookup without baking in a= ny URLs. > > E.g., > > domain: example.com > rel: domainlookup href-template: http://example.com/lookup/{domain= } > > I'm very curious to hear what other APPS folks think about this -- especi= ally those of a Web bent. We're trying to line up some conversations about = this in London, and I'd like to inform them with the WG's perspective, rath= er than just my own. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From tbray@textuality.com Tue Feb 11 10:53:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26841A06D0 for ; Tue, 11 Feb 2014 10:53:57 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rGCfBWFttSR for ; Tue, 11 Feb 2014 10:53:55 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5041A06AD for ; Tue, 11 Feb 2014 10:53:54 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so6150199vcb.19 for ; Tue, 11 Feb 2014 10:53:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iOK6l6Tqay5cHpwXPmfdyBqpqF3/cSV2dezXtoU2aCY=; b=TzbobtZNZb/0zz9x5SYwPgywNaozttOr1ztMJeDYaEpowP+PQQvjghTgeecLlihjN5 SJBmUhrjYoNLS7hvOqUlPyGJ43SLfH+Tx0ke9nGjZYkKAZDc7SSlcgSpj2bDRzZQep69 7yn2ZI8/ZFBIpB7gBb7VDDdlSf/wdhHVu4Q0uuU/pFcPnTIYYJJ/BOgmj6812eFv37fu irQ91OCqqZoec994RBSc4kYNfVAgkuI0KzkexnkOCn0d8o+kDXnOblrmQSZaV0eRL9Uo pSuYiL0PQLbNUTQ5ftW6uTxpKveYZ7kwz27yapXBRikPAmfzwM4KXBT6bWHr2ZWe9uME ypDQ== X-Gm-Message-State: ALoCoQlD108V1OXZPTsBpkh7KTOXwn0sXVejyawSBkB0ZhNiiTfilu8ROAZoanqsws0WEou/AZmV MIME-Version: 1.0 X-Received: by 10.220.89.4 with SMTP id c4mr440671vcm.53.1392144834385; Tue, 11 Feb 2014 10:53:54 -0800 (PST) Received: by 10.220.98.73 with HTTP; Tue, 11 Feb 2014 10:53:54 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 10:53:54 -0800 Message-ID: From: Tim Bray To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=047d7b3a8456546f4404f225fa14 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 18:53:57 -0000 --047d7b3a8456546f4404f225fa14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 2:07 AM, Henry S. Thompson wrote: > > > 2.2: =E2=80=9C[UNICODE] defines three "encoding forms", which are indep= endent of > > serialization=E2=80=9D - what does =E2=80=9Cindependent of serializatio= n=E2=80=9D mean? I think > > the UTF-* are actually serializations of unicode codepoints. I suppose > > UTF-16 is sort-of semi-independent of serialization, but UTF-8 never is= . > > The three encoding forms (UTF-8, -16 and -32) allow for at least 7 > serializations between them. And the text does go on to say that > UTF-8 has only one serialization. So I don't think there's anything > wrong here, and it is following the UNICODE spec itself. > The sentence =E2=80=9C[UNICODE] defines three "encoding forms", which are independent of serialization, namely UTF-8, UTF-16 and UTF-32. =E2=80=9D is= really horribly misleading. UTF-8 is a serialization. UTF-16 and -32 are not independent of serialization in the slightest, you can=E2=80=99t process th= em successfully unless you know whether you=E2=80=99re looking at the _LE or _= BE serializations. How about something like [UNICODE] defines several =E2=80=9Cencoding forms=E2=80=9D, namely UTF-8, U= TF-16, and UTF-32. UTF-8 is a serialization. Note that UTF-16 XML documents may be serialised into MIME entities in ... [also loses the information-free sentence about the spec following the =E2=80=9Cprecedent=E2=80=9D] > > I also think I disagree with my guess as what it=E2=80=99s trying to > > say. I tend to think the tools are going to do a better job of figurin= g > > out the right charset labeling than your typical document author. > > Really? Neither of the above-mentioned tools will do the 'right' > thing with my XHTML by default, for example. > Ah, I got it finally; as the other thread said, what this is *really* talking about is configuring your web server and so on. So this is OK, except for I think the word =E2=80=9Cauthor=E2=80=9D is misleading since do= cument authors shouldn=E2=80=99t be expected to understand Unicode encodings or webserver considerations. So maybe something like: XML MIME producers are RECOMMENDED to provide means to control what value, if any, is given to charset parameters for XML MIME entities, for example by enabling Web server configuration of filename-to-Content-Type-header mappings on a file- by-file or suffix basis. > > What does being =E2=80=9Cauthoritative=E2=80=9D mean concretely? Is it= the RFC=E2=80=99s > > recommendation that the receiver SHOULD refuse to parse the the XML eve= n > > though it could? If so, we should say so explicitly. > > No -- 'authoritative' means 'answers the question "how to determine > the encoding with which to attempt to process the entity"'. So the > RFC is telling you how to process the entity, which is its job, after > all. > RIght, but it feels bizarre and sort of against the spirit of Postel=E2=80= =99s law to remain completely silent about what happens when there are conflicts. I suggest you simply say that in the case of conflict, interoperability can suffer since the observed behavior of receiving software is unpredictable. This reinforces your central thrust, which is: Don=E2=80=99t do this. > > Then in the example in 9.8, draft says =E2=80=9Call processors will tre= at the > > enclosed entity as iso-8859-1 encoded. That is, the "UTF-8" encoding > > declaration will be ignored.=E2=80=9D Is this really true in practice?= I > suspect > > not; so perhaps you should say =E2=80=9Call processors which conform to= this > > specification will=E2=80=9D. > > I could make it 'conformant processors', but the whole point of a > media type specification is to describe the behaviour of conformant > processors. . . > It bothers me that the assertion, as stated, is simply wrong, and I don=E2= =80=99t think RFCs should contain assertions which are empirically false. It=E2= =80=99s fairly common in the RFCs that I say to note that conformant implementations will do thus and so. > --047d7b3a8456546f4404f225fa14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 10, 2014 at 2:07 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:

> 2.2: =E2=80=9C[UNICODE] defines three "encoding forms", whic= h are independent of
> serialization=E2=80=9D - what does =E2=80=9Cindependent of serializati= on=E2=80=9D mean? =C2=A0I think
> the UTF-* are actually serializations of unicode codepoints. =C2=A0I s= uppose
> UTF-16 is sort-of semi-independent of serialization, but UTF-8 never i= s.

The three encoding forms (UTF-8, -16 and -32) allow for at least 7 serializations between them. =C2=A0And the text does go on to say that
UTF-8 has only one serialization. =C2=A0So I don't think there's an= ything
wrong here, and it is following the UNICODE spec itself.

The sentence =E2=80=9C[UNICODE] defines three "encod= ing forms", which are independent of serialization, namely UTF-8, UTF-= 16 and UTF-32. =E2=80=9D is really horribly misleading. UTF-8 is a serializ= ation. UTF-16 and -32 are not independent of serialization in the slightest= , you can=E2=80=99t process them successfully unless you know whether you= =E2=80=99re looking at the _LE or _BE serializations. =C2=A0How about somet= hing like=C2=A0

[UNICODE] defines several =E2=80=9Cencoding forms=E2=80= =9D, namely UTF-8, UTF-16, and UTF-32. =C2=A0UTF-8 is a serialization. Note= that UTF-16 XML documents may be serialised into MIME entities in ... [als= o loses the information-free sentence about the spec following the =E2=80= =9Cprecedent=E2=80=9D]
=C2=A0
> I also think I disagree with my guess as what it=E2=80= =99s trying to
> say. =C2=A0I tend to think the tools are going to do a better job of f= iguring
> out the right charset labeling than your typical document author.

Really? =C2=A0Neither of the above-mentioned tools will do the 'r= ight'
thing with my XHTML by default, for example.

Ah, I got it finally; as the other thread said, what this is *really*= talking about is configuring your web server and so on. =C2=A0So this is O= K, except for I think the word =E2=80=9Cauthor=E2=80=9D is misleading since= document authors shouldn=E2=80=99t be expected to understand Unicode encod= ings or webserver considerations. =C2=A0 So maybe something like:

XML MIME producers are RECOMMENDED to provide mean= s to control what value, if any, is given to charset parameters for XML MIM= E entities, for example by enabling Web server configuration of filename-to= -Content-Type-header mappings on a file- by-file or suffix basis.
=C2=A0
> =C2=A0What does being =E2=80=9Cauthoritative=E2=80=9D mean concretely?= Is it the RFC=E2=80=99s
> recommendation that the receiver SHOULD refuse to parse the the XML ev= en
> though it could? =C2=A0If so, we should say so explicitly.

No -- 'authoritative' means 'answers the question "h= ow to determine
the encoding with which to attempt to process the entity"'. =C2=A0= So the
RFC is telling you how to process the entity, which is its job, after
all.

RIght, but it feels bizarre and so= rt of against the spirit of Postel=E2=80=99s law to remain completely silen= t about what happens when there are conflicts. =C2=A0I suggest you simply s= ay that in the case of conflict, interoperability can suffer since the obse= rved behavior of receiving software is unpredictable. =C2=A0This reinforces= your central thrust, which is: Don=E2=80=99t do this.
=C2=A0
> Then in the example in 9.8, draft says =E2=80=9Call pr= ocessors will treat the
> enclosed entity as iso-8859-1 encoded. =C2=A0 That is, the "UTF-8= " encoding
> declaration will be ignored.=E2=80=9D =C2=A0Is this really true in pra= ctice? =C2=A0I suspect
> not; so perhaps you should say =E2=80=9Call processors which conform t= o this
> specification will=E2=80=9D.

I could make it 'conformant processors', but the whole point = of a
media type specification is to describe the behaviour of conformant
processors. . .

It bothers me that the = assertion, as stated, is simply wrong, and I don=E2=80=99t think RFCs shoul= d contain assertions which are empirically false. =C2=A0 It=E2=80=99s fairl= y common in the RFCs that I say to note that conformant implementations wil= l do thus and so.


--047d7b3a8456546f4404f225fa14-- From johnl@iecc.com Tue Feb 11 14:33:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637EF1A07B1 for ; Tue, 11 Feb 2014 14:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsPeksWFbMqS for ; Tue, 11 Feb 2014 14:33:14 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 873491A07A4 for ; Tue, 11 Feb 2014 14:33:14 -0800 (PST) Received: (qmail 60013 invoked from network); 11 Feb 2014 22:33:13 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Feb 2014 22:33:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52faa529.xn--i8sz2z.k1402; i=johnl@user.iecc.com; bh=1yMZBZvHYsPjjtM6TKuyDDRzNbIBAE+dKvGK8w1VKFg=; b=olPNXxePOC97dde7epL6Oo8brLS9K8MS99j1aLCBkun2Ri4sSXlRJkNwBWK3qDvrZsq9G7YtLAfNQ1qr22YlYcXvMVIY8B3RxErn6pZ/TQN2gnY4XG9NKuR70USHqMYQdPoujLoV/yIQ/B1595Sf93YhC4CC9+9+xxlSCKb1i/DYgFuU1clemKHf2d73P/PJWZTS/x9j7Mq3MjbF6NeljJVR1KnD6BfPXtlqow2EKVovvxFZqhllVO/T3OmXBOpP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52faa529.xn--i8sz2z.k1402; bh=1yMZBZvHYsPjjtM6TKuyDDRzNbIBAE+dKvGK8w1VKFg=; b=OJUeuY8Fa5Oxomp4emKhCX0FnngXZxMccaZjq2W7dFHbnCLdfSzgmJOMs5/J2o8ZWlJP5EAaaDfkfx+2sYmH11qdp0itb5/+8RD5ci0BciNIS2kSwdSd+Edl6EzSRQ0go5YAih7nBNDZw4gIkv5cwTIUc6OqyhR4s59hcs6MmywM7/V6pwmrheHUbGl1JTtWWMwYIAIVYaeHK3fhO8aWfybF8n9lp7fqYukKFbzYGkjMskFLpTYcgd324uPxNAFr Date: 11 Feb 2014 22:32:50 -0000 Message-ID: <20140211223250.68983.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 22:33:16 -0000 >domain: example.com > rel: domainlookup href-template: http://example.com/lookup/{domain} > >I'm very curious to hear what other APPS folks think about this RDAP is a new design. There are no existing RDAP servers other than a few prototypes run by people on the WEIRDS list. There's nothing to be backward compatible with. RDAP is intended as a replacement for WHOIS, to answer the same questions that people ask now using WHOIS, e.g. information about domain names, IP addresses, ASNs, and a few other things. The questions that people ask with WHOIS haven't changed materially in 20 years, and I see no reason to expect them to change in the future. Small RDAP servers will likely adapt the RDAP prototype being funded by ICANN. Large RDAP servers will be written by a handful of large registries, all of which are represented on the WEIRDS list and can speak for themselves, but I can't remember any of them showing notable enthusiasm for templates. In this particular application, I really can't see any benefit to templates other than the ability to be gratuitously different just to prove that you can. R's, John From mnot@mnot.net Tue Feb 11 20:43:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1BE1A082E for ; Tue, 11 Feb 2014 20:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqKNk4yz12B1 for ; Tue, 11 Feb 2014 20:43:33 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AB1081A082C for ; Tue, 11 Feb 2014 20:43:33 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.47.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 04B4F22E253; Tue, 11 Feb 2014 23:43:30 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: Date: Wed, 12 Feb 2014 15:43:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> To: Andrew Newton X-Mailer: Apple Mail (2.1827) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 04:43:36 -0000 On 12 Feb 2014, at 3:59 am, Andrew Newton wrote: > Mark, >=20 > Thank you for looking into this and for being proactive. >=20 > With regard to your idea to use templates in the registry, it seems to > me the current specification is already doing an implicit template of > the sort http://example.com/blah/{rest-of-weirds-uri}. As one of the > participants of the WEIRDS effort, I think your idea is worth > consideration. While the group has looked at templates but not found > favor with them, I believe what you are suggesting does not have the > issue to which the group objected to previously. OK. To be clear, it was just a suggestion -- there are a lot of ways to = do this, but templates seemed like a way to get there without inventing = too much yourself (which seems to be the point, since you're already = reusing HTTP :). > As for baked URIs, there was a suggestion to use .well-known with > which the WEIRDS group is struggling (very interrelated to > bootstrapping). Would you still suggest the use of .well-known with a > registry? Is the use of .well-known not just to avoid collisions but > to also allow applications to identify URIs by application type > without the need for creating a new URI scheme? It really depends on the use case, which I don't feel like I yet have = enough grasp of. I don't want to position .well-known as a panacea, = because it's not -- it's for very specific circumstances (basically, = when you need to bootstrap from a hostname, not a URI). Cheers, >=20 > -andy >=20 > On Tue, Feb 11, 2014 at 2:03 AM, Mark Nottingham = wrote: >> I've been in an on-again, off-again discussion with some of the = WEIRDS folks about their work and its relationship to = . >>=20 >> That seemed to precipitate = , which = describes a way to "bootstrap" a WEIRDS interaction, and I've been asked = for feedback. >>=20 >> Reading through it, I have some issues, but I since = uri-get-off-my-lawn is a product of this WG, not just my draft, I'd = rather get a sense of what the WG thinks overall, rather than just = giving my own feedback. >>=20 >> AIUI, the bootstrap draft uses a number of IANA registries to contain = a mapping of (domain names, IPv4 networks, IPv6 networks, AS numbers) to = URLs for their RDAP services. >>=20 >> Those URLs are then used as base URIs for further interactions; for = example, if example.com had a registry value of = "http://example.com/lookup", you'd look up "foo.example.com" as = "http://example.com/lookup/domain/foo.example.com". >>=20 >> To me, this seems better than the previous solution (where you = assumed that example.com had something available at a certain path), but = it still "bakes" URLs into the spec, relative to that base URI. I.e., = the "/domain/whatever" bit above is locked into the spec and = unchangeable, AIUI. >>=20 >> So, while they avoid collisions (probably), they still risk the other = problems that the "get off my lawn" draft cautions against, AFAICT. >>=20 >> If I were doing this protocol and I still wanted to use a registry = (questionable IMHO), I'd allow each entry to contain a set of URL = templates, identified by link relations, that allows a one-step lookup = without baking in any URLs. >>=20 >> E.g., >>=20 >> domain: example.com >> rel: domainlookup href-template: = http://example.com/lookup/{domain} >>=20 >> I'm very curious to hear what other APPS folks think about this -- = especially those of a Web bent. We're trying to line up some = conversations about this in London, and I'd like to inform them with the = WG's perspective, rather than just my own. >>=20 >> Cheers, >>=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 -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Feb 11 20:49:11 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A51A0846 for ; Tue, 11 Feb 2014 20:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbQln8L6Xsm9 for ; Tue, 11 Feb 2014 20:49:09 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9C1A0837 for ; Tue, 11 Feb 2014 20:49:08 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.47.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CF54B22E1F3; Tue, 11 Feb 2014 23:49:05 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: <0D6BE438-4886-44EC-963C-0F7EC20284A0@viagenie.ca> Date: Wed, 12 Feb 2014 15:49:01 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> <0D6BE438-4886-44EC-963C-0F7EC20284A0@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1827) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 04:49:11 -0000 On 12 Feb 2014, at 1:09 am, Marc Blanchet = wrote: > yes. that is another way. it provides an additional level of = indirection to remove the url component out from the spec. but it = actually overload the registry with more data than typically necessary, = and pretty repetitive. i.e. most likely every registry will have rel: = domainlookup href-template: = http://exampleregistry1.com/lookup/{domain}, rel: domainlookup = href-template: http://exampleregistry2.com/lookup/{domain}, rel: = domainlookup href-template: = http://exampleregistry3.com/lookup/{domain}. Given the number of TLDs = and that there are about 10 objects, we are multiplying the entries by = 10, becomes pretty large registry operationally to parse. Perhaps, but it may be possible to mitigate that, depending on the = particulars of how it's going to be used and deployed. E.g., have IANA run a lookup service themselves; e.g., = http://iana.org/rdap/domain/foo.com Or, define a document format that IANA points to in the registry, and = *it* points to the various endpoints.=20 Also, if the data is that voluminous, it suggests that you may have a = problem anyway; adding such repetitive information shouldn't affect the = size of the response after gzip (which you'd want to use in any case) = that much. >> I'm very curious to hear what other APPS folks think about this -- = especially those of a Web bent. We're trying to line up some = conversations about this in London, and I'd like to inform them with the = WG's perspective, rather than just my own. >=20 > btw, "them/they", "we": we are the same IETF people. Why are we = talking the "them" and "we" perspective? Strangely, we *do* organise ourselves into groups and areas here. Or are = you proposing something more radical? -- Mark Nottingham http://www.mnot.net/ From marc.blanchet@viagenie.ca Wed Feb 12 05:58:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3E71A0997 for ; Wed, 12 Feb 2014 05:58:03 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWzOqog53qOt for ; Wed, 12 Feb 2014 05:58:00 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DACF1A032E for ; Wed, 12 Feb 2014 05:58:00 -0800 (PST) Received: from [IPv6:2620::230:c000:d927:f33:246e:c68c] (unknown [IPv6:2620:0:230:c000:d927:f33:246e:c68c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5D6314690F; Wed, 12 Feb 2014 08:57:59 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Blanchet In-Reply-To: Date: Wed, 12 Feb 2014 08:57:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <47CBA1D2-E875-4DE3-81C3-ABDCE0A1C05C@viagenie.ca> References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> <0D6BE438-4886-44EC-963C-0F7EC20284A0@viagenie.ca> To: Mark Nottingham X-Mailer: Apple Mail (2.1827) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 13:58:03 -0000 Le 2014-02-11 =E0 23:49, Mark Nottingham a =E9crit : >=20 > On 12 Feb 2014, at 1:09 am, Marc Blanchet = wrote: >=20 >> yes. that is another way. it provides an additional level of = indirection to remove the url component out from the spec. but it = actually overload the registry with more data than typically necessary, = and pretty repetitive. i.e. most likely every registry will have rel: = domainlookup href-template: = http://exampleregistry1.com/lookup/{domain}, rel: domainlookup = href-template: http://exampleregistry2.com/lookup/{domain}, rel: = domainlookup href-template: = http://exampleregistry3.com/lookup/{domain}. Given the number of TLDs = and that there are about 10 objects, we are multiplying the entries by = 10, becomes pretty large registry operationally to parse. >=20 > Perhaps, but it may be possible to mitigate that, depending on the = particulars of how it's going to be used and deployed. >=20 > E.g., have IANA run a lookup service themselves; e.g., = http://iana.org/rdap/domain/foo.com >=20 > Or, define a document format that IANA points to in the registry, and = *it* points to the various endpoints.=20 I would suggest that you bring these discussion points to the weirds = mailing list. The topic of bootstrap with various methods have been = subject to many discussions so far. Not that we thought about = everything, but some of your suggestions has been already debated. = There were no perfect solution, it has been a compromise between = various.=20 >=20 > Also, if the data is that voluminous, it suggests that you may have a = problem anyway; adding such repetitive information shouldn't affect the = size of the response after gzip (which you'd want to use in any case) = that much. it is not the size of the response. it is the parsing. some of the use = cases are clients that are doing a _lot_ of requests. Again, I think you = should bring these discussion points to the weirds mailing list. =20 >=20 >>> I'm very curious to hear what other APPS folks think about this -- = especially those of a Web bent. We're trying to line up some = conversations about this in London, and I'd like to inform them with the = WG's perspective, rather than just my own. >>=20 >> btw, "them/they", "we": we are the same IETF people. Why are we = talking the "them" and "we" perspective? >=20 > Strangely, we *do* organise ourselves into groups and areas here. right. but "we" are the same people. anyway. let's not continue that = thread.=20 Regards, Marc. > Or are you proposing something more radical? >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 From mnot@mnot.net Wed Feb 12 17:08:55 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C5E1A00B6 for ; Wed, 12 Feb 2014 17:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFdY7fU6iCWX for ; Wed, 12 Feb 2014 17:08:50 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9631A00A9 for ; Wed, 12 Feb 2014 17:08:50 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.47.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AA9EA22E253; Wed, 12 Feb 2014 20:08:46 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: <47CBA1D2-E875-4DE3-81C3-ABDCE0A1C05C@viagenie.ca> Date: Thu, 13 Feb 2014 12:08:43 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> <0D6BE438-4886-44EC-963C-0F7EC20284A0@viagenie.ca> <47CBA1D2-E875-4DE3-81C3-ABDCE0A1C05C@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1827) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 01:08:55 -0000 On 13 Feb 2014, at 12:57 am, Marc Blanchet = wrote: >=20 > I would suggest that you bring these discussion points to the weirds = mailing list. The topic of bootstrap with various methods have been = subject to many discussions so far. Not that we thought about = everything, but some of your suggestions has been already debated. = There were no perfect solution, it has been a compromise between = various.=20 I suspected that was the case; like I said, there are a number of ways = you can do this, with tradeoffs. My main concern is that definitely bad = practices are avoided, mostly because of the precedent that sets when it = becomes a standard. I'm a little reluctant to get involved too deeply in the discussions on = WEIRDS, because I'm already over-committed, and I don't really have much = interest in the problem domain itself -- my interest (beyond that = expressed above) is validating what's in the get-off-my-lawn draft = (which is why I started the thread). I've been talking to a few people about getting some folks together to = talk about this over coffee / beer / cookies / whatever in London; to = me, that's better than bringing it up in the WG, which will probably = waste a fair amount of time (since it may very well be ground that = you've already been over). Cheers, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Feb 12 17:35:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDBE1A00A2 for ; Wed, 12 Feb 2014 17:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqUh2jYnAC-q for ; Wed, 12 Feb 2014 17:34:58 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id ADC131A0083 for ; Wed, 12 Feb 2014 17:34:58 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.47.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1664822E1FA; Wed, 12 Feb 2014 20:34:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: <20140211223250.68983.qmail@joyce.lan> Date: Thu, 13 Feb 2014 12:34:50 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140211223250.68983.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1827) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 01:35:01 -0000 It's this attitude that I (and apparently other Web folks here) find = disturbing -- to paraphrase, "we're building a new protocol, so we don't = have to worry about what we do to the Web." Because WEIRDS has opted into using HTTP and URIs, it's opted into the = Web, and that means it shouldn't harm other uses of the Web. Squatting on URIs is bad practice on the Web. Requiring implementations = to use certain URI patterns is bad practice on the Web. And so on. While there may be no existing RDAP servers, the Web is pre-existing = (and doing pretty well). If WEIRDS doesn't want to honour its = architectural constraints, that's fine -- RDAP can use or define = something else. Cheers, On 12 Feb 2014, at 9:32 am, John Levine wrote: >> domain: example.com >> rel: domainlookup href-template: = http://example.com/lookup/{domain} >>=20 >> I'm very curious to hear what other APPS folks think about this >=20 > RDAP is a new design. There are no existing RDAP servers other than a > few prototypes run by people on the WEIRDS list. There's nothing to > be backward compatible with. =20 >=20 > RDAP is intended as a replacement for WHOIS, to answer the same > questions that people ask now using WHOIS, e.g. information about > domain names, IP addresses, ASNs, and a few other things. The > questions that people ask with WHOIS haven't changed materially in 20 > years, and I see no reason to expect them to change in the future. >=20 > Small RDAP servers will likely adapt the RDAP prototype being funded > by ICANN. Large RDAP servers will be written by a handful of large > registries, all of which are represented on the WEIRDS list and can > speak for themselves, but I can't remember any of them showing notable > enthusiasm for templates. >=20 > In this particular application, I really can't see any benefit to > templates other than the ability to be gratuitously different just to > prove that you can. >=20 > R's, > John -- Mark Nottingham http://www.mnot.net/ From tbray@textuality.com Wed Feb 12 18:05:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862511A00AB for ; Wed, 12 Feb 2014 18:05:53 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmLwFmDS35wM for ; Wed, 12 Feb 2014 18:05:51 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id DAF741A0043 for ; Wed, 12 Feb 2014 18:05:50 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id j16so1920851vbh.24 for ; Wed, 12 Feb 2014 18:05:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eJGu4axzxXO2o6eCPIYJIhnjm57NUwJkiO5VCTvsqbA=; b=OmKzhoLU6hppp+x6ZZuE/TPdDv6xSIi8KhlJShNf57Xl16WwfVkBK4FqFqW7VH29aP ijzu6t2DXsFEmEbVPuS1vHvP8X8qAQzSCbHHt9AvdDvOCWXQhX7TdSlaSGFrc7RnwdRe cGDUKEXCRCabwRSTL5ITEv58+RVfHxP6VySxpe5FJVqlyM9dCIIxYUAF+VodDQQp/W2Z powwraKZ+2hIEg3cKgRyAvTIJL0xCvCGEMhgIrnm6DiY4qc40Gq79OgsCTrh1u0THOTt UnCg/UKVL4+iyfX+01vU9/GJxl//mbyiAJjvFnE9ImAykDajz+zA6ZMXGIsCTtMvFjWK Kd/Q== X-Gm-Message-State: ALoCoQnkUc+VbPupHxXCCmn0uO7hNhod2CD+YwUWHKbO/v2KP2eBysRRY/N7yLLkTt4lXCcMCsNr MIME-Version: 1.0 X-Received: by 10.58.168.142 with SMTP id zw14mr2363285veb.33.1392257149520; Wed, 12 Feb 2014 18:05:49 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 12 Feb 2014 18:05:49 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> Date: Wed, 12 Feb 2014 18:05:49 -0800 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=047d7b6da028d5aa5104f24020c8 Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 02:05:53 -0000 --047d7b6da028d5aa5104f24020c8 Content-Type: text/plain; charset=UTF-8 Speaking as a Web-centric sort of person and an Apps Area reviewer, if any further specs come forward that try to do a URI-space land-grab, I can promise you loud and sustained objections. On Wed, Feb 12, 2014 at 5:34 PM, Mark Nottingham wrote: > It's this attitude that I (and apparently other Web folks here) find > disturbing -- to paraphrase, "we're building a new protocol, so we don't > have to worry about what we do to the Web." > > Because WEIRDS has opted into using HTTP and URIs, it's opted into the > Web, and that means it shouldn't harm other uses of the Web. > > Squatting on URIs is bad practice on the Web. Requiring implementations to > use certain URI patterns is bad practice on the Web. And so on. > > While there may be no existing RDAP servers, the Web is pre-existing (and > doing pretty well). If WEIRDS doesn't want to honour its architectural > constraints, that's fine -- RDAP can use or define something else. > > Cheers, > > > > On 12 Feb 2014, at 9:32 am, John Levine wrote: > > >> domain: example.com > >> rel: domainlookup href-template: > http://example.com/lookup/{domain} > >> > >> I'm very curious to hear what other APPS folks think about this > > > > RDAP is a new design. There are no existing RDAP servers other than a > > few prototypes run by people on the WEIRDS list. There's nothing to > > be backward compatible with. > > > > RDAP is intended as a replacement for WHOIS, to answer the same > > questions that people ask now using WHOIS, e.g. information about > > domain names, IP addresses, ASNs, and a few other things. The > > questions that people ask with WHOIS haven't changed materially in 20 > > years, and I see no reason to expect them to change in the future. > > > > Small RDAP servers will likely adapt the RDAP prototype being funded > > by ICANN. Large RDAP servers will be written by a handful of large > > registries, all of which are represented on the WEIRDS list and can > > speak for themselves, but I can't remember any of them showing notable > > enthusiasm for templates. > > > > In this particular application, I really can't see any benefit to > > templates other than the ability to be gratuitously different just to > > prove that you can. > > > > R's, > > John > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b6da028d5aa5104f24020c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking as a Web-centric sort of person and an Apps Area = reviewer, if any further specs come forward that try to do a URI-space land= -grab, I can promise you loud and sustained objections. =C2=A0


On Wed, Feb 12, 2014 at 5:34 PM, Mark No= ttingham <mnot@mnot.net> wrote:



On 12 Feb 2014, at 9:32 am, John Levine <johnl@taugh.com> wrote:

>> domain: example.c= om
>> =C2=A0 rel: domainlookup =C2=A0 =C2=A0href-template: http://example.com/look= up/{domain}
>>
>> I'm very curious to hear what other APPS folks think about thi= s
>
> RDAP is a new design. =C2=A0There are no existing RDAP servers other t= han a
> few prototypes run by people on the WEIRDS list. =C2=A0There's not= hing to
> be backward compatible with.
>
> RDAP is intended as a replacement for WHOIS, to answer the same
> questions that people ask now using WHOIS, e.g. information about
> domain names, IP addresses, ASNs, and a few other things. =C2=A0The > questions that people ask with WHOIS haven't changed materially in= 20
> years, and I see no reason to expect them to change in the future.
>
> Small RDAP servers will likely adapt the RDAP prototype being funded > by ICANN. =C2=A0Large RDAP servers will be written by a handful of lar= ge
> registries, all of which are represented on the WEIRDS list and can > speak for themselves, but I can't remember any of them showing not= able
> enthusiasm for templates.
>
> In this particular application, I really can't see any benefit to<= br> > templates other than the ability to be gratuitously different just to<= br> > prove that you can.
>
> R's,
> John

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

--047d7b6da028d5aa5104f24020c8-- From duerst@it.aoyama.ac.jp Wed Feb 12 18:40:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BAE1A00AB for ; Wed, 12 Feb 2014 18:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fis77k3EBVtf for ; Wed, 12 Feb 2014 18:40:55 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB081A004A for ; Wed, 12 Feb 2014 18:40:51 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s1D2ekw4023999; Thu, 13 Feb 2014 11:40:46 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0276_596c_3d83f112_9458_11e3_8460_001e6722eec2; Thu, 13 Feb 2014 11:40:46 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id AA1C7BF54F; Thu, 13 Feb 2014 11:40:45 +0900 (JST) Message-ID: <52FC309F.3000504@it.aoyama.ac.jp> Date: Thu, 13 Feb 2014 11:40:31 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <20140211223250.68983.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 02:40:58 -0000 I can only confirm what Mark and Tim said. WEIRDS may be a new protocol, but HTTP isn't, and URIs aren't new, either. Both come with quite a few good practices that have been established over the more than 20 years that these are in use now. Regards, Martin. On 2014/02/13 11:05, Tim Bray wrote: > Speaking as a Web-centric sort of person and an Apps Area reviewer, if any > further specs come forward that try to do a URI-space land-grab, I can > promise you loud and sustained objections. > > > On Wed, Feb 12, 2014 at 5:34 PM, Mark Nottingham wrote: > >> It's this attitude that I (and apparently other Web folks here) find >> disturbing -- to paraphrase, "we're building a new protocol, so we don't >> have to worry about what we do to the Web." >> >> Because WEIRDS has opted into using HTTP and URIs, it's opted into the >> Web, and that means it shouldn't harm other uses of the Web. >> >> Squatting on URIs is bad practice on the Web. Requiring implementations to >> use certain URI patterns is bad practice on the Web. And so on. >> >> While there may be no existing RDAP servers, the Web is pre-existing (and >> doing pretty well). If WEIRDS doesn't want to honour its architectural >> constraints, that's fine -- RDAP can use or define something else. >> >> Cheers, >> >> >> >> On 12 Feb 2014, at 9:32 am, John Levine wrote: >> >>>> domain: example.com >>>> rel: domainlookup href-template: >> http://example.com/lookup/{domain} >>>> >>>> I'm very curious to hear what other APPS folks think about this >>> >>> RDAP is a new design. There are no existing RDAP servers other than a >>> few prototypes run by people on the WEIRDS list. There's nothing to >>> be backward compatible with. >>> >>> RDAP is intended as a replacement for WHOIS, to answer the same >>> questions that people ask now using WHOIS, e.g. information about >>> domain names, IP addresses, ASNs, and a few other things. The >>> questions that people ask with WHOIS haven't changed materially in 20 >>> years, and I see no reason to expect them to change in the future. >>> >>> Small RDAP servers will likely adapt the RDAP prototype being funded >>> by ICANN. Large RDAP servers will be written by a handful of large >>> registries, all of which are represented on the WEIRDS list and can >>> speak for themselves, but I can't remember any of them showing notable >>> enthusiasm for templates. >>> >>> In this particular application, I really can't see any benefit to >>> templates other than the ability to be gratuitously different just to >>> prove that you can. >>> >>> R's, >>> John >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> _______________________________________________ >> 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 johnl@taugh.com Wed Feb 12 21:24:49 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902D61A00F5 for ; Wed, 12 Feb 2014 21:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95BFOwpM-eUl for ; Wed, 12 Feb 2014 21:24:48 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1821A00EF for ; Wed, 12 Feb 2014 21:24:47 -0800 (PST) Received: (qmail 99231 invoked from network); 13 Feb 2014 05:24:46 -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:user-agent:cleverness; s=1839e.52fc571e.k1402; i=johnl-iecc.com@submit.iecc.com; bh=VdyP8xZYYmitx2NIGs/FQvgOZVkBvoRsW6cQAr4Wh3Q=; b=hKtegmM8QGnzXICQOBFkO5M+oQL7Rl1prZ+PiTCLLCBszv+DW3LclmofHNiGe3sF03DC/mEdY8V9FJ5Lt3iXrN+yG6dnGES4ntn1AcDsbeopeOtRtEEiy8lcFZzowtbEMoxDfrtupDrvFImkcNgR3PQtHQUbo5YeS87y6DDYH4dRrnO5MV1eS/Xp90/EUfiQfipdS1iUxPrbZ8PEoEOvNuB3LmvP9yDLAfJLZqVWHZoSF+9dY7u+Rsv48+3oArY/ 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:user-agent:cleverness; s=1839e.52fc571e.k1402; olt=johnl-iecc.com@submit.iecc.com; bh=VdyP8xZYYmitx2NIGs/FQvgOZVkBvoRsW6cQAr4Wh3Q=; b=ObGHWOkxNiXuXtVakVSKBQA4rKXyZf1rRKwtf9uzuGgCnxprypbMuBenXjveUSHc/2XfYkI+Fu7yhTN2S254L2GZJKv19VtwWciGoaygo3vvAXMm8gB2BosC/jZd/Zw9OEjPIwGLXKV3tzlfR98ms/nORY4XKd7RLNtvgvUSzCNfKHH9+4I6yNYVzm7hjWOwU8iqASLsbuFlwrej2hOwdQncDPHml6axfPtLcPGDPzcGH0OIsrUI7fgFRZ9qLlXd Received: from [10.1.152.209] ([207.236.136.66]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 13 Feb 2014 05:24:45 -0000 Date: 13 Feb 2014 00:24:45 -0500 Message-ID: From: "John R Levine" To: "Mark Nottingham" In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> 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: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 05:24:49 -0000 > It's this attitude that I (and apparently other Web folks here) find disturbing -- to paraphrase, "we're building a new protocol, so we don't have to worry about what we do to the Web." I have no interest in breaking the web, but honestly, so far all I've seen is FUD. Can you offer a plausible scenario where RDAP would break something? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From johnl@taugh.com Wed Feb 12 21:25:47 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B181A00FD for ; Wed, 12 Feb 2014 21:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKw_Q8477m9R for ; Wed, 12 Feb 2014 21:25:46 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 72E661A00EF for ; Wed, 12 Feb 2014 21:25:46 -0800 (PST) Received: (qmail 99380 invoked from network); 13 Feb 2014 05:25:45 -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:user-agent:cleverness; s=18433.52fc5759.k1402; i=johnl-iecc.com@submit.iecc.com; bh=7z0YsEYzXBWiCAvOJhw6bydUUZoYd8Z2AdihIcQrx5Y=; b=hCaQ+a089oJatUeGATxmYh6dEavOvjo/kjkh0Xue4ztEtsq7sOdaP5suv1dl2fETz58QVHKl/sSG0tovtZ7YDpckM1ILADIl7bJ4fKjKyx/EErA/ezHDNN+1mIrUJInnShDdohu8OE+1RzKw4FawbeWBLMTYVv5+fL/baW85I5JBU6NC0vHP33uYiNoxfdhVa/M0fWQIIi9S0neTrnjmq9mh0HntTnnEkkDLh0iNGPXJgi9dsMSAUn65NONLKYSN 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:user-agent:cleverness; s=18433.52fc5759.k1402; olt=johnl-iecc.com@submit.iecc.com; bh=7z0YsEYzXBWiCAvOJhw6bydUUZoYd8Z2AdihIcQrx5Y=; b=DbMLbJ+3Ana2NuLrrx6ajHZVGcuaDf5pu+HrXlKMPppAW2C3P8Yl9iCDlKX/sN55XHOBg9LTImk6PR42XYbtJfb9RzJNgIf6Pt6GT/rQiq2Qai7cobk7VgwRi9lrLONvy10k/noM9X115yMVlmw/Be/NwmT0eDZjGQut9YLHQRRjCEMHNWmlkD3p7WzaHYxKmkq5ol7BjNWCr+Z6tpkxvuG2aqIr2CJ+u43iT79d7N6qu174X4VKkyRMGyrxMFvR Received: from [10.1.152.209] ([207.236.136.66]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 13 Feb 2014 05:25:45 -0000 Date: 13 Feb 2014 00:25:42 -0500 Message-ID: From: "John R Levine" To: "Tim Bray" In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> 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: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 05:25:48 -0000 > Speaking as a Web-centric sort of person and an Apps Area reviewer, if any > further specs come forward that try to do a URI-space land-grab, I can > promise you loud and sustained objections. Same question. I really don't see a plausible scenario where RDAP would break anything. Can you help us out with one? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From tbray@textuality.com Wed Feb 12 21:42:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235781A00F5 for ; Wed, 12 Feb 2014 21:42:29 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2Td7AL3NtnM for ; Wed, 12 Feb 2014 21:42:26 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9101A00EF for ; Wed, 12 Feb 2014 21:42:26 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id w20so7887857vbb.13 for ; Wed, 12 Feb 2014 21:42:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ti1y+0EzVzsuWIDvSt5NpeCwK9KmSslHYEpWdKdDo/8=; b=D8b/C2RaEgkTo7ad2ND6sXbieRCawOOWMmldHB4AXQ1r38atwmfLE3e5OCe+8PnCi8 6eeqZgELR78hbxfUzAQM7m8i0aq/Se9aHjcBl/JHgCy4XRDrdxwmOjXLCx2kbrh4Q9dv Sv7ABiencETpFeiwhrU53z8yIs7xtwJIa0LVVTQKfux4dnvVfy5ikwBoNImuwfm9CPrT onoQ/uy43LRR0qaJfJ1PAM0lxrdESsPP2cmV0evcJvvLXePXWDfBl8/79geFGf5JcX4d BrUjbehKT9hRP+XB9lPlNYg1F/TTaMzsIoc7Q34XLxBCtYBBftnJWVkHRMpi4DXmvcJp 0flA== X-Gm-Message-State: ALoCoQkJb337h2jxI8xmwh6TWAqyah2Qk856A5kLTgZfeBR0Aos1L7Vefk/4iTsDmV1yv5ORwdQp MIME-Version: 1.0 X-Received: by 10.52.23.68 with SMTP id k4mr15462646vdf.24.1392270145160; Wed, 12 Feb 2014 21:42:25 -0800 (PST) Received: by 10.220.98.73 with HTTP; Wed, 12 Feb 2014 21:42:25 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> Date: Wed, 12 Feb 2014 21:42:25 -0800 Message-ID: From: Tim Bray To: John R Levine Content-Type: multipart/alternative; boundary=bcaec501c4e66f1fcb04f2432784 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 05:42:29 -0000 --bcaec501c4e66f1fcb04f2432784 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Suppose my server comes with a package where I have to route endpoints based on URL parameters, so the WEIRDS requests come in to =E2=80=9C https://example.com?service=3Dweirds " so that=E2=80=99s my registry value. In this case, appending /domain/whatever is going to result in a malformed URI reference, or at least one that=E2=80=99s going to cause all the standa= rd parsing libraries trouble. On Wed, Feb 12, 2014 at 9:25 PM, John R Levine wrote: > Speaking as a Web-centric sort of person and an Apps Area reviewer, if an= y >> further specs come forward that try to do a URI-space land-grab, I can >> promise you loud and sustained objections. >> > > Same question. I really don't see a plausible scenario where RDAP would > break anything. Can you help us out with one? > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > --bcaec501c4e66f1fcb04f2432784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suppose my server comes with a package where I have to rou= te endpoints based on URL parameters, so the WEIRDS requests come in to=C2= =A0=E2=80=9Chttps://example.com?serv= ice=3Dweirds" so that=E2=80=99s my registry value. =C2=A0

In this case, appending /domain/whatever is going to result = in a malformed URI reference, or at least one that=E2=80=99s going to cause= all the standard parsing libraries trouble.=C2=A0


On Wed, Feb 12, 2014 at 9:25 PM, John R = Levine <johnl@taugh.com> wrote:
Speaking as a Web-centric sort of person and an Apps Area reviewer, if any<= br> further specs come forward that try to do a URI-space land-grab, I can
promise you loud and sustained objections.

Same question. =C2=A0I really don't see a plausible scenario where RDAP= would break anything. =C2=A0Can you help us out with one?


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

--bcaec501c4e66f1fcb04f2432784-- From arnt@gulbrandsen.priv.no Thu Feb 13 00:24:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FA11A014F for ; Thu, 13 Feb 2014 00:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRECNPCsCpxM for ; Thu, 13 Feb 2014 00:24:14 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id B83B21A017C for ; Thu, 13 Feb 2014 00:24:14 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5C470FA0078; Thu, 13 Feb 2014 08:24:12 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1392279851-18442-18441/11/10; Thu, 13 Feb 2014 08:24:11 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 13 Feb 2014 09:24:17 +0100 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: <52FC309F.3000504@it.aoyama.ac.jp> References: <20140211223250.68983.qmail@joyce.lan> <52FC309F.3000504@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 08:24:17 -0000 I don't understand this. AFAICT, IANA is serving basically a giant discovery response pointing to lookup URLs. Why would the IANA registry have to contain only foo/rdap/ip for IPv4 lookups? I don't see why the lookups have to be constrained. To look up AS31337, I retrieve the discovery response, usually from cache, and look up the right in the xml. Then I ask that URL. Sounds good. There are details I don't like. The draft indicates that I should take the URL I found in the IANA thing, append / and then my argument. Why isn't the slash already on the URL I found? And what escaping rules apply to my argument? Arnt From andy@hxr.us Thu Feb 13 03:45:13 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446D91A01F6 for ; Thu, 13 Feb 2014 03:45:13 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9LI21NQrvX7 for ; Thu, 13 Feb 2014 03:45:11 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2815D1A01B4 for ; Thu, 13 Feb 2014 03:45:11 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id rd3so10638801pab.2 for ; Thu, 13 Feb 2014 03:45:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wMOUOmHf49xxZ8vUPx8kTVoiOVWOIQKHfmQG257HY+E=; b=J74OPLq6XnSRrZXZA5y4EywZBAPRWFxiHH2YDWilBT57coYWhyd8kvaCtaRG2P4nak rf5XBBZTg7iXrmlyySJAOZNZJAH3nTGzafJqRGK8b9pnIOAQsMJzg4OKrfMhmKZcc9i9 shY4vOjQ/f1lchgOdd+KocwLshjH6W/+TYP+BEoNt6UoEBwEeXGpSmTDpgjyGFLiiex8 9aI32Slfe//BD++V0X+qK7vgALHOcFZoBzXEK14BJLafTeeRQbnA0tgfdOS29gV9eur7 M/e6UKIot5BjYQu7/Se5bgnbz9v6m2hSze5L2bjjvbSRWbr9Vf3ql0ezoZoE+/VLrk4n 1Wlw== X-Gm-Message-State: ALoCoQn9FWhgMKMw410XBjMpADYS5iYd3pD2OOTxBcjOgkNYlCcpLVly+4SvYkfdQX2SStnioDVI MIME-Version: 1.0 X-Received: by 10.68.202.8 with SMTP id ke8mr1272334pbc.86.1392291909813; Thu, 13 Feb 2014 03:45:09 -0800 (PST) Received: by 10.68.143.4 with HTTP; Thu, 13 Feb 2014 03:45:09 -0800 (PST) X-Originating-IP: [108.45.162.177] In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> Date: Thu, 13 Feb 2014 06:45:09 -0500 Message-ID: From: Andrew Newton To: Tim Bray Content-Type: text/plain; charset=ISO-8859-1 Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 11:45:13 -0000 I don't understand this example. Doesn't it suppose that every web application client, past, present, and future, uses templates? Since that is not true and will never be true, this does not seem like a valid point. -andy On Thu, Feb 13, 2014 at 12:42 AM, Tim Bray wrote: > Suppose my server comes with a package where I have to route endpoints based > on URL parameters, so the WEIRDS requests come in to > "https://example.com?service=weirds" so that's my registry value. > > In this case, appending /domain/whatever is going to result in a malformed > URI reference, or at least one that's going to cause all the standard > parsing libraries trouble. > > > On Wed, Feb 12, 2014 at 9:25 PM, John R Levine wrote: >>> >>> Speaking as a Web-centric sort of person and an Apps Area reviewer, if >>> any >>> further specs come forward that try to do a URI-space land-grab, I can >>> promise you loud and sustained objections. >> >> >> Same question. I really don't see a plausible scenario where RDAP would >> break anything. Can you help us out with one? >> >> >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From GK@ninebynine.org Thu Feb 13 04:06:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C931A0203 for ; Thu, 13 Feb 2014 04:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ISE6373B5E2 for ; Thu, 13 Feb 2014 04:06:05 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDCC1A01FA for ; Thu, 13 Feb 2014 04:06:05 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WDv3I-00063g-nh; Thu, 13 Feb 2014 12:06:00 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WDv3H-0007Ee-9X; Thu, 13 Feb 2014 12:06:00 +0000 Message-ID: <52FCB4F7.7030805@ninebynine.org> Date: Thu, 13 Feb 2014 12:05:11 +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: Mark Nottingham References: <20140211223250.68983.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 12:06:08 -0000 +1 to what Mark says. [later, on seeing some of the responses to this...] A question I have (not having read your specs, and not intending to) is this: are you defining a specific *service*, or are you defining a protocol that others may use to deliver a service over the web? If the former, then maybe there's not so much harm here, but it's not clear to me why this is seen as a potential IETF standard. I.e. you define a service, and you define the URIs that will be used to access it. Fine, it's your lawn. But if you are defining a protocol, that tells others how to design and allocate URIs in their own URI space, then that tramples over the lawns of other web participants, and constrains their implementation and deployment choices. That's bad. #g -- On 13/02/2014 01:34, Mark Nottingham wrote: > It's this attitude that I (and apparently other Web folks here) find disturbing -- to paraphrase, "we're building a new protocol, so we don't have to worry about what we do to the Web." > > Because WEIRDS has opted into using HTTP and URIs, it's opted into the Web, and that means it shouldn't harm other uses of the Web. > > Squatting on URIs is bad practice on the Web. Requiring implementations to use certain URI patterns is bad practice on the Web. And so on. > > While there may be no existing RDAP servers, the Web is pre-existing (and doing pretty well). If WEIRDS doesn't want to honour its architectural constraints, that's fine -- RDAP can use or define something else. > > Cheers, > > > > On 12 Feb 2014, at 9:32 am, John Levine wrote: > >>> domain: example.com >>> rel: domainlookup href-template: http://example.com/lookup/{domain} >>> >>> I'm very curious to hear what other APPS folks think about this >> >> RDAP is a new design. There are no existing RDAP servers other than a >> few prototypes run by people on the WEIRDS list. There's nothing to >> be backward compatible with. >> >> RDAP is intended as a replacement for WHOIS, to answer the same >> questions that people ask now using WHOIS, e.g. information about >> domain names, IP addresses, ASNs, and a few other things. The >> questions that people ask with WHOIS haven't changed materially in 20 >> years, and I see no reason to expect them to change in the future. >> >> Small RDAP servers will likely adapt the RDAP prototype being funded >> by ICANN. Large RDAP servers will be written by a handful of large >> registries, all of which are represented on the WEIRDS list and can >> speak for themselves, but I can't remember any of them showing notable >> enthusiasm for templates. >> >> In this particular application, I really can't see any benefit to >> templates other than the ability to be gratuitously different just to >> prove that you can. >> >> R's, >> John > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From johnl@taugh.com Thu Feb 13 06:25:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CE41A0296 for ; Thu, 13 Feb 2014 06:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kXYw7vdcPmA for ; Thu, 13 Feb 2014 06:25:38 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 08D031A01EB for ; Thu, 13 Feb 2014 06:25:37 -0800 (PST) Received: (qmail 86411 invoked from network); 13 Feb 2014 14:25: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:references:mime-version:content-type:content-id:user-agent:cleverness; s=1518a.52fcd5e0.k1402; i=johnl-iecc.com@submit.iecc.com; bh=M69rFIjjSDTPc14PxM651opFmRqNOYIzEyxl3MdxFQM=; b=clUbwB8KVJjGhFmlS5OtUQ6udLZl2/mx+wBbTuG4z+ZyHMdVA13BScjPsMr4D3qAcVvuIwWVx/ahV/Who7ArgyWUoZk90SMOf9vnfI950gye/lx2ScygVJft43RBcVFGInIU4+1QJVNC1RnDcMR1Z2On+B+mahxiLCI1Y9CmXy5g3Guab1B7pXgWZNxfnIGDx0TcOOhNNQ2OAYZVhyuBKkXIZNPrbUksGF4d2I0pTHW8dzxYXKX4ZcZfn+CHeY0j 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:content-id:user-agent:cleverness; s=1518a.52fcd5e0.k1402; olt=johnl-iecc.com@submit.iecc.com; bh=M69rFIjjSDTPc14PxM651opFmRqNOYIzEyxl3MdxFQM=; b=cU4N/4HMI2oqxhao47TkpKDpnP5muhkzaJG7nILLcu6C1dbNb9tyLA12GtdB006djQETlbg3XPvA9WDBpgkeCDlAOiX1Fp/74g/IfMMsiyHBedcWVwShtZTvOIcS0Fo5BCrZF9qxp16grq/vwAjCuCIzQnivNg7xsHbRBhaxGxLyTkNItMTSqHLzPP6Qcmc7sCUtA6/FfNJdCe2++7CaG93qxkCumolTH9eNxiyMcmepW6srWjkM3tGk6jkS1fr3 Received: from [10.255.254.1] ([76.71.216.36]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 13 Feb 2014 14:25:36 -0000 Date: 13 Feb 2014 09:25:34 -0500 Message-ID: From: "John R Levine" To: "Tim Bray" In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-1879703968-1392294567=:2084" Content-ID: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 14:25:40 -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-1879703968-1392294567=:2084 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: My, I seem to have kicked a hornet's nest here. First, I am not speaking for WEIRDS, just for myself here. If I seem to have a bad attitude, I suppose I do. If you've ever tried to do anything that deals with the DNS, you'll have run into DNS fundamentalists, for whom the answer is to use a new RRTYPE, pretty much regardless of what the question was, and in at least one case (SPF) doing so broke the protocol. When I hear that we have to use templates, the situation feels not altogether dissimilar. The advice in the get off my lawn draft reads to me as "some web servers are amazingly lame, so web clients have to use templates to deal with it." I certainly believe the first part, but it is not obvious that the second part is always the correct response. > Suppose my server comes with a package where I have to route endpoints > based on URL parameters, so the WEIRDS requests come in to > "https://example.com?service=weirds > " so that’s my registry value. Why wouldn't it be reasonable to say if you want to run RDAP, use a server that can support it? We expect there to be vastly more RDAP clients than servers, so it seems perverse to push complexity into the clients. With regard to Graham's question, I'd say RDAP is a service. It defines the queries, and it defines the return codes and blobs of JSON that come back. If you are not a domain or IP registry, it's hard to think of a reason to run it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. --3825401791-1879703968-1392294567=:2084-- From simon.perreault@viagenie.ca Thu Feb 13 06:28:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8ED1A0252 for ; Thu, 13 Feb 2014 06:28:40 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ugAjN37-jBq for ; Thu, 13 Feb 2014 06:28:39 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 36C311A0240 for ; Thu, 13 Feb 2014 06:28:39 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 027E240222 for ; Thu, 13 Feb 2014 09:28:37 -0500 (EST) Message-ID: <52FCD695.4010806@viagenie.ca> Date: Thu, 13 Feb 2014 09:28:37 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140211223250.68983.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 14:28:41 -0000 Le 2014-02-13 00:42, Tim Bray a écrit : > Suppose my server comes with a package where I have to route endpoints > based on URL parameters, so the WEIRDS requests come in > to “https://example.com?service=weirds" so that’s my registry value. > > In this case, appending /domain/whatever is going to result in a > malformed URI reference, or at least one that’s going to cause all the > standard parsing libraries trouble. Probably a naive question, just trying to understand: couldn't you reverse proxy that server with a front-end that would rewrite the URIs? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Feb 13 13:27:29 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB851A048E for ; Thu, 13 Feb 2014 13:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT7NxxAWd08G for ; Thu, 13 Feb 2014 13:27:26 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id DA27C1A0429 for ; Thu, 13 Feb 2014 13:27:26 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id C611F2005D107 for ; Thu, 13 Feb 2014 13:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=NMqyXjBWfQ/3G9OoWBrxt9mu6A4=; b=l8drkaYSmHg 3317dAmswO/04bMU4TlXBJ/Zx3pKtmqux/fkBWSSfj07XKVaJrSNNfGgpMIrRiyq Jg73jL0GyvkgtCyHkTER0XwAXRuArZac3PUTfrmipynOptOrv6ZCRiorJb/6CfYD 2AD/71/+7mFPq/GMXySMyIrl0mGfdXhw= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 70A4E2005D101 for ; Thu, 13 Feb 2014 13:27:25 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id cc10so9279548wib.10 for ; Thu, 13 Feb 2014 13:27:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DOJJX137Ui9M9YY8MVh5viBzG3nnPa+jvvPMr4xMrXI=; b=IwbB9pxtShdmmUdODa2v6G3abxEVylOJ5Yhd/5/umdvNu67qmn3/IWVsgZcNFH3mqX blb0s1i6YRql952UpgAtFmuGqNsKu+70u6EsBnDl03mBaerRAUQnnq7+Ku4a3ZBJqCsV dmmi1OUu+MLYL24R+3P6mNc74mkyRJUU/5VvO0gMdaw2UbbtdBEXOZIQzoxrvHf7fwdE h8aHbeQ2PA/ZNvPEZGmHfhea0kRZL8sBvk6VpIqFgQVzWwdORrFqkuPcnMhA9baMC9lR AzCpj/OLPJXWHWu+Y3HcljZ1wAYyLA4/wCHqScnl/g3SwCuAK4zaK4imo1BLz9GqMc7t eCyA== MIME-Version: 1.0 X-Received: by 10.194.85.168 with SMTP id i8mr228524wjz.81.1392326843661; Thu, 13 Feb 2014 13:27:23 -0800 (PST) Received: by 10.217.108.132 with HTTP; Thu, 13 Feb 2014 13:27:23 -0800 (PST) In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> Date: Thu, 13 Feb 2014 15:27:23 -0600 Message-ID: From: Nico Williams To: John R Levine Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/WiZrXdWjh2GMOm7gz_mS_PhxMys Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 21:27:29 -0000 On Thu, Feb 13, 2014 at 8:25 AM, John R Levine wrote: > My, I seem to have kicked a hornet's nest here. Maybe. Perhaps the get-off-my-lawn argument needs some fleshing out. Clearly there are people who don't see how it follows from the stated principles. > The advice in the get off my lawn draft reads to me as "some web servers = are > amazingly lame, so web clients have to use templates to deal with it." I > certainly believe the first part, but it is not obvious that the second p= art > is always the correct response. I don't share this impression. >> Suppose my server comes with a package where I have to route endpoints >> based on URL parameters, so the WEIRDS requests come in to >> "https://example.com?service=3Dweirds " >> so that=E2=80=99s my registry value. > > Why wouldn't it be reasonable to say if you want to run RDAP, use a serve= r > that can support it? We expect there to be vastly more RDAP clients than > servers, so it seems perverse to push complexity into the clients. I think the harm from specifying baked-in local parts of URIs is that they might collide with other pre-existing and unrelated local parts of URIs on the servers that might want to run RDAP some day. I.e., if I run foo.example and RDAP would make me displace an existing resource at foo.example, that'd be bad for me. ISTM that what's needed here is a method for discovering where the RDAP service is hosted on foo.example. A well-known URI would seem appropriate. Note that any discovery method not based on DNS is going to add round trips -- I don't know how important that is to RDAP, or that HTTP is a good choice if latency matters a lot to RDAP anyways. > With regard to Graham's question, I'd say RDAP is a service. It defines = the > queries, and it defines the return codes and blobs of JSON that come back= . > If you are not a domain or IP registry, it's hard to think of a reason to > run it. Yeah, but if you own a domain you're probably running an HTTP service and some apps on it, and RDAP is stepping on your lawn. If this sets a precedent that one should not run anything but "standard apps" in some domainnames, then that'd be extra bad (and definitely counter to current practice). It'd be much better to not do this. Nico -- From nobody Fri Feb 14 06:03:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9811A0269 for ; Fri, 14 Feb 2014 06:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGJtdyYSfKjM for ; Fri, 14 Feb 2014 06:03:32 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id F1E341A026D for ; Fri, 14 Feb 2014 06:03:31 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s1EE3E8a009653; Fri, 14 Feb 2014 14:03:19 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1EE3Duo010150; Fri, 14 Feb 2014 14:03:13 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1EE3DEb016772; Fri, 14 Feb 2014 14:03:13 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s1EE3Cs0016768; Fri, 14 Feb 2014 14:03:12 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Tim Bray References: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 14 Feb 2014 14:03:12 +0000 In-Reply-To: (Tim Bray's message of "Tue\, 11 Feb 2014 10\:53\:54 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BrqYCE2ivW3JinE7zWKqblBVWAM Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 14:03:37 -0000 Tim Bray writes: > [wrt 2.2] > How about something like > > [UNICODE] defines several =E2=80=9Cencoding forms=E2=80=9D, namely UTF-8,= UTF-16, and > UTF-32. UTF-8 is a serialization. Note that UTF-16 XML documents may be > serialised into MIME entities in ... [also loses the information-free > sentence about the spec following the =E2=80=9Cprecedent=E2=80=9D] How about [UNICODE] defines three "encoding forms", namely UTF-8, UTF-16, and UTF-32. As UTF-8 can only be serialized in one way, the only possible label for UTF-8-encoded documents when serialised into MIME entities is "utf-8". UTF-16 XML documents, however, can be serialised into MIME entities in one of two ways: either big- endian, labelled (optionally) "utf-16" or "utf-16be", or little- endian, labelled (optionally) "utf-16" or "utf-16le". and add the following (removing the earlier verrsion from 3.1), per my reply to SM: UTF-32 has four potential serializations, of which only two (UTF-32BE and UTF-32LE) are given names in in [UNICODE]. Support for the various serializations varies widely, and security concerns about their use have been raised. The use of UTF-32 is NOT RECOMMENDED for XML MIME entities. >> > I also think I disagree with my guess as what it=E2=80=99s trying to >> > say. I tend to think the tools are going to do a better job of figuri= ng >> > out the right charset labeling than your typical document author. >> >> Really? Neither of the above-mentioned tools will do the 'right' >> thing with my XHTML by default, for example. >> > > Ah, I got it finally; as the other thread said, what this is *really* > talking about is configuring your web server and so on. So this is OK, > except for I think the word =E2=80=9Cauthor=E2=80=9D is misleading since = document authors > shouldn=E2=80=99t be expected to understand Unicode encodings or webserver > considerations. So maybe something like: > > XML MIME producers are RECOMMENDED to provide means to control what value, > if any, is given to charset parameters for XML MIME entities, for example > by enabling Web server configuration of filename-to-Content-Type-header > mappings on a file- by-file or suffix basis. Thanks, that works. >> > What does being =E2=80=9Cauthoritative=E2=80=9D mean concretely? Is i= t the RFC=E2=80=99s >> > recommendation that the receiver SHOULD refuse to parse the the XML ev= en >> > though it could? If so, we should say so explicitly. >> >> No -- 'authoritative' means 'answers the question "how to determine >> the encoding with which to attempt to process the entity"'. So the >> RFC is telling you how to process the entity, which is its job, after >> all. >> > > RIght, but it feels bizarre and sort of against the spirit of Postel=E2= =80=99s law > to remain completely silent about what happens when there are conflicts. = I > suggest you simply say that in the case of conflict, interoperability can > suffer since the observed behavior of receiving software is unpredictable. > This reinforces your central thrust, which is: Don=E2=80=99t do this. OK - will do, by clarifying that by 'authoritative' is meant 'do it this way', while acknowledging that this will not (cannot) _always_ do the 'right' thing. >> > Then in the example in 9.8, draft says =E2=80=9Call processors will tr= eat the >> > enclosed entity as iso-8859-1 encoded. That is, the "UTF-8" encoding >> > declaration will be ignored.=E2=80=9D Is this really true in practice= ? I >> suspect >> > not; so perhaps you should say =E2=80=9Call processors which conform t= o this >> > specification will=E2=80=9D. >> >> I could make it 'conformant processors', but the whole point of a >> media type specification is to describe the behaviour of conformant >> processors. . . >> > > It bothers me that the assertion, as stated, is simply wrong, and I don= =E2=80=99t > think RFCs should contain assertions which are empirically false. It=E2= =80=99s > fairly common in the RFCs that I say to note that conformant > implementations will do thus and so. Happy to make the change. Will see if it is needed/feels right in other examples. ht --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From nobody Fri Feb 14 07:14:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8391A0260 for ; Fri, 14 Feb 2014 07:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnHxFViq85ru for ; Fri, 14 Feb 2014 07:14:52 -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 0F9B71A0253 for ; Fri, 14 Feb 2014 07:14:52 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.133.236]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s1EFEaAx021131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 07:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1392390889; bh=FoVCmoESCo5moOaM8Ul95SfQMx9whBRrl1BnHpchoAM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hPdQGWg3lm3NW1Lqna2plSaBTp5LCY76VDcrDfjb3Atg8rHySXNZJfnjou4dfqasc el0Ld8xdBWqSUjSUePpJHTXq1hX3SNj8ECH8Yh5ckqQsMYeB8yEg+wu7gfvzSqmeBD PjcDUG1EoQOmgkLcK5ershRX7+QfO1BVCFWNfVDU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1392390889; i=@elandsys.com; bh=FoVCmoESCo5moOaM8Ul95SfQMx9whBRrl1BnHpchoAM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fRDWDcrikDbooKn7/ISZtQwZGjRPmNpsGq66IS7cBkBLb8yTbCXSZP4Mfrkl8VLRJ 0WBcvhlnt0ZXCnKS94eYyMsRwT8FTCI5v21DdsTMct2aN6VxJfV61/ZDuRl9VcvdB+ WJudb9tWjhfZRnBqZWhuTftI7bQ45V4X+zDscfzg= Message-Id: <6.2.5.6.2.20140214062237.0b3bfbe0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Feb 2014 07:07:40 -0800 To: ht@inf.ed.ac.uk (Henry S. Thompson) From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20140110142955.0ac73048@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1fry83nUIXGOoXqjyybGPmHp9wU Cc: Chris Lilley , apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-xml-mediatypes-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 15:14:56 -0000 Hi Henry, At 07:23 11-02-2014, Henry S. Thompson wrote: > > In Section 3.1: > >So, good point -- There's a subtle issue here which I should try to >clarify. We have > > MIME agents (producers or consumers) > 1) Which are also XML processors, i.e. XML-aware > 2) Which are not XML processors, i.e. not XML-aware > 2a) Which are none-the-less good MIME citizens, i.e. they try to > conform to _all_ media-type registrations to the extent that > they can, and they are therefore trying to conform to this one. > 2b) The real ignorant remnant, for whom by definition nothing > here is relevant. > >How much detail is needed in this regard in the spec? A good MIME citizen (2a) can try to conform to all media-type registrations. It is not possible to do that in practice as there can be new media-type registrations after the code is deployed. It is also more work for the implementer as he or she would have to read a lot of specifications to identify the requirements to be followed. Some of these implementations might be like 2b. I'll quote the requirement: "XML-unaware MIME producers MUST NOT supply a charset parameter with an XML MIME entity unless the entity's character encoding is reliably known." What happens when that producer supplies a charset parameter with XML entity when the entity's character encoding is not reliably known? That's the angle I would look at. I think that it is better not to get into that level of detail (see Point 1 and 2). >Maybe, as for the following para., this is just too much of an >in-crowd thing. What it _means_ to those of us who have struggled >with this situation for the last 10 years is "Sysadmins: do _not_ >configure your apache servers to serve XML and/or XHTML with a charset >param of iso-8859-1 by default unless you _really_ know what your >users are shipping" Ok. >Person, but see reply to Tim Bray and above. Ok. > > "The use of UTF-32 is NOT RECOMMENDED for XML MIME entities." > > > > I suggest having a short explanation about why the use of UTF-32 is > > not recommended instead of only saying that it is not recommended. > >Care to suggest some wording? Seriously, my understanding is that the >main reason is that most (all?) of the major browsers have removed >support for UTF-32, often citing security considerations which I don't >fully understand. . . So, is something along the following lines >sufficient? > > UTF-32 is not widely supported, and security concerns about its use > have been raised. Accordingly, the use of [as before]. The above text looks good. I'll try and suggest alternate wording if it is needed. The reason I flagged this is it can come up as an issue during IESG Evaluation. >I could repeat it, but I hate duplicating normative prose. . . Ok. > > Would a XML-unaware MIME consumer be following this specification? > >I hope so, see above. I don't feel strongly about this. I suggest getting other people to weight in (if they have not done so) and choose whatever has agreement. >Fair enough. This is very old prose, which I hadn't touched. At >least the UTF-8 advice should be repeated. Ok. >I'll get rid of the double negation. Ok. >Good idea -- I'll leave an introductory bit, so the 8.2 doesn't come >completely out of the blue. Ok. > > I suggest moving the examples in Section 9 to an appendix. > >They were in a main section in 3023, and I'd rather not -- do you feel >strongly? Does anyone else, either way? I do not feel strongly about that. Regards, S. Moonesamy From nobody Fri Feb 14 08:15:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C91A02D3 for ; Fri, 14 Feb 2014 08:15:45 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg-Mni-08i1B for ; Fri, 14 Feb 2014 08:15:42 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 38A401A0322 for ; Fri, 14 Feb 2014 08:15:28 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id oy12so9802036veb.37 for ; Fri, 14 Feb 2014 08:15:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SbWpBFca73ipOORz3SrTiv05615O/19PzYhOGZvtd1U=; b=hcYWw+AiqwItUGpxxCQEzUsc4V4/5a8Ah9s9NvR3rJc9YU44q/Es48As+JDSvKIKUJ en2HfZE0o6zZ0nIr15LvmWQ/uXoi/yCMK1R0TIoGZfydQ7N+R4yi7ZKYKaV1JEFzOkXx XB+ZfXb8+sX9E5tkiaRgdr177JBVmPNgWRcF7bx7dwpnAepRUGK+tuN4LBu17esdXNPl RtePX3eUDNApQGTGSKIj4B++wJ+joerYez5a/s6h56b2kKJTb0DEvgrJMSxb8tZrD9Oq cC/cEEGh1NW+cWtoKRS12OPHb/vtt8nRcb8Qph656jiZ0+17jn32vg6F+lr2ws0HdsIy IESQ== X-Gm-Message-State: ALoCoQmafnx2Tr1YfYH4f465pok5wGvzhw6y55dAm1g9DMOngKmWKDLg/csAWEy2YG9LfrdWpcsi MIME-Version: 1.0 X-Received: by 10.220.182.137 with SMTP id cc9mr35936vcb.62.1392394526344; Fri, 14 Feb 2014 08:15:26 -0800 (PST) Received: by 10.220.98.73 with HTTP; Fri, 14 Feb 2014 08:15:26 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20140206183642.28098.24139.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 08:15:26 -0800 Message-ID: From: Tim Bray To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=089e0149c3ce21602204f2601d45 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8Iou-ecZ7nb53szzpew-36syhE4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 16:15:45 -0000 --089e0149c3ce21602204f2601d45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 14, 2014 at 6:03 AM, Henry S. Thompson wrote: > Tim Bray writes: > > How about > > [UNICODE] defines three "encoding forms", namely UTF-8, UTF-16, and > UTF-32. As UTF-8 can only be serialized in one way, the only possible > label for UTF-8-encoded documents when serialised into MIME entities > is "utf-8". UTF-16 XML documents, however, can be serialised into > MIME entities in one of two ways: either big- endian, labelled > (optionally) "utf-16" or "utf-16be", or little- endian, labelled > (optionally) "utf-16" or "utf-16le". > Excellent. > > RIght, but it feels bizarre and sort of against the spirit of Postel=E2= =80=99s > law > > to remain completely silent about what happens when there are conflicts= . > I > > suggest you simply say that in the case of conflict, interoperability c= an > > suffer since the observed behavior of receiving software is > unpredictable. > > This reinforces your central thrust, which is: Don=E2=80=99t do this. > > OK - will do, by clarifying that by 'authoritative' is meant 'do it > this way', while acknowledging that this will not (cannot) _always_ do > the 'right' thing. > Fair enough. Do consider mentioning unpredictable behavior, I=E2=80=99ve fo= und that useful in explaining why something is a good idea, and in this case it has the virtue of being true. > --089e0149c3ce21602204f2601d45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 14, 2014 at 6:03 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
Tim Bray writes:

How about

=C2=A0 [UNICODE] defines three "encoding forms", namely UTF-8, UT= F-16, and
=C2=A0 UTF-32. As UTF-8 can only be serialized in one way, the only possibl= e
=C2=A0 label for UTF-8-encoded documents when serialised into MIME entities=
=C2=A0 is "utf-8". =C2=A0UTF-16 XML documents, however, can be se= rialised into
=C2=A0 MIME entities in one of two ways: either big- endian, labelled
=C2=A0 (optionally) "utf-16" or "utf-16be", or little- = endian, labelled
=C2=A0 (optionally) "utf-16" or "utf-16le".

Excellent.
=C2=A0
> RIght, but it feels bizarre and sort of against the sp= irit of Postel=E2=80=99s law
> to remain completely silent about what happens when there are conflict= s. =C2=A0I
> suggest you simply say that in the case of conflict, interoperability = can
> suffer since the observed behavior of receiving software is unpredicta= ble.
> =C2=A0This reinforces your central thrust, which is: Don=E2=80=99t do = this.

OK - will do, by clarifying that by 'authoritative' is meant = 'do it
this way', while acknowledging that this will not (cannot) _always_ do<= br> the 'right' thing.

Fair enough.= Do consider mentioning unpredictable behavior, I=E2=80=99ve found that use= ful in explaining why something is a good idea, and in this case it has the= virtue of being true.


--089e0149c3ce21602204f2601d45-- From nobody Fri Feb 14 11:46:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4388E1A0375 for ; Fri, 14 Feb 2014 11:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W-_mxr_9ONi for ; Fri, 14 Feb 2014 11:46:39 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA251A0449 for ; Fri, 14 Feb 2014 11:42:04 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 994B21B4061 for ; Fri, 14 Feb 2014 11:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gebfifa1IRHvPRoWSJpv YlP0tnA=; b=XEzxP+pFtGYKDbIFEIuDiCpKxunxBdoc1vNORbPZLU9Lfb0iAULa yKUQ87OUGzyfNPn386WxRw8a/Zzd7PzDxfxTnT/hzytOYLsUjfAOJAI3uGcspK4h 152hQ1ai7OITS+CE+R+uzg/5zS2ttiEsdsD85GM12ljSPimZXRWt5ks= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 4BE9D1B405F for ; Fri, 14 Feb 2014 11:42:02 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hi5so808389wib.2 for ; Fri, 14 Feb 2014 11:42:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IWLjop8So8d53h9txL4N6azqMIJ3mgZFZtdAasLDz6Q=; b=limanf63vRHQWuYt7+Vt/gPronE0t0IdjGaZ+dIrVdmkYhEF8vC5YhDn/2yR3tmWbN IGyBCqhbX4Kj1nV/pv3nMYYcs+s5zfHcbtyvwg9QLKHhZwjnXqXhHH2MKqkzfrc90GAR BOyDtDaoU1itFaqYejhVXl+KxLzqBWumT9bwNObevpbNMfkd6gWA27q0UIDfG1pQABIB jf6j94Zcfa1e5yINqkFsJe90CxY43CqZ/nom6iwaTJ2h7UmhhT3o6V013wbMtP2fjg33 P/HC6hQmMHcHXfaI79Ij6D6HWDU7cRVawdMms7cjT51zWm8g0wE11npnqoDEJLdIxhfr 7hrw== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr7716797wjb.28.1392406920755; Fri, 14 Feb 2014 11:42:00 -0800 (PST) Received: by 10.217.108.132 with HTTP; Fri, 14 Feb 2014 11:42:00 -0800 (PST) In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> Date: Fri, 14 Feb 2014 13:42:00 -0600 Message-ID: From: Nico Williams To: John R Levine Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BurhVnqV7ZeQFs9613qKHi9X0O0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 19:46:41 -0000 On Thu, Feb 13, 2014 at 3:27 PM, Nico Williams wrote: > > I think the harm from specifying baked-in local parts of URIs is that > they might collide with other pre-existing and unrelated local parts > of URIs on the servers that might want to run RDAP some day. > > I.e., if I run foo.example and RDAP would make me displace an existing > resource at foo.example, that'd be bad for me. Checking draft-ietf-weirds-bootstrap-01, I see that the RDAP proposal does allow one to specify a fully formed base URI for the RDAP service for a given domain. Given that I fail to see the harm in specifying what resources *below* that must look like. It looks like any other HTTP API. It looks like there's no lawn squatting. But then, there's also draft-ietf-weirds-rdap-query-10, which uses well-known URIs, saying this in section 3: RDAP queries use well-known URLs [RFC5785] with the "rdap" prefix. Generally, a registry or other service provider will provide a base URL that identifies the protocol, host and port, and this will be used as a base URL that the well-known URL is resolved against, as per Section 5 of RFC 3986 [RFC3986]. For example, if the base URL is "http://example.com/", all RDAP query URLs will begin with "http://example.com/.well-known/rdap". Note that path and query information in the base URL are not used, because the well-known URL is rooted at "/.well-known/rdap"; for example, if a registry provides "http://example.com/other/path" as a base URL, RDAP query URLs will still begin with "http://example.com/ .well-known/rdap". I see nothing wrong with the first-two paragraphs. As for the third, I find that surprising. I'd expect that a well-known URI would be used to find the correct, site-local, non-well-known base URI for RDAP. In particular, the third paragraph quoted above conflicts with RFC5785, section 1.1 ("Appropriate Use of Well-Known URIs"). So there is something like URL squatting going on here, but it shouldn't be too hard to fix this. Nico -- From nobody Fri Feb 14 12:24:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83AC1A0337 for ; Fri, 14 Feb 2014 12:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1BVt8H74Za2 for ; Fri, 14 Feb 2014 12:24:36 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E841A03DC for ; Fri, 14 Feb 2014 12:24:36 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 8A724FA0090; Fri, 14 Feb 2014 20:24:33 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1392409472-16893-16892/11/6; Fri, 14 Feb 2014 20:24:32 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Fri, 14 Feb 2014 21:24:31 +0100 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <19a44afe-6888-4872-8612-6fbb4749f64b@gulbrandsen.priv.no> In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7IfHHStvgdduEuJk_fl-Efey_e8 Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 20:24:39 -0000 On Friday, February 14, 2014 8:42:00 PM CEST, Nico Williams wrote: > I'd expect that a well-known URI would be > used to find the correct, site-local, non-well-known base URI for > RDAP. The URL of the IANA registry is used to find that, AIUI. Arnt From nobody Fri Feb 14 12:39:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB791A03B9 for ; Fri, 14 Feb 2014 12:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrEJ0msbLXaq for ; Fri, 14 Feb 2014 12:39:22 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id A30DD1A0388 for ; Fri, 14 Feb 2014 12:39:22 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 309291E05D for ; Fri, 14 Feb 2014 12:39:21 -0800 (PST) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id D923B1E05C for ; Fri, 14 Feb 2014 12:39:20 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t61so9248461wes.14 for ; Fri, 14 Feb 2014 12:39:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2Ci1GyGOqp06ooVvrYhrChyH3J8N9fE17gwWsevFPX4=; b=VL7c6NY69Jq0gStGHSBRvVfB78EFDFCEzAhnnJHsNqxWVR70QptOccTPQXiKBDZB1D FtnAivKG5afzZUacW8V+i1ouLll3k3A0wlDDxne7z6rcEcjFMTAT0m6VlxTFzw7MqlrF oRdVLEOwmdQVr7PGpzdG8ORU5xM0PS7P0q3JtzFrlrbUoU51tzJwBcPza9ViSY2gPU6g t9moEIiy5XcX6XHEakQM8IxNuh6WPh5gNX9+tRdrYEx/Sr98R7jBv56g3vC+DywqgAmT Or7WxPv3Y/xIZxjdtTMDY5oD/Fu7VT/TdNSRuXDXlB0KSJaC8rAAtdviWFb9kmtw6oPL 9KQQ== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr3857523wib.5.1392410359203; Fri, 14 Feb 2014 12:39:19 -0800 (PST) Received: by 10.217.108.132 with HTTP; Fri, 14 Feb 2014 12:39:19 -0800 (PST) In-Reply-To: <19a44afe-6888-4872-8612-6fbb4749f64b@gulbrandsen.priv.no> References: <20140211223250.68983.qmail@joyce.lan> <19a44afe-6888-4872-8612-6fbb4749f64b@gulbrandsen.priv.no> Date: Fri, 14 Feb 2014 14:39:19 -0600 Message-ID: From: Nico Williams To: Arnt Gulbrandsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2FnsF-LZ_bDD7iyaE9VfrBG3iBo Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 20:39:23 -0000 On Fri, Feb 14, 2014 at 2:24 PM, Arnt Gulbrandsen wrote: > On Friday, February 14, 2014 8:42:00 PM CEST, Nico Williams wrote: >> >> I'd expect that a well-known URI would be >> used to find the correct, site-local, non-well-known base URI for >> RDAP. > > The URL of the IANA registry is used to find that, AIUI. Then why bother with well-known URIs? And if the whole base URI can be fetched from the IANA registry, then there's no name squatting going on, no lawn to get off of. I do question the scalability of IANA as a resolution service though... Does the IANA agree to be used this way?? Has the IANA been consulted about this? Also, don't we have a DNS that's meant to scale? Why is WEIRDS not using the DNS? Nico -- From nobody Fri Feb 14 12:53:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97AB1A0303 for ; Fri, 14 Feb 2014 12:53:21 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICC1_ysuYhRV for ; Fri, 14 Feb 2014 12:53:19 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE341A02C0 for ; Fri, 14 Feb 2014 12:53:19 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id hz1so12773572pad.36 for ; Fri, 14 Feb 2014 12:53:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hh3vwMFxaChYmQBMkbOBOH3kmcAnsMuSNlLkOhyPNQY=; b=kjpML/yJ4i7EP39MnHtLpGOlOpvBogBUVXc0vwBQ8//TIJTBVhlEY1YB/r6ledd2Cb uQAaa4iCtEPx72WTf9n5Q88lcG8/DHvneHQCD1C2eCkGtw0p4rrkCvi02bu48QJG/Las gLxMucp+sqMznjZlw70U1YuoRom7zQKXszHWSEyTvUcc2qML/dh56rQrnI6y9vWDj8ZE Lem036QoM0ORSl0S36CtVPMZsMZHjsHvjnc8yg38vwUObvnf/TmisBjljQBGVY673fOI 0ZojKjDPyZazAlxXwm0g9brQ3opjmYYJHMzhpAAhunRP3TEdIqaqetj9ct+fGKbujfnm LecQ== X-Gm-Message-State: ALoCoQmwVQFhMIoxXYhMDPHQvInxtBpOk6AZxqEKKtros93ETUFksyciy8XUJGTGDv8Jwxd+uefF MIME-Version: 1.0 X-Received: by 10.68.163.197 with SMTP id yk5mr11472941pbb.57.1392411198090; Fri, 14 Feb 2014 12:53:18 -0800 (PST) Received: by 10.68.143.4 with HTTP; Fri, 14 Feb 2014 12:53:17 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> <19a44afe-6888-4872-8612-6fbb4749f64b@gulbrandsen.priv.no> Date: Fri, 14 Feb 2014 15:53:17 -0500 Message-ID: From: Andrew Newton To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2p0oXSPAGWHMmtu0JhnmIBvQ-rc Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 20:53:21 -0000 On Fri, Feb 14, 2014 at 3:39 PM, Nico Williams wrote: > Then why bother with well-known URIs? > That's from a previous incarnation of helpful advice. It can probably come out now. > And if the whole base URI can be fetched from the IANA registry, then > there's no name squatting going on, no lawn to get off of. > > I do question the scalability of IANA as a resolution service > though... Does the IANA agree to be used this way?? Has the IANA > been consulted about this? > The IANA files are meant to be cached. And the IANA folks claim this is workable. > Also, don't we have a DNS that's meant to scale? Why is WEIRDS not > using the DNS? Because not everything maps cleanly into the DNS. There were other issues as well, all discussed on the WEIRDS list. -andy From nobody Fri Feb 14 12:58:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EF41A03E0 for ; Fri, 14 Feb 2014 12:58:43 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkq1eeJhneu2 for ; Fri, 14 Feb 2014 12:58:39 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A7CAC1A03D5 for ; Fri, 14 Feb 2014 12:58:39 -0800 (PST) Received: from [10.99.160.144] (out-pq-144.wireless.telus.com [216.218.29.144]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C81324040B; Fri, 14 Feb 2014 15:58:37 -0500 (EST) References: <20140211223250.68983.qmail@joyce.lan> <19a44afe-6888-4872-8612-6fbb4749f64b@gulbrandsen.priv.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <47ACA06D-67E8-424A-93FE-4F311164DCB6@viagenie.ca> X-Mailer: iPhone Mail (11B554a) From: Marc Blanchet Date: Fri, 14 Feb 2014 15:58:35 -0500 To: Nico Williams Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AaIJSt9G3b5dEwwESlYsFwWz7jU Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 20:58:45 -0000 > Le 2014-02-14 =C3=A0 15:39, Nico Williams a =C3=A9= crit : >=20 > On Fri, Feb 14, 2014 at 2:24 PM, Arnt Gulbrandsen > wrote: >> On Friday, February 14, 2014 8:42:00 PM CEST, Nico Williams wrote: >>>=20 >>> I'd expect that a well-known URI would be >>> used to find the correct, site-local, non-well-known base URI for >>> RDAP. >>=20 >> The URL of the IANA registry is used to find that, AIUI. >=20 > Then why bother with well-known URIs? >=20 > And if the whole base URI can be fetched from the IANA registry, then > there's no name squatting going on, no lawn to get off of. >=20 > I do question the scalability of IANA as a resolution service > though... Does the IANA agree to be used this way?? =20 Yes > Has the IANA > been consulted about this? Yes. See archives of weirds >=20 > Also, don't we have a DNS that's meant to scale? Why is WEIRDS not > using the DNS? Being discussed at length in weirds. I wrote multiple drafts (search draft-b= lanchet-weirds-bootstrap* ). Pros and cons. We settled on this one. Marc. >=20 > Nico > -- >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Fri Feb 14 13:15:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2581A0388 for ; Fri, 14 Feb 2014 13:15:38 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY_YP21U6K4y for ; Fri, 14 Feb 2014 13:15:36 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C94E41A0375 for ; Fri, 14 Feb 2014 13:15:36 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 5E79C2F4071 for ; Fri, 14 Feb 2014 13:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=HpN/PxH7i8uTJk7dktAI /qZ7McQ=; b=k7iFk5jMILcIg11ehD7N3MHK+81WGbJ6xI3apv4yn98VVwZj8LXg SabVLKjLr1EwzoLlViABhEJXmss4lkiVbGsG43/dE2B+af855DfekQjUM8M8vmb+ p2+gyhgdsLEeNvsrdSl48jlox6/MG8RECFb75nprXGb/pL2itM5kb6k= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 12BD52F406D for ; Fri, 14 Feb 2014 13:15:34 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l18so789363wgh.9 for ; Fri, 14 Feb 2014 13:15:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=khiKwP7z0DfB8iqDiFV/Y/8+44EodADws+sqEulf90U=; b=dZS49Z8qiDS1i0ENi3T5eeQkhLy3IHGCw62WMg7T7JizkMPzVkcWdkji9pJw7QaZ86 4eunFsPHxzGYhxVlkNgHLIk63AIg8QLDnS/RUVp5DOrhOmgF3x6c4sOLnf7mGcvCuUPL O1i6o1/JGVS1x3ldCc55/gdGY7mcRVRgHKQkaKxMm4yBTStm460odnkGg/4mj6/YrElw 9Q25cnPlqHhqUJipkqpubNfxqymt5kc8NF9QZCMPDF7SIexpmbMccIbd2j/JCnGULrZW YbTHiTC45UQb7ubLgaxagPjOLlUTjqS6zz6Lpamd4H2kJT8jS/QmFseWgwp6bI/e1Qs4 B/dw== MIME-Version: 1.0 X-Received: by 10.194.110.41 with SMTP id hx9mr8006095wjb.28.1392412533480; Fri, 14 Feb 2014 13:15:33 -0800 (PST) Received: by 10.217.108.132 with HTTP; Fri, 14 Feb 2014 13:15:33 -0800 (PST) In-Reply-To: References: <20140211223250.68983.qmail@joyce.lan> <19a44afe-6888-4872-8612-6fbb4749f64b@gulbrandsen.priv.no> Date: Fri, 14 Feb 2014 15:15:33 -0600 Message-ID: From: Nico Williams To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZAumW2FVeMKZHCIVSj_2F_1uwgY Cc: Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 21:15:38 -0000 On Fri, Feb 14, 2014 at 2:53 PM, Andrew Newton wrote: > On Fri, Feb 14, 2014 at 3:39 PM, Nico Williams wrote: >> Then why bother with well-known URIs? > > That's from a previous incarnation of helpful advice. It can probably > come out now. Yeah, my advice: rip it out. It'd be nice to get a note from Mark N. and Tim B. that yeah, there's no lawn to get off of, but don't wait for them: that's what WG, IESG, and IETF reviews are for, and neither of the I-Ds in question is even in WG LC, much less past it, so just go with it. >> I do question the scalability of IANA as a resolution service >> though... Does the IANA agree to be used this way?? Has the IANA >> been consulted about this? > > The IANA files are meant to be cached. And the IANA folks claim this > is workable. I meant scaling into the namespace... But if you're only putting TLD records in the IANA registry then yeah, it will scale. >> Also, don't we have a DNS that's meant to scale? Why is WEIRDS not >> using the DNS? > > Because not everything maps cleanly into the DNS. There were other > issues as well, all discussed on the WEIRDS list. I'd think that WHOIS stuff does! But OK, I don't care enough to look into it any further. Nico -- From nobody Fri Feb 14 14:21:39 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3DA1A0233 for ; Fri, 14 Feb 2014 14:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RSUu_5F6RkI for ; Fri, 14 Feb 2014 14:21:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3926F1A00FA for ; Fri, 14 Feb 2014 14:21:23 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.0.878.16; Fri, 14 Feb 2014 22:21:18 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0878.008; Fri, 14 Feb 2014 22:21:18 +0000 From: Dave Thaler To: "apps-discuss@ietf.org" Thread-Topic: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt Thread-Index: AQHPKcEaJNqgQQL1fEW4nlD27YvlO5q1S01ggAAFZJA= Date: Fri, 14 Feb 2014 22:21:18 +0000 Message-ID: <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(377454003)(377424004)(13464003)(76796001)(76786001)(76576001)(69226001)(87266001)(49866001)(50986001)(47976001)(47736001)(74502001)(74662001)(47446002)(31966008)(19580395003)(80976001)(74706001)(4396001)(83322001)(85306002)(19580405001)(77982001)(15202345003)(51856001)(53806001)(15975445006)(46102001)(74316001)(56776001)(54316002)(95416001)(86612001)(95666001)(54356001)(74366001)(59766001)(76482001)(87936001)(94316002)(92566001)(74876001)(81542001)(56816005)(81816001)(86362001)(90146001)(81342001)(2656002)(81686001)(65816001)(93136001)(93516002)(80022001)(33646001)(79102001)(63696002)(85852003)(94946001)(66066001)(83072002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:F0E8FDBE.8EF6E081.A4C39EAB.86E3E861.20426; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DBXGPTJvozM23r9c4kO-Tw-SRFM Subject: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 22:21:28 -0000 VGhpcyBkcmFmdCByZXBsYWNlcyBkcmFmdC1pZXRmLWlyaS00Mzk1YmlzLWlyaXJlZy0wNC4gU2lu Y2UgdGhlIElSSQ0KV0cgY2xvc2VkLCB3ZSd2ZSBnb25lIGJhY2sgdG8gaXQgYmVpbmcgYW4gaW5k aXZpZHVhbCBzdWJtaXNzaW9uLg0KVGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBzb21lIG9mIHRoZSBp c3N1ZXMgcmFpc2VkIG9uIC0wNCAoc2VlDQpkcmFmdC10aGFsZXItdXJpLXNjaGVtZS1yZWctcHMt MDEgYW5kIHRoZSBkaXNjdXNzaW9uIGF0IGxhc3QgSUVURikgYXMNCm5vdGVkIGJlbG93LiBUaGVy ZSBhcmUgc3RpbGwgYSBudW1iZXIgb2Ygb3BlbiBpc3N1ZXMgZm9yIHdoaWNoLCB3aXRoDQp0aGUg cGVybWlzc2lvbiBhbmQgaGVscCBvZiB0aGUgYXBwc2F3ZyBjaGFpcnMsIEkgaGF2ZSBmaWxlZCBp c3N1ZQ0KdHJhY2tlciB0aWNrZXRzIHRvIHRyYWNrLg0KDQpJIGhhdmUgbm90IGZpbGVkIHRpY2tl dHMgZm9yIHRoaW5ncyBhbHJlYWR5IGFkZHJlc3NlZCBpbiB0aGlzIHZlcnNpb24uDQpUaGVzZSBh cmUgZW51bWVyYXRlZCBiZWxvdywgYW5kIGlmIHRoZXJlIGFyZSBkaXNhZ3JlZW1lbnRzIG9uIGFu eQ0KdGhlbiB3ZSBjYW4gZmlsZSBhIHRpY2tldCBmb3IgaXQuDQoNCjEpIFRoZSBJUkkgV0cgcHJl dmlvdXNseSBhZ3JlZWQgdGhhdCB0aGUgZnJhZ21lbnQgY29tcG9uZW50IGlzIG5vdA0Kc2NoZW1l LXNwZWNpZmljLCBhbmQgdGhhdCB0aGUgZG9jIHNob3VsZCBiZSB1cGRhdGVkIHRvIGNsYXJpZnkg dGhhdA0KYSBzY2hlbWUgZGVmaW5pdGlvbiBzaG91bGQgb25seSBkZWZpbmUgdGhlIHNjaGVtZS1z cGVjaWZpYyBwYXJ0Lg0KVGhpcyBpcyBub3cgZG9uZSBhdCBlbmQgb2Ygc2VjdGlvbiAxLg0KDQoy KSBTaW5jZSB0aGUgSVJJIFdHIHdhcyBjbG9zZWQsIEkgcmV2ZXJ0ZWQgbW9zdCBvZiB0aGUgSVJJ LXNwZWNpZmljDQpjaGFuZ2VzIGZyb20gUkZDIDQzOTUgdGhhdCB3ZXJlIGluIGRyYWZ0LWlldGYt aXJpLTQzOTViaXMtaXJpcmVnLTA0Lg0KSSBsZWZ0IGluIHRleHQgY2xhcmlmeWluZyB0aGF0IGEg VVJJIHNjaGVtZSBuYW1lIGFuZCBhbiBJUkkgc2NoZW1lDQpuYW1lIHdlcmUgdGhlIHNhbWUgYW5k IGhlbmNlIHRoZXJlIGFyZW4ndCBzZXBhcmF0ZSByZWdpc3RyaWVzLCBzaW5jZQ0KYXBwYXJlbnRs eSB0aGF0IHdhcyBhIGNvbW1vbiBxdWVzdGlvbiBvbiBSRkMgNDM5NS4NCg0KMykgQXMgbm90ZWQg aW4gZHJhZnQtdGhhbGVyLXVyaS1zY2hlbWUtcmVnLXBzIGFuZCBpbiBteSBwcmVzZW50YXRpb24N CmF0IGxhc3QgSUVURiwgdGhlIElSSSBXRyBwcmV2aW91c2x5IGFncmVlZCB0aGF0IHRoZSA0LXdl ZWsgbWFpbGluZw0KbGlzdCByZXZpZXcgd2FzIG9wdGlvbmFsIGZvciBQcm92aXNpb25hbC4gUkZD IDQzOTUgd2FzIGFtYmlndW91cyBhcw0KdG8gb3B0aW9uYWwgdnMgbWFuZGF0b3J5LiBVcGRhdGVk IHRleHQgaW4gc2VjdGlvbiA3LjIgdG8gbWFrZSBpdA0KZXhwbGljaXQgdGhhdCBpdCBpcyBvbmx5 IG1hbmRhdG9yeSBmb3IgUGVybWFuZW50Lg0KDQo0KSBBcyBub3RlZCBpbiBkcmFmdC10aGFsZXIt dXJpLXNjaGVtZS1yZWctcHMgYW5kIGluIG15IHByZXNlbnRhdGlvbg0KYXQgbGFzdCBJRVRGLCBS RkMgNDM5NSdzIGNvbnZlbnRpb24gZm9yIHByaXZhdGUgbmFtZXNwYWNlcyAoaS5lLiwNCmNvbnZl cnRpbmcgIi4iIHRvICItIiBpbiBzY2hlbWUgbmFtZXMgYmFzZWQgb24gYSBkb21haW4gbmFtZSkN CmNhdXNlcyBjb25mbGljdHMuIFVwZGF0ZWQgZXhhbXBsZSB0byB1c2UgIi4iIGluc3RlYWQgb2Yg Ii0iIHRvDQpyZWR1Y2UgY29sbGlzaW9ucy4gQW5kIG9wZW4gdGlja2V0ICMxNyBjb3ZlcnMgdGhl IHJlc3Qgb2YgdGhlDQpjb25mbGljdCBwcm9ibGVtLg0KDQo1KSBDb21iaW5lZCB0aGUgUGVybWFu ZW50LCBQcm92aXNpb25hbCwgYW5kIEhpc3RvcmljYWwgVVJJIFNjaGVtZQ0Kc3ViLXJlZ2lzdHJp ZXMgaW50byBvbmUgVVJJIFNjaGVtZSByZWdpc3RyeSB3aXRoIGEgc3RhdHVzIGNvbHVtbi4NClRo aXMgaXMgZG9uZSB0byBtYWtlIGl0IGVhc2llciB0byBwcmV2ZW50IGR1cGxpY2F0ZXMgYW5kIHNl ZQ0KZXhpc3RpbmcgY29udmVudGlvbnMsIGFzIHdlbGwgYXMgdG8gc3VwcG9ydCB0aGUgIlBlbmRp bmcgUmV2aWV3Ig0KdGVtcG9yYXJ5IHN0YXRlIGFkZGVkIGluIGRyYWZ0LWlldGYtaXJpLTQzOTVi aXMtaXJpcmVnLg0KDQotRGF2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCAxMjoxMyBQTQ0KVG86IExhcnJ5IE1h c2ludGVyOyBEYXZlIFRoYWxlcjsgVGVkIEhhcmRpZTsgRGF2ZSBUaGFsZXI7IExhcnJ5IE1hc2lu dGVyOyBUZWQgSGFyZGllOyBUb255IEhhbnNlbjsgVG9ueSBIYW5zZW4NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGhhbGVyLWFwcHNhd2ctdXJpLXNjaGVtZS1y ZWctMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRoYWxlci1hcHBzYXdn LXVyaS1zY2hlbWUtcmVnLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBEYXZlIFRoYWxlciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 CQlkcmFmdC10aGFsZXItYXBwc2F3Zy11cmktc2NoZW1lLXJlZw0KUmV2aXNpb246CTAwDQpUaXRs ZToJCUd1aWRlbGluZXMgYW5kIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmVzIGZvciBOZXcgVVJJIFNj aGVtZXMNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDItMTQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTE4DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtdGhhbGVyLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWctMDAudHh0 DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dGhhbGVyLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWcvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGhhbGVyLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWctMDAN Cg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGUgZ3VpZGVsaW5lcyBh bmQgcmVjb21tZW5kYXRpb25zLCBhcyB3ZWxsIGFzDQogICB0aGUgSUFOQSByZWdpc3RyYXRpb24g cHJvY2Vzc2VzLCBmb3IgdGhlIGRlZmluaXRpb24gb2YgVW5pZm9ybQ0KICAgUmVzb3VyY2UgSWRl bnRpZmllciAoVVJJKSBzY2hlbWVzLiAgSXQgb2Jzb2xldGVzIFJGQyA0Mzk1Lg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Feb 14 15:50:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91E1A03F5; Fri, 14 Feb 2014 15:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoO0jLtv7Thp; Fri, 14 Feb 2014 15:50:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BF31A047C; Fri, 14 Feb 2014 15:50:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214235020.9814.69424.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:50:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7AnCgGAWdghnatYJ-cRkxEa6eQw Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:50:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-01.txt Pages : 10 Date : 2014-02-14 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 17:16:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC161A000A for ; Fri, 14 Feb 2014 17:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvdayC9_xafR for ; Fri, 14 Feb 2014 17:16:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBDE1A0012 for ; Fri, 14 Feb 2014 17:16:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD58646; Sat, 15 Feb 2014 01:16:04 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 01:15:59 +0000 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 01:16:03 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 09:15:57 +0800 From: Bert Greevenbosch To: "apps-discuss@ietf.org" Thread-Topic: New Version Notification for draft-greevenbosch-appsawg-cbor-cddl-01.txt Thread-Index: AQHPKWRZM80F0JOYEEiK1YuMGQU+RJq1gPLQ Date: Sat, 15 Feb 2014 01:15:56 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63E3FE91D@SZXEMA510-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/UoIk_oYrmz-DzD6ZxhkDUK-n_Pw Subject: [apps-discuss] FW: New Version Notification for draft-greevenbosch-appsawg-cbor-cddl-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 15 Feb 2014 01:16:09 -0000 SGVsbG8gYWxsLA0KDQpJIGhhdmUgdXBkYXRlZCB0aGUgQ0JPUiBkYXRhIGRlc2NyaXB0aW9uIGxh bmd1YWdlIChDRERMKSBkcmFmdC4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1jZGRsLTAxLnR4dA0KDQpUaGUgY2hh bmdlcyBhcmUgYXMgZm9sbG93czoNCg0KICAgbyAgUmVtb3ZlZCB0aGUgY29uc3RhbnRzIG1lY2hh bmlzbQ0KICAgbyAgVXBkYXRlZCB0aGUgdGFnIG1lY2hhbmlzbQ0KICAgbyAgRXh0ZW5kZWQgdGhl IG1hcCBzdHJ1Y3R1cmUNCiAgIG8gIEFkZGVkIGV4YW1wbGVzDQoNClRoZSBtYXAgc3RydWN0dXJl IG5vdyBhbGxvd3MgY29uc3RydWN0cyBhcyBmb2xsb3dzOg0KDQogICAgICAgICAgICAgICAgICAg UGVyc29uYWxEYXRhOiBtYXAoIHRzdHIgKSB7DQogICAgICAgICAgICAgICAgICAgICAiZGlzcGxh eU5hbWUiOiB0c3RyOw0KICAgICAgICAgICAgICAgICAgICAgImFnZSI6IHVpbnQ7DQogICAgICAg ICAgICAgICAgICAgfQ0KDQpBcyBmb3IgdGhlIHRhZyBtZWNoYW5pc20sIEkgcmVtb3ZlZCB0aGUg ZGVwZW5kZW5jeSBvbiB0aGUgbm93IHJlbW92ZWQgY29uc3RhbnRzIG1lY2hhbmlzbSwgYnV0IGFk ZGVkIHByZS1kZWZpbmVkIGRhdGF0eXBlcyBmb3IgY29tbW9uIHRhZ3MsIHN1Y2ggYXMgYmlnbnVt IGFuZCBVUkkuIFNvIGEgYmlnbnVtIE4gY2FuIG5vdyBiZSBkZWNsYXJlZCBhcyBmb2xsb3dzOg0K DQogICAgICAgICAgICAgICAgICAgTjogYmlnbnVtOw0KDQpJIGhvcGUgd2l0aCB0aGVzZSBjaGFu Z2VzLCB0aGUgbGFuZ3VhZ2Uvbm90YXRpb25hbCBjb252ZW50aW9uIGJlY29tZXMgbW9yZSBzdHJh aWdodGZvcndhcmQgYW5kIGxlc3MgY29tcGxleC4NCg0KQ29tbWVudHMgd2lsbCBiZSBhcHByZWNp YXRlZCENCg0KQmVzdCByZWdhcmRzLA0KQmVydA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogMTQgRmVicnVhcnkgMjAxNCAxNzowNg0KVG86IEJlcnQgR3Jl ZXZlbmJvc2NoOyBCZXJ0IEdyZWV2ZW5ib3NjaA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1ncmVldmVuYm9zY2gtYXBwc2F3Zy1jYm9yLWNkZGwtMDEudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdyZWV2ZW5ib3NjaC1hcHBzYXdnLWNib3It Y2RkbC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmVydCBHcmVl dmVuYm9zY2ggYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LWdyZWV2ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2RkbA0KUmV2aXNpb246CTAxDQpUaXRsZToJ CUNCT1IgZGF0YSBkZWZpbml0aW9uIGxhbmd1YWdlOiBhIG5vdGF0aW9uYWwgY29udmVudGlvbiB0 byBleHByZXNzIENCT1IgZGF0YSBzdHJ1Y3R1cmVzLg0KRG9jdW1lbnQgZGF0ZToJMjAxNC0wMi0x NA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUNClVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ncmVldmVuYm9z Y2gtYXBwc2F3Zy1jYm9yLWNkZGwtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3JlZXZlbmJvc2NoLWFwcHNhd2ctY2Jvci1jZGRs Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdyZWV2 ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2RkbC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWdyZWV2ZW5ib3NjaC1hcHBzYXdnLWNib3ItY2Rk bC0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBub3RhdGlvbmFs IGNvbnZlbnRpb24gdG8gZXhwcmVzcyBDQk9SIGRhdGENCiAgIHN0cnVjdHVyZXMuICBJdHMgbWFp biBnb2FsIGlzIHRvIG1ha2UgaXQgZWFzeSB0byBleHByZXNzIG1lc3NhZ2UNCiAgIHN0cnVjdHVy ZXMgZm9yIHByb3RvY29scyB0aGF0IHVzZSBDQk9SLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Sat Feb 15 01:03:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8D21A013E; Sat, 15 Feb 2014 01:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ODNX7laX_7s; Sat, 15 Feb 2014 01:03:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 005E31A00E4; Sat, 15 Feb 2014 01:03:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> Date: Sat, 15 Feb 2014 01:03:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/tL8nDyX-OxbgirU1fmkEUQSinQE Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 09:03:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A NULL MX Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-00.txt Pages : 5 Date : 2014-02-14 Abstract: When the 5321.MailFrom domain in an e-mail message has a DNS MX Resource Record (RR), it is making an explicit statement that it is willing to accept email. However, when the domain has just a DNS A or AAAA RR, there mail clients cannot easily tell whether the domain accepts mail, as many hosts on the Internet advertise an A or AAAA RR regardless of whether they want to accept email. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 15 01:05:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE8A1A014A for ; Sat, 15 Feb 2014 01:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjDEsJIHZihD for ; Sat, 15 Feb 2014 01:05:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A34641A015A for ; Sat, 15 Feb 2014 01:05:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140215090515.9920.59861.idtracker@ietfa.amsl.com> Date: Sat, 15 Feb 2014 01:05:15 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/K-iQO6EPCmH0R3Gj6L4r3IRq4dY Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 09:05:18 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sat Feb 15 06:08:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41DC1A0203 for ; Sat, 15 Feb 2014 06:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrZzmN6Kso8o for ; Sat, 15 Feb 2014 06:08:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A061A0236 for ; Sat, 15 Feb 2014 06:08:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140215140836.3024.75106.idtracker@ietfa.amsl.com> Date: Sat, 15 Feb 2014 06:08:36 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LM3ZDAAZro7OES-HdiVoS4sixaw Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 14:08:39 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-nullmx", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sat Feb 15 14:44:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BBD1A0166 for ; Sat, 15 Feb 2014 14:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFF-b01bP_AH for ; Sat, 15 Feb 2014 14:44:36 -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 4966A1A0133 for ; Sat, 15 Feb 2014 14:44:36 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id to1so265183ieb.38 for ; Sat, 15 Feb 2014 14:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=efUEUMjMHaYoewMW+45co1Fhpw1bRRcgIZp4QMnR/+w=; b=exLiEqUM+1bZbWt7jI+/7YuhQY/Vx0mZ9g60okK5CIXECJQudYg0usZYiisNQ+2pNF IZ0PUXIhAiKzGfbGLSJEfikHmCPpUc+uT9AQK5+nwIkZkTRdIj2Ab1eZSZFVaUWH6pLh sJeFA2niV+Rhqjwa2uSiAMyBVOgPIXzfzknv5Vc4P2Bd5r+SGlP2VefBWYrgh9VGiUKn A8VGEhny2mArGTkszYfUKdd1ZAWei7WH1sZgICMT0DVwholurcQwBpiDJSVNOXgYrX4F bF8i61q2k/4DvzYSi35FQBCChazT5EiSW0hIOUp60yr3tLcWcB+ytAy2DsNwkK45L9a0 Tihw== MIME-Version: 1.0 X-Received: by 10.50.119.161 with SMTP id kv1mr9630335igb.8.1392504274313; Sat, 15 Feb 2014 14:44:34 -0800 (PST) Received: by 10.42.195.206 with HTTP; Sat, 15 Feb 2014 14:44:34 -0800 (PST) Date: Sat, 15 Feb 2014 17:44:34 -0500 Message-ID: From: Darrel Miller To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/w4g1lsu8VT1ZbsfxJA4DPxYwDRI Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 22:44:38 -0000 On Fri, Feb 14, 2014 at 2:42 PM, Nico Williams wrote: > On Thu, Feb 13, 2014 at 3:27 PM, Nico Williams wrote: >> >> I think the harm from specifying baked-in local parts of URIs is that >> they might collide with other pre-existing and unrelated local parts >> of URIs on the servers that might want to run RDAP some day. >> >> I.e., if I run foo.example and RDAP would make me displace an existing >> resource at foo.example, that'd be bad for me. > > Checking draft-ietf-weirds-bootstrap-01, I see that the RDAP proposal > does allow one to specify a fully formed base URI for the RDAP service > for a given domain. > > Given that I fail to see the harm in specifying what resources *below* > that must look like. It looks like any other HTTP API. It looks like > there's no lawn squatting. > Preventing collisions is only one of the reasons that get-off-my-lawn mentions for avoiding specifying URI structure. Enforcing any kind of structural rule on URIs can interfere with implementation choices of the server framework. Limiting the server framework, limits where RDAP can be used, which seems counter productive to me. As an example, this URL, http://example.com/.well-known/rdap/ip/192.0.2.0/24 would be pain for a few of the frameworks that I am familiar with as it is not possible to have a slash as part of a parameter value. Creating a routing that would handle both the IP and CIDR parameters would be tricky. One of the major advantages of using URI templates, beyond freeing the server from conforming to conventions, is that it makes client code really simple. All a client needs to do is retrieve a URI template identified by a link relation and pass parameters to a URI template resolution library (of which there are many). The client doesn't need to know any of the details about to construct URIs. URI construction can be a pain as there are quite a number of esoteric rules for accurate production of a URI. Why burden all the clients with that work and constrain the usable server frameworks, all to save one level of indirection that can be easily be cached on the client? >From briefly reviewing the rdap-query spec, it would seem that the spec could reduce down a set of link relation specifications rel="http://rdap.org/rels/ip" - Points to IP information using the parameter {ipaddress} where {ipaddress} is a IPv4/IPV6 address or IPv4/IPv6 CIDR. rel="http://rdap.org/rels/autnum" - Points to autonomous system number registrations where the parameter {autnum} is an AS Plain autonomous system number. rel="http://rdap.org/rels/domain" - Points to domain information where the parameters {domain} is is a fully-qualified (relative to the root) domain name [RFC1594] in either the in-addr.arpa or ip6.arpa zones (for RIRs) or a fully-qualified domain name in a zone administered by the server operator (for DNRs).. rel="http://rdap.org/rels/nameserver" - you get the idea.... rel="http://rdap.org/rels/entity" and help already exists as a standard link relation, so no need to redefine. And for searches, rel="http://vnd.rdap.domains" rel="http://vnd.rdap.nameservers" rel="vnd.rdap.entities" Now all you need is a single .well-known name, such as, http://example.com/.well-known/rdap/home that could return something like this application/home+json document, { "resources": { "http://rdap.org/rels/ip": { "href-template": "http://rdap1.example.org/myrdap/ip/{ip}", "href-vars": { "ip": null } }, "http://rdap.org/rels/autnum": { "href-template": "http://rdap1.example.org/myrdap/autnum/{autnum}", "href-vars": { "autnum": null } }, "http://rdap.org/rels/domain": { "href-template": "http://rdap1.example.org/myrdap/domain/{domain}", "href-vars": { "domain": null } }, "http://rdap.org/rels/nameserver": { "href-template": "http://rdap1.example.org/myrdap/nameserver/{nameserver}", "href-vars": { "nameserver": null } }, "http://rdap.org/rels/entity": { "href-template": "http://rdap1.example.org/myrdap/entity/{handle}", "href-vars": { "handle": null } }, "help": { "href": "http://rdap1.example.org/help" }, "http://rdap.org/rels/domains": { "href-template": "http://rdap2.example.org/myrdap/domains{?name}", "href-vars": { "name": null } }, "http://rdap.org/rels/nameservers": { "href-template": "http://rdap2.example.org/myrdap/nameservers{?name,ip}", "href-vars": { "name": null, "ip": null } }, "http://rdap.org/rels/entities": { "href-template": "http://rdap2.example.org/myrdap/entity{?fn,handle}", "href-vars": { "fn": null, "handle": null } } } } This document can be cached by clients and provides all the URI templates to access the RDAP server's services. By using complete URI templates you get the opportunity to do other things, like in this example I moved the search queries onto a different host "rdap2" to distribute load. This is just one way of creating a discovery process that would be familiar to web developers and requires minimal specification because it is reusing existing techniques. If you don't think this would work for this use case, don't hold back, you won't hurt me feelings :-). I would be really interested to understand why it wouldn't work. Regards, Darrel Miller From nobody Sat Feb 15 19:56:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CE41A033C for ; Sat, 15 Feb 2014 19:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.043 X-Spam-Level: * X-Spam-Status: No, score=1.043 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smkg712XpVSM for ; Sat, 15 Feb 2014 19:56:07 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABA1A033B for ; Sat, 15 Feb 2014 19:56:07 -0800 (PST) Received: (qmail 12123 invoked from network); 16 Feb 2014 03:56:04 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 16 Feb 2014 03:56:04 -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; s=530036d3.xn--i8sz2z.k1402; i=johnl@user.iecc.com; bh=ZiHz+Qe036gUUDzbBRm9fV09x4NZ0IzqNs0Gkl06iRI=; b=LiDVbatAFEqblw/VzLGScq/zLvHqf87Qpj7lepRoxAj4zH83E4h2WlsFN61hPdwMimBn1xR/YqNK7yJMo68q2kY+DFaMYLgxRYY/wha3WAyDYIQ0XWVlvxoLD8TfUvMRDnSS8wj5FUYDhEAdQuX5SkExZhqLXAeLJ9cqGpncYx1vAcADLGUWNMxzpeLbAAz81jDvC3NDGgfcTo1nhS4Nxffmh8QTgYC/9T0ayGMdeGjSolqcFtRAm0xA72NkV78Q 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; s=530036d3.xn--i8sz2z.k1402; bh=ZiHz+Qe036gUUDzbBRm9fV09x4NZ0IzqNs0Gkl06iRI=; b=R2/VU+wtU10lqgOfvjEs41T5e/7ezPkuQmhhs3L52tmQbvR3wofRqQiU+09tokzOdl17kF1ti7233wLgWtE4uM70LasM9LVRLtnbg6Ngc5MMAOrDuFZocMJBlm3WKQA6Ec51Oqpw/IaJbfR6Hzd8kGHPVdSPHQoRVtWO0nBIAg4XPsQ9iUmBx6cYVAz3iBWClbhmtdlx3BHZf+mxOfGRzdk1Uy+FvSy1YB1Ku20TxAzp3s9D1t852tkeweOiMN2o Date: 16 Feb 2014 03:55:39 -0000 Message-ID: <20140216035539.2686.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5Jk72NMpcTzqdfmwVGInl9svnL4 Cc: darrel@tavis.ca Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2014 03:56:09 -0000 >One of the major advantages of using URI templates, beyond freeing the >server from conforming to conventions, is that it makes client code >really simple. People keep saying this. My client is a three line shell script that uses wget and grep (really.) Could you explain how that works with templates? While you're at it, it'd also be helpful to identify some web servers that people might plausibly use to implement RDAP in 2014 (as opposed to an exercise in retrocomputing) that couldn't handle the syntax in rdap-query. You can skip the .wellknown stuff, which is a holdover from a point when we thought we might use something like SRV records that don't provide a path in the bootstrap. R's, John From nobody Sat Feb 15 21:49:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AB81A037C for ; Sat, 15 Feb 2014 21:49:29 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zTxDccdfSwY for ; Sat, 15 Feb 2014 21:49:26 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA201A037B for ; Sat, 15 Feb 2014 21:49:26 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so10287863vcb.25 for ; Sat, 15 Feb 2014 21:49:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qcdpbR4B0rmTO6QRPuPQOmqnv0r9xA52R1vGifJu5XA=; b=ZsLzzxWUoQ4RS2+83F9EH87TEh0n1beg/yE8u6A7DsT1Qyav/rYiE/aJuY0gvk5iGs VnAGtUPCxtHRydlzse/9OJyKkWJ7o/OYUvC1OxxDLU4ilzs2gm/eS+zJV5MA+n/61NaC 9wHoPTYsIAnsbv7IBz2VlbvUdbKS+rhvLNQTPmUSVzhwq6Tn8QN+MRR5d0kJlMsU1Zcb bgM4db79imJbGkgKR2WuFo2xfszcmE1mZ+EptfpgWqEAWqFIPKBjG2fsP9JJJnK6DZqr H01f1wdPgOqLfWWQtRzRPfHwLfRTZ5jenc4AdbBmv3kk/uLlIHjgnUCDoEhe6dSIuVOD x9iQ== X-Gm-Message-State: ALoCoQkvbmJgsNHLCaE+M0L2d0VyILHK18ECO014mS3ovdyXdd0FjEuGc+J2BCJ8M3kEEQnHNGvI MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr12192454vcb.0.1392529764332; Sat, 15 Feb 2014 21:49:24 -0800 (PST) Received: by 10.220.98.73 with HTTP; Sat, 15 Feb 2014 21:49:24 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <20140216035539.2686.qmail@joyce.lan> References: <20140216035539.2686.qmail@joyce.lan> Date: Sat, 15 Feb 2014 21:49:24 -0800 Message-ID: From: Tim Bray To: John Levine Content-Type: multipart/alternative; boundary=001a11339ae4f14c5c04f27f997d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_mA-FZ-kvoOUEx6-Jv0NGoZ8pUg Cc: Darrel Miller , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2014 05:49:29 -0000 --001a11339ae4f14c5c04f27f997d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I gather that you are fortunate enough never to have dealt with various sorts of shared or enterprise deployments where you have all sorts of constraints on what bits of webspace you=E2=80=99re allowed to touch and wh= at kinds of things you=E2=80=99re allowed to have in your URIs. Anyone who can depl= oy their own server infrastructure and pick what to use is probably able to dance to whatever RFC=E2=80=99s tune, but lots can=E2=80=99t. Anyhow; by definition, the server is authoritative on the URI space it serves and standards shouldn=E2=80=99t screw with that. On Sat, Feb 15, 2014 at 7:55 PM, John Levine wrote: > >One of the major advantages of using URI templates, beyond freeing the > >server from conforming to conventions, is that it makes client code > >really simple. > > People keep saying this. My client is a three line shell script that > uses wget and grep (really.) Could you explain how that works with > templates? > > While you're at it, it'd also be helpful to identify some web servers > that people might plausibly use to implement RDAP in 2014 (as opposed > to an exercise in retrocomputing) that couldn't handle the syntax in > rdap-query. You can skip the .wellknown stuff, which is a holdover > from a point when we thought we might use something like SRV records > that don't provide a path in the bootstrap. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11339ae4f14c5c04f27f997d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I gather that you are fortunate enough never to have dealt= with various sorts of shared or enterprise deployments where you have all = sorts of constraints on what bits of webspace you=E2=80=99re allowed to tou= ch and what kinds of things you=E2=80=99re allowed to have in your URIs. = =C2=A0Anyone who can deploy their own server infrastructure and pick what t= o use is probably able to dance to whatever RFC=E2=80=99s tune, but lots ca= n=E2=80=99t.

Anyhow; by definition, the server is authoritative on the UR= I space it serves and standards shouldn=E2=80=99t screw with that.


On Sat, Fe= b 15, 2014 at 7:55 PM, John Levine <johnl@taugh.com> wrote:
>One of the major advanta= ges of using URI templates, beyond freeing the
>server from conforming to conventions, is that it makes client code
>really simple.

People keep saying this. =C2=A0My client is a three line shell script= that
uses wget and grep (really.) =C2=A0Could you explain how that works with templates?

While you're at it, it'd also be helpful to identify some web serve= rs
that people might plausibly use to implement RDAP in 2014 (as opposed
to an exercise in retrocomputing) that couldn't handle the syntax in rdap-query. =C2=A0You can skip the .wellknown stuff, which is a holdover from a point when we thought we might use something like SRV records
that don't provide a path in the bootstrap.

R's,
John

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

--001a11339ae4f14c5c04f27f997d-- From nobody Sun Feb 16 05:11:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283791A01E2 for ; Sun, 16 Feb 2014 05:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDo_gOIkNJqZ for ; Sun, 16 Feb 2014 05:11:40 -0800 (PST) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 811F31A01E1 for ; Sun, 16 Feb 2014 05:11:40 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so13477847pdb.10 for ; Sun, 16 Feb 2014 05:11:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m2jyoe/zV6MxZApBBd49QrJr1WsP9pE0xnz9aIgaMx4=; b=Vkfoc5/0V/4j/7qzvPV21UtOextnedriLGLpVzExZZr+dnHP+4sXky2QhB9ohaV+9C UfG3/XMW0fG9gkp3vjyPHgh1oHsdMOGE95d/eABj3kG//EGP9++vMs7kTxXRDVMSR++W ajg0siVBHU9+MtOAKhYfAgUEVA7I+MyzF72CsBLH+7I5tyoW4DC8kF5QeHhbC/kcnHCT gjrnb2RKEI18kOubvFmGHHJVfY7yr3Sdbue8Fb3S5PK28lI3WsFPriCkEIkQ/ifjiuSb u0iAMZ+iKMQnAvIfy5JeY8qiMWftttK5d3O82MZqtGnmgRfelw0lPFUl7oG7oayuRm0x PXlw== X-Gm-Message-State: ALoCoQloeHLGvzN5vM6tU8CjVr9Np449s4jygjfu9VtNj/p/nzRmT3gwLJohPoMuR1Ff4RKSQWHf MIME-Version: 1.0 X-Received: by 10.66.164.165 with SMTP id yr5mr20248368pab.63.1392556298310; Sun, 16 Feb 2014 05:11:38 -0800 (PST) Received: by 10.68.143.4 with HTTP; Sun, 16 Feb 2014 05:11:38 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Sun, 16 Feb 2014 08:11:38 -0500 Message-ID: From: Andrew Newton To: darrel@tavis.ca Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jULoXfQdyMAGWw62jytejU43sMc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2014 13:11:42 -0000 On Sat, Feb 15, 2014 at 5:44 PM, Darrel Miller wrote: > As an example, this URL, > http://example.com/.well-known/rdap/ip/192.0.2.0/24 would be pain for > a few of the frameworks that I am familiar with as it is not possible > to have a slash as part of a parameter value. Creating a routing that > would handle both the IP and CIDR parameters would be tricky. And yet there are some methods/frameworks that would have a problem doing as you suggest as well, so it's a tradeoff. As it stands, all RDAP lookups can be laid down on a file system. Your suggestion would remove that. > Now all you need is a single .well-known name, such as, > http://example.com/.well-known/rdap/home that could return something > like this application/home+json document, [..snip..] I believe this is where Mark was going with the bootstrapping. It's worth exploring at that layer as it is more useful there than with .well-known. Thanks. -andy From nobody Sun Feb 16 08:09:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE721A00CD for ; Sun, 16 Feb 2014 08:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tifpbg9SXPel for ; Sun, 16 Feb 2014 08:09:25 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 414E71A002C for ; Sun, 16 Feb 2014 08:09:25 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so3689756iga.1 for ; Sun, 16 Feb 2014 08:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=hd7zlSA+jXYV1v+RXC+cpuEYz6OVRqfOImvY4bVGIJk=; b=f25V5wEIbk+vTXDJGmemMNMqKQd0um5wOWT2wHUVaGrHbMQlhiofB9eQ5d9khnYPkk ydMjjCPltoyXV99oxte4fjknV9qjFGWscgR4YNkXfHgUFlioh86laY2ugbRtSJ/lv5Cn 10mQYHOndafIC5X8nxTz4+4Bm+ks7MzHgqhTbTFXMmjq1jZavVo+7Xt7U+n1ESw3dCRV 08tHKfa7ce0ofOG0ybl97W/O7KYQM1ZkQqZGLadSrlWKxUJqtDAHQ995CpZYhz6jyp/l G6xQqap1eKWNk5G+KOpsSTWpDHRSZJnzPX+lPaRALsmcpu/T7qFbcDvxaCX2oxmLbu8r WTvQ== MIME-Version: 1.0 X-Received: by 10.50.119.161 with SMTP id kv1mr12420424igb.8.1392566962868; Sun, 16 Feb 2014 08:09:22 -0800 (PST) Received: by 10.42.195.206 with HTTP; Sun, 16 Feb 2014 08:09:22 -0800 (PST) Date: Sun, 16 Feb 2014 11:09:22 -0500 Message-ID: From: Darrel Miller To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9ZfDXVYnZXdS1evlnuXSY_E0rUk Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 16:09:27 -0000 John, Your client is a three line shell script because someone took the time to write programs like wget that implement a standard protocol. It would surprise me if someone hasn't already written a URI template processing utility that you can call from your script. Your 3 lines would likely end up being 4 lines. Pseudocode would look something like, get homedoc from homeUri parse desired service uri template from homedoc resolve URI template with parameters get informationdoc from resolved URI However, we seem to be addressing this whole issue from the wrong perspective. It is quite probable that the people who are implementing the RDAP servers will have no issue handling the URIs. It is quite likely that the clients will be able to successfully create the necessary URIs. It is possible that you will not need to change the RDAP URI space once the spec has been baked. However, you are highly visible, publicly accessible service that has chosen to use HTTP. IETF best practices recommend that you don't do what you are doing. Will it work for you, sure, probably, because of your context. The problem is that other developers developing HTTP based services are going to look to what you have done as an example and say, look, at how RDAP works. If it works for them, then why won't it work for us. But their context may not be the same as yours. It is in the web's best interest if high profile services like RDAP are a model for others to follow. The question should not be, why should RDAP follow best practices when they are not absolutely necessary? The question should be, what justification exists for not following that guidance. Justifications might include, - there are no URITemplate processing libraries available on the target client platforms. - caching infrastructure does not exist on client platforms to minimize the impact of the extra round-trip to get the home doc. I don't know if these are valid objections, but I think that would be a better discussion to have than the current one. Regards, Darrel On Sat, Feb 15, 2014 at 10:55 PM, John Levine wrote: >>One of the major advantages of using URI templates, beyond freeing the >>server from conforming to conventions, is that it makes client code >>really simple. > > People keep saying this. My client is a three line shell script that > uses wget and grep (really.) Could you explain how that works with > templates? > > While you're at it, it'd also be helpful to identify some web servers > that people might plausibly use to implement RDAP in 2014 (as opposed > to an exercise in retrocomputing) that couldn't handle the syntax in > rdap-query. You can skip the .wellknown stuff, which is a holdover > from a point when we thought we might use something like SRV records > that don't provide a path in the bootstrap. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Sun Feb 16 08:15:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574CE1A002C for ; Sun, 16 Feb 2014 08:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tas6Lrfi43jt for ; Sun, 16 Feb 2014 08:15:34 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1AD1A00B4 for ; Sun, 16 Feb 2014 08:15:34 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so3695848iga.1 for ; Sun, 16 Feb 2014 08:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=pwF2SQyzVkux+IKEJdOvRzvTvalm3gwQ3BkX0auG4Bc=; b=TltKnIdtV0D+Pa4xYLYwSivkrO6PeJMw11MoOfUmPKfsb64RkA0t6u8kIL95nx+B+8 qLslTx1Re9svrJQinP2ZuXXaW8az0EPWi97TOFwu9bZUAUFo80H37IrLRTncPDXw+eR4 bRI6OPX6wF0UntLpdnTyiGMvLJhm2sHqamcLYqntYeTe4ezCX1Sl24WqPgRs5c7yHrB7 DuAz6ehKgz1JxTfsaa3qVrZDkHpri3JHfr8fRz7ZvKlMHGP9jeJultTxtLb2Md5YVitL SEQpaqkfV0uXlVThS4Rorrtj67cxoaz5FVocc1nkA1kike27MjUJ1Iz/l9M1qIJnHNxz XgTg== MIME-Version: 1.0 X-Received: by 10.50.18.51 with SMTP id t19mr12465566igd.5.1392567331897; Sun, 16 Feb 2014 08:15:31 -0800 (PST) Received: by 10.42.195.206 with HTTP; Sun, 16 Feb 2014 08:15:31 -0800 (PST) Date: Sun, 16 Feb 2014 11:15:31 -0500 Message-ID: From: Darrel Miller To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/c2EJn2SCYsXE2sv3q1WYgEOCdBs Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 16:15:36 -0000 Andrew, On Sun, Feb 16, 2014 at 8:11 AM, Andrew Newton wrote: > On Sat, Feb 15, 2014 at 5:44 PM, Darrel Miller wrote: >> As an example, this URL, >> http://example.com/.well-known/rdap/ip/192.0.2.0/24 would be pain for >> a few of the frameworks that I am familiar with as it is not possible >> to have a slash as part of a parameter value. Creating a routing that >> would handle both the IP and CIDR parameters would be tricky. > > And yet there are some methods/frameworks that would have a problem > doing as you suggest as well, so it's a tradeoff. As it stands, all > RDAP lookups can be laid down on a file system. Your suggestion would > remove that. > I'm not sure I understand the problem you are alluding to. I'm suggesting that servers get to choose whatever URI structure works for them. I can't imagine a server application implementation picking a URI structure that it can't handle. Would be pretty silly, no? There is no reason that the home document can't be read from a file system and contain templates that are compatible with file system access. Well, all except the search ones. I imagine those would be rather inefficient to implement as a file system. Darrel From nobody Sun Feb 16 09:11:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBC21A0103 for ; Sun, 16 Feb 2014 09:11:23 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7e9QYfEsQYLp for ; Sun, 16 Feb 2014 09:11:17 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 669FE1A0016 for ; Sun, 16 Feb 2014 09:11:17 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id up15so14211953pbc.8 for ; Sun, 16 Feb 2014 09:11:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tCwV3QM4GI1eSf8sv8JuyRVqx0xBvrta8nRHVmMNrhU=; b=jzNyNm8k/MLq4mEGuT+g7XxbLrNPqG92mmzMraRfcr7CGFUcdNUmizezFI5KeDQzY9 /kPyDmtlKg9DAW3PpQNMkqRSpMXYEyopu1EbUXEU4rnR9kRz9vEF46TTymJ4LwXDNd8V PuwJdZkzANiXAY1Cg3EmVUcIW2TofXAsBiH7l3+467aOu1PVvH8g/KXXg3kXXxQSVRCY dOq1XzvyBEt3rB20cQsQYOFei942JC+jevgQ+MP33CFcwcs7mqGmA6w5DE574tO4Udgr VwilDBHLcVPZSmMoQuVwaUf+ryYY8NNB1Arch4ZKExdMwiMkrEcjgriS3TTWUHcFgON8 gsPQ== X-Gm-Message-State: ALoCoQmYo9t4gKEC18XDnMWuLa+YxZOfV0Amskxyo1YhwRb9SCr9b+7bvNynjkeGOi2Ywbf0ZCJm MIME-Version: 1.0 X-Received: by 10.68.202.8 with SMTP id ke8mr21709366pbc.86.1392570675188; Sun, 16 Feb 2014 09:11:15 -0800 (PST) Received: by 10.68.143.4 with HTTP; Sun, 16 Feb 2014 09:11:15 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Sun, 16 Feb 2014 12:11:15 -0500 Message-ID: From: Andrew Newton To: darrel@tavis.ca Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/JgXAlxBOgUrg59P8nuDBlkLSY8A Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2014 17:11:25 -0000 On Sun, Feb 16, 2014 at 11:15 AM, Darrel Miller wrote: > I'm not sure I understand the problem you are alluding to. I'm > suggesting that servers get to choose whatever URI structure works for > them. I can't imagine a server application implementation picking a > URI structure that it can't handle. Would be pretty silly, no? I was specifically addressing your idea of using the CIDR length as a query parameter vs as part of the path. With regards to templates, they have been discussed many times by the WEIRDS wg and rejected as they complicate the clients and introduce an extra round-trip. If the "get off my lawn" advice is to avoid URI collisions then the current bootstrap method already accomplishes this. On the other hand, if the advice is that URI templates MUST be used to avoid collisions, then that is different and not what I have heard previously. -andy From nobody Sun Feb 16 10:58:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5631A0221 for ; Sun, 16 Feb 2014 10:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.542 X-Spam-Level: * X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nNy0qDck5AH for ; Sun, 16 Feb 2014 10:58:28 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0BB51A020D for ; Sun, 16 Feb 2014 10:58:27 -0800 (PST) Received: (qmail 49300 invoked from network); 16 Feb 2014 18:58:25 -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:user-agent:cleverness; s=c092.53010a51.k1402; i=johnl-iecc.com@submit.iecc.com; bh=7GV5WL1HRwAoDPgTD2n5L6uiYc9Zvx9SlcU6EhcWnq4=; b=X9I7KaypcfCsSM2NHKilWCawsMMoH9JyG5juIcxpuKiUrYlrTN0RtbsEd036YFkhK/7mpoVQelA1JpvXQb0MzWv6mOunsHbvS5ZvruJ0Yv02oDWq1FESJL+DNz3jOpxclrXLzvUMjcQDv1O7uvUfl0RSrA0uN5LfIIa2Cpd5n6wm0J9Ryr2QUlNQAO8TwSMwjkD2gfvdvKe517rRJgdL6co9pdYhYDERbDOZ53ZJHQJ3jL7TIuS9bWOGl3yBTE/d 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:user-agent:cleverness; s=c092.53010a51.k1402; olt=johnl-iecc.com@submit.iecc.com; bh=7GV5WL1HRwAoDPgTD2n5L6uiYc9Zvx9SlcU6EhcWnq4=; b=lNAhSzi4t890bL/PJ8rVo3kumciDTLNIrl/yh3x7l9JCO2CKb6viRTaJYWjYR0OXZHCZ3uoZLfVew9xYNpNclHrGUxkNk5qXc50y9wLLzE7xPiyDjAcG/OJ7jaTdwW6S1ko78S7ASYeQOkk6UBrTLjTDXbEggQ28BmJHwevkywkdaDrYjBIkRhm1Cf8YLGffGy87e9HYwcr1eVxvbtRse7vFZldUX0yk4HCiUAaf60jInQ+gAlUZrLFcFgwsi59t Received: from [192.168.0.102] ([109.62.74.131]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 16 Feb 2014 18:58:24 -0000 Date: 16 Feb 2014 14:58:20 -0400 Message-ID: From: "John R Levine" To: "Tim Bray" In-Reply-To: References: <20140216035539.2686.qmail@joyce.lan> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/DC6Y0HzrqSQ_Be2JAD7vN7pVXWQ Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2014 18:58:29 -0000 >> People keep saying this. My client is a three line shell script that >> uses wget and grep (really.) Could you explain how that works with >> templates? We seem to be talking past each other here. I believe that there are web servers that for reasons of bureacracy are run in ways with weird limitations, and it would be nice for them if http clients would do arbitrarily complex stuff to work around those servers' limitations. Although it's hard to imagine why a domain or IP registry would use a server like that (none do now), it's not hard to imagine ISPs delegating the RDAP for an IPv6 /56 or /60 to a a SOHO router that's routing the IP traffic, where RDAP will share the tiny http server with the one for the config panel. But there are also web clients that are rather constrained for both administrative and technical reasons, and "use templates" is not helpful advice. (See unanswered question above.) I also think I understand why it is not a good idea to invent random fixed URL syntax that people might shove into random places in a web server, but that's not what RDAP is proposing. Each RDAP server picks its own arbitrary URL prefix which the bootstrap or upstream servers know about, and the RDAP stuff is all constrained to be under that prefix, not anywhere else in the name space. It's true, the syntax requires that some stuff be in the path and some as queries, but so be it. As firmly as one side can say get better clients that can handle arbitrary templates, the other side can say get better servers that can handle the syntax that everyone uses. Since there will be way more clients than servers, fixing the servers will minimize the global pain. Having been through this kind of stuff before,* if RDAP is forced to stick in templates to get through the IESG, here's what will happen: a few clients that already have template libraries will use them. Everyone else will see that the largest domain and IP registries use the syntax in the draft (their prototypes do now), and the small registries and subregistries will use the free python server commissioned by ICANN, which also uses the same syntax, so in practice you can skip the templates and it'll work. A few registries or LIRs might take the spec at face value and use different URL syntax and expect the templates to deal with it. They will get a stream of complaints from people who tell them that their clients work fine with everyone else, you're broken, don't waste our time playing RFC lawyer. So they'll eventually give up and stick in a rewriting proxy to match the defacto standard syntax, or for registries who are stubborn, helpful entrepreneurs will run proxies on their behalf which translate the queries, and also snoop on the query stream. There are plenty of web WHOIS sites right now now that conveniently find the right WHOIS server for you and sell the queries to domain speculators, so this isn't a stretch at all. I hope we agree that would be a ridiculous outcome. If you want to help us, you need to understand RDAP enough to see what has a realistic chance of posing a problem in actual deployed implementations, and how to offer advice we can realistically follow. R's, John * - I'm thinking of when SPF was forced to add a new RRTYPE From nobody Sun Feb 16 14:25:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6E1A02B6 for ; Sun, 16 Feb 2014 14:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv94cy2fqRKy for ; Sun, 16 Feb 2014 14:24:58 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 640A51A02A6 for ; Sun, 16 Feb 2014 14:24:58 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id uy17so4063209igb.3 for ; Sun, 16 Feb 2014 14:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=pjRxg/YnJZBL29lnrUB74Gm3pNZBvTUIF71kEArpw7o=; b=mL4NR3GGvIXX7aRt08pMlPexo9ZX7m2H7bAvArHJs4FoQ2Q91NftlUu7otLVCOAbOG QqdrpPCcSVOJOIVNJi8PAOWcUlh0TsTc/+VmmW4Dj2hi9x2BgvFSScC0zTFTOeURqqcH mZEyaCd4FWbQU4T5TttYpJOEYjxZc3wzYuGxIaGqnOJ5Yv4ibM57BYz81ZBCg4hbycWz CKoR9r4F3WmRgID/8ykorRUAt2n+Nj1yJe8Ts4tb914UVGSw3+2dTcwCg63gYuJgjigS VIiFIIU+ejcBDAGCsnKvS7YEvT0jUIT6Oqy0mttrmnEvLT8jXk5iG8P4ZwMwM91tWut+ BFdQ== MIME-Version: 1.0 X-Received: by 10.42.206.206 with SMTP id fv14mr2720411icb.39.1392589496056; Sun, 16 Feb 2014 14:24:56 -0800 (PST) Received: by 10.42.195.206 with HTTP; Sun, 16 Feb 2014 14:24:55 -0800 (PST) In-Reply-To: References: <20140216035539.2686.qmail@joyce.lan> Date: Sun, 16 Feb 2014 17:24:55 -0500 Message-ID: From: Darrel Miller To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/q59049eDZHlaui3ELp5bb8B6Kxw Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 22:25:01 -0000 John, Wow, that sucks for you guys. I'm glad I don't have to spend time writing specs that people are going choose to ignore at their own convenience. I wish you the best of luck. Darrel On Sun, Feb 16, 2014 at 1:58 PM, John R Levine wrote: >>> People keep saying this. My client is a three line shell script that >>> uses wget and grep (really.) Could you explain how that works with >>> templates? > > > We seem to be talking past each other here. > > I believe that there are web servers that for reasons of bureacracy are run > in ways with weird limitations, and it would be nice for them if http > clients would do arbitrarily complex stuff to work around those servers' > limitations. Although it's hard to imagine why a domain or IP registry > would use a server like that (none do now), it's not hard to imagine ISPs > delegating the RDAP for an IPv6 /56 or /60 to a a SOHO router that's routing > the IP traffic, where RDAP will share the tiny http server with the one for > the config panel. > > But there are also web clients that are rather constrained for both > administrative and technical reasons, and "use templates" is not helpful > advice. (See unanswered question above.) > > I also think I understand why it is not a good idea to invent random fixed > URL syntax that people might shove into random places in a web server, but > that's not what RDAP is proposing. Each RDAP server picks its own arbitrary > URL prefix which the bootstrap or upstream servers know about, and the RDAP > stuff is all constrained to be under that prefix, not anywhere else in the > name space. It's true, the syntax requires that some stuff be in the path > and some as queries, but so be it. > > As firmly as one side can say get better clients that can handle arbitrary > templates, the other side can say get better servers that can handle the > syntax that everyone uses. Since there will be way more clients than > servers, fixing the servers will minimize the global pain. > > Having been through this kind of stuff before,* if RDAP is forced to stick > in templates to get through the IESG, here's what will happen: a few clients > that already have template libraries will use them. Everyone else will see > that the largest domain and IP registries use the syntax in the draft (their > prototypes do now), and the small registries and subregistries will use the > free python server commissioned by ICANN, which also uses the same syntax, > so in practice you can skip the templates and it'll work. > > A few registries or LIRs might take the spec at face value and use different > URL syntax and expect the templates to deal with it. They will get a stream > of complaints from people who tell them that their clients work fine with > everyone else, you're broken, don't waste our time playing RFC lawyer. So > they'll eventually give up and stick in a rewriting proxy to match the > defacto standard syntax, or for registries who are stubborn, helpful > entrepreneurs will run proxies on their behalf which translate the queries, > and also snoop on the query stream. There are plenty of web WHOIS sites > right now now that conveniently find the right WHOIS server for you and sell > the queries to domain speculators, so this isn't a stretch at all. > > I hope we agree that would be a ridiculous outcome. If you want to help us, > you need to understand RDAP enough to see what has a realistic chance of > posing a problem in actual deployed implementations, and how to offer advice > we can realistically follow. > > R's, > John > > * - I'm thinking of when SPF was forced to add a new RRTYPE > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Sun Feb 16 19:17:18 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F371A032E for ; Sun, 16 Feb 2014 19:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.043 X-Spam-Level: * X-Spam-Status: No, score=1.043 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKmI6FkJx5DG for ; Sun, 16 Feb 2014 19:17:12 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id AFA8F1A0129 for ; Sun, 16 Feb 2014 19:17:11 -0800 (PST) Received: (qmail 62200 invoked from network); 17 Feb 2014 03:17:07 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Feb 2014 03:17:07 -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; s=53017f31.xn--btvx9d.k1402; i=johnl@user.iecc.com; bh=5H1b+eF8pPx32IaWVvlHvkj25ErKOEdsJo4otKIyxi0=; b=o63Uh/FXytC1yhIOVDX1YPV9mYbWRiNgbLCe0gOvPs+gSDRE4Cq+biPpiFFewO4cRspnYRSYDPJL2lJtr3JBKH6hAIylv0R6qASltqNM0FyzFSVBx0n8RLed2Yfb4PjedUZ1NewaBzBdZUTHZaQVzxmzhWF2iGGmaG+RDu6ymkbCyKy6mUhjhQxIpS3JqqiLl90oL45HuSUgPMzBGXx78JUTULA686E3ZQsAlw/HCvlgfXe4VAnOCshOIIMOPRgA 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; s=53017f31.xn--btvx9d.k1402; bh=5H1b+eF8pPx32IaWVvlHvkj25ErKOEdsJo4otKIyxi0=; b=Yh6n26W0TMM9oc5PFGeLFqEO0NCR8vzXfkbupFAvFjJrOWWjIeLCxdgVzDrumCrIk4ZpX5KxatZfTxApMwoz3U3tS3lw8bhwZWmTw/X141eP+nnrtn0dSjYiVJeiww5zr0hNpENIegBqwRh60xM8MIFNU6ncE9MxdkAQnrLa9evCsknVeExS7tYg37l7+5qZDSAvjQ2f2ys1xJL38vLiafUJOFhpuYU0AxRnSlnJCVdSC5uHe4ndV+9wXuPnUKGD Date: 17 Feb 2014 03:16:42 -0000 Message-ID: <20140217031642.64322.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/iaSm9i85ElpMY6esjhZmhb8LuzI Cc: darrel@tavis.ca Subject: Re: [apps-discuss] unpersuasive advice, was draft-ietf-weirds-bootstrap-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 03:17:16 -0000 >Your client is a three line shell script because someone took the time >to write programs like wget that implement a standard protocol. It >would surprise me if someone hasn't already written a URI template >processing utility that you can call from your script. Quite posssibly, but it's hard to find among vast array of http servers and proxies that can easily serve up any URL structure we would ever define, removing any need for templates. Why should tens of thousands of clients change their code rather than hundreds (maybe less, considering how concentrated the domain business is) of servers? >However, you are highly visible, publicly accessible service that has >chosen to use HTTP. IETF best practices recommend that you don't do >what you are doing. Yes, we're quite aware of that. We're your friends, and we find this advice unpersuasive, so I wouldn't even want to think about the zillions of random RDAP users who just want to get some answers. Andy has pointed out, more tactfully than me, that when the web crowd has described something that might plausibly be a problem, we've gone to some effort to fix it, e.g., path prefixes in RDAP bootstraps to avoid an implicit need for RDAP servers to have their own (essentially free these days) virtual domain. At this point, the only concrete reason I've seen to use templates is that someone might want to run RDAP on a crappy server that can't implement our very simple URL structure with its own chosen prefix, so we need to add all sorts of template stuff to our clients just in case. I can't speak for the rest of WEIRDS, but in view of what RDAP is and the existing prototypes, that is simply not a problem I see any reason to care about. If you want people to follow your advice, you need credible arguments about what could plausibly break in real world scenarios and reasonable tradeoffs in implementation cost, not "because we say so". We went down the latter road with SPF, the IETF best practices from the DNS crowd turned out to be completely wrong in that context (something they still don't admit) and I for one am not interested in doing it again. R's, John From nobody Sun Feb 16 20:39:07 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC1A1A0340 for ; Sun, 16 Feb 2014 20:39:05 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT-s2hAD0MtH for ; Sun, 16 Feb 2014 20:39:03 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7021A033C for ; Sun, 16 Feb 2014 20:39:03 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id E454959805F for ; Sun, 16 Feb 2014 20:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=crJ4zaLbDPmNpVIjTmxX +kif/wg=; b=LVn4Z61caSCiIx5QhbZ/5m2ubh8NZKg55BQp8PRJdKNsAtBYDuhE QO1//gyU8ZyckOJtO5CtzD/5qyXqlTzIx/G0gI3sCNMP/Z/KRWZe7m2qhHsHp6Uj OChxVOMfUIPNDmhM1xZoqD8Y2D8QE2C+2QDqKR7k2Q01BO19szWrSb4= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 8D22A598058 for ; Sun, 16 Feb 2014 20:39:00 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t61so10386295wes.14 for ; Sun, 16 Feb 2014 20:38:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0K1Hxw+wrudXve5GvGheNKBpU0t751LTsTDczjyxgHQ=; b=l+22dUdV315vgu3AwJsUuPjlqKxy+22S9oCfFNL3aVf68EN55rDCLYMOgRc3sxxdbt mfmkOiNzdieUOaOrRnsJnxQzGP1e8ZM27PimeYkSVUE/3bLUvRV6QgNoW/ySbo+YB8U9 I+cSmAW/GdJ7dbd+wHnLY2Bi9s/AYClu6IK8MpdVMGfYbJt8NrVY6qybCg2s9LcxxWid C3bItNJAYSi/y/E5r+aSHvLMG3ONDE3Ugc8iepA5piI1ZRz2gAgv539mYzCBX3HiD8dD 8E6wJx1FQiW2+Jh2/bcK9XM2ylpkeMo5jI+MxQ8ZoCR5/p9hCrZXVE71k39XM1XxYHWi ijug== MIME-Version: 1.0 X-Received: by 10.180.98.35 with SMTP id ef3mr11162718wib.39.1392611938947; Sun, 16 Feb 2014 20:38:58 -0800 (PST) Received: by 10.217.108.132 with HTTP; Sun, 16 Feb 2014 20:38:58 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Feb 2014 22:38:58 -0600 Message-ID: From: Nico Williams To: darrel@tavis.ca Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AaVHRkP4TZaXPLyxMuKTpkQoIQs Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 04:39:05 -0000 On Sun, Feb 16, 2014 at 10:09 AM, Darrel Miller wrote: > Your client is a three line shell script because someone took the time > to write programs like wget that implement a standard protocol. It > would surprise me if someone hasn't already written a URI template > processing utility that you can call from your script. Your 3 lines > would likely end up being 4 lines. Pseudocode would look something > like, It'd probably still be three loc because where RDAP says to find base URIs now one would find templates, and then it's just a matter of passing the named parameters' values to wget in the one command. Granted, wget (and curl) lacks template support, but it shouldn't be hard to fix that (or to implement a command-line template expander). Having just met and read RFC6570, I must say, it seems like the right way to go. Here's a list of open source URI template implementations: https://code.google.com/p/uri-templates/wiki/Implementations Nico -- From nobody Sun Feb 16 21:54:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51F91A035C for ; Sun, 16 Feb 2014 21:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BplEz_RmHqV for ; Sun, 16 Feb 2014 21:54:08 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C289F1A02DD for ; Sun, 16 Feb 2014 21:54:07 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b15so6864433eek.29 for ; Sun, 16 Feb 2014 21:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OvJzgaxe+q4vMzsWZFF/FOj9U0zF+W8uK0XAFi8f/uM=; b=sEc8NO4gM7Fbc6gr7zdwqrsUMheEx/m45UotzXZa+L2KO7ONiPCDRKy6S/p20Vl8Z7 /4xndez5k4Ip27a4Izr0JGQM/J/UXXTYlQwuntedhTafO/pugcg1x1VLVbfLqcNpEj++ i/JzIkZ7wGrBrakW3TYK3mtpsscbOhX7OObbOIKl9hYEjRHqDzSDGVFqcfiGR3FrsowN u8YfG1AASokI4HgODbLXFdINj/+BG5DUYXAYcU2kEP4rw9p4tEOyED0qrGQb0loMNSN9 aCOkXmAPTlEdP8sS/+86BVPdrG74hDr+iEWpBgJa3Z4XVW+nGiqCnrloUkXu0R+gv+rd 4dUw== MIME-Version: 1.0 X-Received: by 10.15.56.130 with SMTP id y2mr25623432eew.17.1392616444944; Sun, 16 Feb 2014 21:54:04 -0800 (PST) Received: by 10.14.223.132 with HTTP; Sun, 16 Feb 2014 21:54:04 -0800 (PST) Date: Mon, 17 Feb 2014 06:54:04 +0100 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ZU_tS_DoE9rdGWfpQCP6zaw84-w Subject: [apps-discuss] Question about draft-snell-merge-patch-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 05:54:10 -0000 Hello, I have an implementation of said draft which basically works, but some questions remain unclear with regards to applying patches to JSON values which are not objects and null values in the patch. Say we have JSON value: true and the patch reads: { "foo": null } The draft says both that member "foo" should be considered undefined and that the whole JSON value should be replaced by the patch. So, what is the result of the above? Is it {} or { "foo": null }? Similarly, if the patch were { "foo": { "bar": null } }, would the result be { "foo": {} } or { "foo": { "bar": null } }? Cheers, -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nobody Sun Feb 16 22:12:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCFC1A036F for ; Sun, 16 Feb 2014 22:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhOMS2SQtxmW for ; Sun, 16 Feb 2014 22:12:31 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1301F1A036E for ; Sun, 16 Feb 2014 22:12:31 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.8.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 67FC6509B6; Mon, 17 Feb 2014 01:12:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> Date: Mon, 17 Feb 2014 17:12:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <9108BBA8-5FA3-4E52-816D-56E22BA3CA41@mnot.net> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> To: Dave Thaler X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/POa1Rqt5kESimhOYlolSTMdpZDU Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 06:12:34 -0000 Hi Dave, I took a look through, and the draft looks very good; quite readable. A few notes I scratched down as I went through, FWIW: * Introduction - "discourage use of the same scheme name for different = purposes." This is a bit ambiguous; e.g., I use http:// for the purposes = of checking the weather and my bank balance, and that's OK. Suggest: = "discourage handling of a scheme by in conflicting ways." * Introduction (and throughout) - there are a number of lowercase = "should" and "may"s in the document; some people might complain. * Demonstratable... - s/demonstratable/demonstrable/ * Demonstratable - "...some parts of URI processing may be = scheme-dependent." I think this needs to be stronger; at least "...are = often scheme-dependent." * CREF1 - LGTM. * Syntactic Compatibility - "Schemes that are not intended for use with = relative URIs SHOULD avoid use of the forward slash "/" character, which = is used for hierarchical delimiters, and the complete path segments "." = and ".." (dot-segments). If they avoid use of "/", how do you tell what = delimits dot-segments from other stuff? * Syntactic Compatibility - "...the first part of a URI is not an = artistic indicator..." I'd drop "artistic". * Syntactic Compatibility - "Schemes that do not contain a conformant = hierarchical structure in their SHOULD NOT use = double slashes following the string." Why is this not a MUST = NOT? * Well-Defined - "While URIs may or may not be defined as locators in = practice, a scheme definition itself MUST be clear..." Does this really = deserve to be a MUST? When advice is given about what to document = elsewhere in the spec, it always seems to be a SHOULD. * Well-Defined - "In particular, the mapping SHOULD describe the = mechanisms for encoding binary or character strings within valid = character sequences in a URI." I feel like this ought to be more = clearly qualified to cases where such content is valid for the = application; some might read this as requiring a mapping for binary in = all schemes. * Definition of Operations - HTTP calls them "methods", and this should = be noted here to avoid confusing people (we saw it recently). * Definition of Operations - I'd like to see us encourage (but probably = not require) schemes to define a *default* operation for locators; the = AWWW calls this "dereferencing" = and it would be nice to = align the worldviews between the W3C and IETF here. It would also be = good if we encouraged such default methods to be "safe" -- that is, not = having surprising or undesired side effects, from the client's = standpoint. * Scheme Name Considerations - There's a shift in use of language in = this section in the two paragraphs starting with "Avoid..." -- it's = direct, first-person advice, whereas the rest of the spec is more = third-person. * Scheme Name Considerations - I'm very much against "private" / = organisationally scoped registrations -- is the idea that someone can = then make up new URI schemes without registering them? This seems = counter to the purposes of having URIs, as per the AWWW.=20 * CREF2 - The HTML5 folks have spec'd (not clear if they've implemented) = web+, so we should at least talk about it. To me, the problem is that if = somebody comes along and does something like email+, which one wins -- = i.e. do I now have to handle both email+web+http:// and = web+email+http:// as equivalent? Bleurgh.=20 * CREF3 - As per above, I think that allowing domain-based URI schemes = is a Bad Idea. What's the use case?=20 * Guidelines for Provisional URI Scheme Registration - The first = paragraph indicates that provisional is for "private" schemes. I think = we need to have a discussion about that in the WG (perhaps in a separate = thread), because AFAICT provisional is NOT being used that way; rather, = it's being used to reserve namespace for parties that can't be bothered = doing full registration. That's not to say that there's something wrong = with that; as the draft points out, one motivation is to make = registration easier; it's just that we should be honest about why we = have provisional - I'd rather not encourage private URI use at all (but = keep provisional). * Registration Procedures - I'd be much more comfortable if there were = references in this section to the previous requirements; people often = just skip to this section in this kind of RFC, oblivious to the = carefully prepared requirements and arguments above. In an ideal world, = I'd restructure the draft so that the whole thing read like a flow = chart, but I'm not going to ask the WG to do that :) * Registration Procedures - "Unless Expert Review has explicitly = rejected the registration request within two weeks, IANA should = automatically add the registration to the registry as 'provisional." = I'm a bit uncomfortable with this; if the Experts aren't on the ball, = get sick, go on holiday, etc., we can end up with some surprising = results. Can we just raise an exception to the ADs or something? That's all I've got. Thanks again, On 15 Feb 2014, at 9:21 am, Dave Thaler wrote: > This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI > WG closed, we've gone back to it being an individual submission. > This version addresses some of the issues raised on -04 (see > draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as > noted below. There are still a number of open issues for which, with > the permission and help of the appsawg chairs, I have filed issue > tracker tickets to track. >=20 > I have not filed tickets for things already addressed in this version. > These are enumerated below, and if there are disagreements on any > then we can file a ticket for it. >=20 > 1) The IRI WG previously agreed that the fragment component is not > scheme-specific, and that the doc should be updated to clarify that > a scheme definition should only define the scheme-specific part. > This is now done at end of section 1. >=20 > 2) Since the IRI WG was closed, I reverted most of the IRI-specific > changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04. > I left in text clarifying that a URI scheme name and an IRI scheme > name were the same and hence there aren't separate registries, since > apparently that was a common question on RFC 4395. >=20 > 3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > at last IETF, the IRI WG previously agreed that the 4-week mailing > list review was optional for Provisional. RFC 4395 was ambiguous as > to optional vs mandatory. Updated text in section 7.2 to make it > explicit that it is only mandatory for Permanent. >=20 > 4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > at last IETF, RFC 4395's convention for private namespaces (i.e., > converting "." to "-" in scheme names based on a domain name) > causes conflicts. Updated example to use "." instead of "-" to > reduce collisions. And open ticket #17 covers the rest of the > conflict problem. >=20 > 5) Combined the Permanent, Provisional, and Historical URI Scheme > sub-registries into one URI Scheme registry with a status column. > This is done to make it easier to prevent duplicates and see > existing conventions, as well as to support the "Pending Review" > temporary state added in draft-ietf-iri-4395bis-irireg. >=20 > -Dave >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 14, 2014 12:13 PM > To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry = Masinter; Ted Hardie; Tony Hansen; Tony Hansen > Subject: New Version Notification for = draft-thaler-appsawg-uri-scheme-reg-00.txt >=20 >=20 > A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt > has been successfully submitted by Dave Thaler and posted to the IETF = repository. >=20 > Name: draft-thaler-appsawg-uri-scheme-reg > Revision: 00 > Title: Guidelines and Registration Procedures for New = URI Schemes > Document date: 2014-02-14 > Group: Individual Submission > Pages: 18 > URL: = http://www.ietf.org/internet-drafts/draft-thaler-appsawg-uri-scheme-reg-00= .txt > Status: = https://datatracker.ietf.org/doc/draft-thaler-appsawg-uri-scheme-reg/ > Htmlized: = http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00 >=20 >=20 > Abstract: > This document updates the guidelines and recommendations, as well as > the IANA registration processes, for the definition of Uniform > Resource Identifier (URI) schemes. It obsoletes RFC 4395. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From nobody Sun Feb 16 22:16:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD4B1A0372 for ; Sun, 16 Feb 2014 22:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.198 X-Spam-Level: * X-Spam-Status: No, score=1.198 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKDi3Cty_sml for ; Sun, 16 Feb 2014 22:16:53 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD1D1A0370 for ; Sun, 16 Feb 2014 22:16:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,859,1384261200"; d="scan'208";a="183801090" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 17 Feb 2014 17:16:49 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7351"; a="193997286" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipccvi.tcif.telstra.com.au with ESMTP; 17 Feb 2014 17:16:50 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Mon, 17 Feb 2014 17:16:31 +1100 From: "Manger, James" To: Francis Galiegue , "apps-discuss@ietf.org" Date: Mon, 17 Feb 2014 17:16:30 +1100 Thread-Topic: [apps-discuss] Question about draft-snell-merge-patch-08 Thread-Index: Ac8rpLH/iVd1h2hyTd6bl/Efb3w2SwAAMfGQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1153B519138@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L_oysTh6OnK3TY_G2GgRMLuDiGg Subject: Re: [apps-discuss] Question about draft-snell-merge-patch-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 06:16:55 -0000 PiBJIGhhdmUgYW4gaW1wbGVtZW50YXRpb24gb2Ygc2FpZCBkcmFmdCB3aGljaCBiYXNpY2FsbHkg d29ya3MsIGJ1dCBzb21lDQo+IHF1ZXN0aW9ucyByZW1haW4gdW5jbGVhciB3aXRoIHJlZ2FyZHMg dG8gYXBwbHlpbmcgcGF0Y2hlcyB0byBKU09ODQo+IHZhbHVlcyB3aGljaCBhcmUgbm90IG9iamVj dHMgYW5kIG51bGwgdmFsdWVzIGluIHRoZSBwYXRjaC4NCj4gDQo+IFNheSB3ZSBoYXZlIEpTT04g dmFsdWU6DQo+IA0KPiB0cnVlDQo+IA0KPiBhbmQgdGhlIHBhdGNoIHJlYWRzOg0KPiANCj4gew0K PiAgICAgImZvbyI6IG51bGwNCj4gfQ0KPiANCj4gVGhlIGRyYWZ0IHNheXMgYm90aCB0aGF0IG1l bWJlciAiZm9vIiBzaG91bGQgYmUgY29uc2lkZXJlZCB1bmRlZmluZWQNCj4gYW5kIHRoYXQgdGhl IHdob2xlIEpTT04gdmFsdWUgc2hvdWxkIGJlIHJlcGxhY2VkIGJ5IHRoZSBwYXRjaC4gU28sDQo+ IHdoYXQgaXMgdGhlIHJlc3VsdCBvZiB0aGUgYWJvdmU/IElzIGl0IHt9IG9yIHsgImZvbyI6IG51 bGwgfT8NCg0Ke30gaXMgdGhlIG9ubHkgcmVzdWx0IHRoYXQgbWFrZXMgc2Vuc2UgdG8gbWUuDQoN Cg0KPiBTaW1pbGFybHksIGlmIHRoZSBwYXRjaCB3ZXJlIHsgImZvbyI6IHsgImJhciI6IG51bGwg fSB9LCB3b3VsZCB0aGUNCj4gcmVzdWx0IGJlIHsgImZvbyI6IHt9IH0gb3IgeyAiZm9vIjogeyAi YmFyIjogbnVsbCB9IH0/DQoNCnsgImZvbyI6IHt9IH0gaXMgdGhlIHNlbnNpYmxlIGFuc3dlci4N Cg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From nobody Sun Feb 16 22:25:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0A41A043A for ; Sun, 16 Feb 2014 22:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR-Wh7gb62S7 for ; Sun, 16 Feb 2014 22:25:37 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2956B1A0437 for ; Sun, 16 Feb 2014 22:25:37 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.8.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1C58D509B5; Mon, 17 Feb 2014 01:25:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: <20140217031642.64322.qmail@joyce.lan> Date: Mon, 17 Feb 2014 17:25:28 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <1425FC5B-1210-43AC-89B4-B7CF99E22526@mnot.net> References: <20140217031642.64322.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sCsetUlaAw2sx0vP0aJGYNmZQrA Cc: IETF Apps Discuss Subject: Re: [apps-discuss] unpersuasive advice, was draft-ietf-weirds-bootstrap-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 06:25:40 -0000 On 17 Feb 2014, at 2:16 pm, John Levine wrote: > I can't speak for the rest of WEIRDS, but in view of what RDAP is and > the existing prototypes, that is simply not a problem I see any reason > to care about. If you want people to follow your advice, you need > credible arguments about what could plausibly break in real world > scenarios and reasonable tradeoffs in implementation cost, not > "because we say so". We went down the latter road with SPF, the IETF > best practices from the DNS crowd turned out to be completely wrong in > that context (something they still don't admit) and I for one am not > interested in doing it again. So, you keep on using that analogy. The thing is, introducing a new RRTYPE has well-understood, = difficult-to-overcome operational problems. However, here your argument seems to be "it's too hard; I want to write = a three-line shell script." Is there more? Because "I have to write a = bit more code" is not equal to the fundamental deployment problems that = introducing a new RRTYPE brings, not even close. I think a better analogy is this -- you want to deploy a new protocol = over TCP/IP, but for convenience you want to assume that all hosts on = the local network ending in ".2" speak your protocol. When the IP folks express concern about the operational problems this = will bring, and the precedent it will set for others, you say "But, the = people deploying my protocol will just deploy a new network for it -- = it's not a problem!" And so on. Like all analogies, it'll break down at some point; it's just closer = than RRTYPE vs. TXT, IMO. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Sun Feb 16 22:49:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DD01A043C for ; Sun, 16 Feb 2014 22:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4GlOSDvEHhW for ; Sun, 16 Feb 2014 22:48:56 -0800 (PST) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7791A002D for ; Sun, 16 Feb 2014 22:48:56 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id m10so4317572eaj.8 for ; Sun, 16 Feb 2014 22:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8g7wPP2Tn+ZXGi66y3lARjF6PRiCSniXu1HiU/dxOhc=; b=OjAOFSAPWEeePlC9/6Xp+8iPDjH7ITvg6peZZ71ahR6xUNnufytBvjI89Z/+qNLIKq kkQRKMDImTWtdoESrCAnoKSbP5otDtFHMab5GlL+boPSk2kcsnvXbRL1C6Pzfk9z/uVz qGF8bY8c8N2k2ZjskXrm/KMmnNgH4sSgpHidoyHxa3NziQo+7/q+y/nkGlOp8sVU7I9S l4fpbcVgCiLXAktel9e2WVSP3QUeKMPGT1xPF20/AMldxQpyYsx3YXNj+idNS5piIegz UeTS4dvz+dVrMZP+OOT8Z5ti82TE8oJ/DiFS5CU34XGZ+2j00OZnOeIkt3TFgUGJ6Dae z6dg== MIME-Version: 1.0 X-Received: by 10.14.110.68 with SMTP id t44mr293850eeg.74.1392619733749; Sun, 16 Feb 2014 22:48:53 -0800 (PST) Received: by 10.14.223.132 with HTTP; Sun, 16 Feb 2014 22:48:53 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1153B519138@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1153B519138@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 17 Feb 2014 07:48:53 +0100 Message-ID: From: Francis Galiegue To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/yNPPp61WW9aAm8xwE41Cz5GdVgQ Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Question about draft-snell-merge-patch-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 06:48:59 -0000 Hello, On Mon, Feb 17, 2014 at 7:16 AM, Manger, James wrote: [...] > >> Similarly, if the patch were { "foo": { "bar": null } }, would the >> result be { "foo": {} } or { "foo": { "bar": null } }? > > { "foo": {} } is the sensible answer. > OK, I have since noticed that the reference draft is http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02, and the text in this draft is more clear about that. However, there is also that text in section 2, which kind of troubles me, since there are no examples: [...] Any null member contained in a provided array MUST be ignored and treated as if the member was undefined, even within array or object members within the array. Uhm. So, does this mean that if the value is: [ 1, null, { "a": null } ] then it really should be patched to: [ 1, {} ] ? Also, in point 1 (ie, both the patch and victim are arrays), it only says that "Any null member contained in the merge patch MUST be ignored and treated as if those members are undefined". What are members here? Does that include array elements? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nobody Mon Feb 17 00:56:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35D31A00BF for ; Mon, 17 Feb 2014 00:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYLilQfapNVx for ; Mon, 17 Feb 2014 00:56:27 -0800 (PST) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B8DB11A00B6 for ; Mon, 17 Feb 2014 00:56:26 -0800 (PST) Received: by mail-ea0-f171.google.com with SMTP id f15so6999690eak.16 for ; Mon, 17 Feb 2014 00:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lvaIP2/BP6MDdgTjQIKs05hyTzKEiO0Sq9nYi0EIqZU=; b=P1vDal/XOge9+ArzN9P1EuUoSE1mVxbAPGFZ7Wi2gyBS298f2VzDWzT7VtCpQHgXjV ZTdwFc4smJ3nlJoZ1Ty8QzKUrlDgx6ADIyHR3hXY0++IUzM2Kh9IgzKbx1QvPtpJwxds Am4Rs7/0m8iElsDx9TTkF2gC7ukj42GNCs0KpFf5ROUI4yC6DxYrmgm8shyFzGGHf3ex EiQVAW2LW/UqPZAEG+tDWy7S31sJcJBwcMMyxhUVYwwAo7MThvrE+TzISedyiMgfXDjq TFqHx0ojdLGrTJ+DgvkKEF0+698tidePZMoXOWh86Lc/PjANuDOCqk2OCbhvqYvVEYBW TDfQ== MIME-Version: 1.0 X-Received: by 10.14.203.197 with SMTP id f45mr807524eeo.90.1392627383858; Mon, 17 Feb 2014 00:56:23 -0800 (PST) Received: by 10.14.223.132 with HTTP; Mon, 17 Feb 2014 00:56:23 -0800 (PST) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1153B519138@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 17 Feb 2014 09:56:23 +0100 Message-ID: From: Francis Galiegue To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/5T7K0R9vxF4yQORDa1kUAyNMVy8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Question about draft-snell-merge-patch-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 08:56:28 -0000 [...] > > However, there is also that text in section 2, which kind of troubles > me, since there are no examples: > > [...] Any null member contained in a provided array MUST be > ignored and treated as if the member was undefined, even > within array or object members within the array. > > Uhm. So, does this mean that if the value is: > > [ 1, null, { "a": null } ] > > then it really should be patched to: > > [ 1, {} ] > > ? > > Also, in point 1 (ie, both the patch and victim are arrays), it only > says that "Any null member contained in the merge patch MUST be > ignored and treated as if those members are undefined". What are > members here? Does that include array elements? > OK, my bad, there are examples further down in the draft showing how to deal with nulls. Sorry for the noise, -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nobody Mon Feb 17 01:02:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEBD1A00C9 for ; Mon, 17 Feb 2014 01:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZNYe27gUJIh for ; Mon, 17 Feb 2014 01:02:22 -0800 (PST) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id B51171A00B6 for ; Mon, 17 Feb 2014 01:02:22 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WFK5h-0006ZK-jj; Mon, 17 Feb 2014 09:02:17 +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 1WFK5f-0000ZT-2M; Mon, 17 Feb 2014 09:02:16 +0000 Message-ID: <53009C37.3030009@ninebynine.org> Date: Sun, 16 Feb 2014 11:08:39 +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: John Levine References: <20140216035539.2686.qmail@joyce.lan> In-Reply-To: <20140216035539.2686.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/duN5uIwJx3KkgkAqMLDOwK9HW6c Cc: darrel@tavis.ca, apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 09:02:25 -0000 On 16/02/2014 03:55, John Levine wrote: >> One of the major advantages of using URI templates, beyond freeing the >> server from conforming to conventions, is that it makes client code >> really simple. > > People keep saying this. My client is a three line shell script that > uses wget and grep (really.) Could you explain how that works with > templates? I've done something like this for apps I write by providing a simple template expansion service (POST template+parameters as JSON, get URI back). E.g. [[ # URI template expansion echo "==== Request URI-template expansion ====" cat >sample-params.txt < X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B59C1A0379 for ; Mon, 17 Feb 2014 04:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjjx2oZve5PW for ; Mon, 17 Feb 2014 04:31:23 -0800 (PST) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8741A0275 for ; Mon, 17 Feb 2014 04:31:23 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WFNLz-00084X-lg; Mon, 17 Feb 2014 12:31:19 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WFNLz-0004tD-7L; Mon, 17 Feb 2014 12:31:19 +0000 Message-ID: <5301FD29.5000401@ninebynine.org> Date: Mon, 17 Feb 2014 12:14:33 +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: Dave Thaler References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/a5uyRnKHgSHyGrVnyFkH3aLQG0E Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 12:31:27 -0000 Dave, Reviewing: http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00 I'm responding with a perspective of being the current designated IANA reviewer. Broadly, I'm supportive of the changes proposed, and in particular to lower the perceived barrier to provisional registration of schemes. ... Section 3: "For IETF Standards-Track documents, Permanent registration status is REQUIRED." -- I can guess at what this is trying to say, but I think it's not clear (and I wonder if it needs to be saif at all). ... Section 3.3 ("well defined"). One of the first questions I ask myself when reviewing a URI scheme proposal is: "What kinds of thing do URIs in this scheme identify, or how do I find out?". I'd like to see all scheme registrations providing a clear answer for this. One of the problems I have sometimes experienced in reviewing URI scheme registration submissions is understanding what the corresponding scheme is intended to identify. If it is a locator, then it's usually fairly clear. But some schemes I've seen - particularly where used as particular identifiers within other protocols - have been less clear (in their original submissions). Recent(ish) examples that come to mind are acct:, turn: and stun: (not criticizing them, just trying to give examples of things that are not always immediately clear). I think the text "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme." goes some way to this, but that was present in the previous draft and didn't always get noticed. Also, there is not always a mechanism that is available to software (e.g. urn":). I'm wondering if this can be beefed up a bit... e.g. to lead with something like: "URI scheme specifications should be clear about the kind of resource that they may identify, or the means (technical or non-technical) by which URIs are related to the resources they identify" My text could surely be improved. The first part of this would apply to a scheme like "acct:" saying that an acct: URI identifies a user account in some domain or system (**); the latter would apply to locator schemes like http:, or identifier schemes like urn: where there is a defined administrative delegation structure. In making this comment, I also note there is some slight overlap with material covered in section 3.4. ... Section 3.8: Re: "[[CREF2: Open Issue: Should we define a mechanism to register a scheme prefix ("web+", "ms-", etc.)? --DT]]" I think not. I've not come across any great need for this, and I think it might even encourage scheme proliferation in conflict with the exhortations in section 3.1 ("In general, the use and deployment of new schemes in the Internet infrastructure may be costly; ...", etc.) ... Section 4 re: [[CREF4: Open issue: previously this also RECOMMENDED following the same guidelines as for permanent registration. However, this higher bar disincented people to register schemes at all, and hence interfered with the goals of the registry. Hence tentatively removed, but need to confirm consensus on this. --DT]] I've not seen any cases where this has been a problem, but maybe that's because I mainly see a self-selecting population ;) (I.e. those who have actually submitted a registration request.) Some time ago, we started creating a FAQ/guidance page at IANA for a similar registry (message header fields), with the goal of demystifying the process and encouraging early registration. Unfortunately, that effort fizzled (though I think an initial draft is still around on an IETF/IANA wiki page.) Maybe this kind of approach would be an alternative? I.e. create a FAQ, and direct readers to that page for provisional registration. The FAQ-as-guidance can then be updated more easily than the BCP document (within its defined constraints). ... Section 7.1 [[CREF8: Open Issue: Should Provisional status just use First Come First Serve? Someone suggested FCFS with Expert Review afterwards, but the benefit and efficacy of a subsequent Expert Review seems dubious to me and might only serve to deter registrations in the first place, which is the problem we're trying to solve. --DT]] Given the limited nature of URI scheme name space, I think that IESG/IANA should always have final say about name allocation. Given that we try to keep the bar low, I feel formal FCFS makes it too easy to use provisional registration as a land grab - writing that into the spec would make it harder for an expert reviewer to push for alternatives where appropriate. (I think there is one occasion in the past few years where the choice of name has been cause for push-back, so it's not a great problem.) As reviewer, I have tried to treat the role as providing guidance rather than as gatekeeper (I don't think I've ever recommended rejection of a provisional registration request, though I do often make comments), so I'm a little troubled by the perception that expert review is a deterrent. Can we do something in the spec language to make this less of a concern? E.g. "The purpose of expert review applied to provisional registration is not intended to impose onerous requirements on the proposals offered, but as a light-touch process to promote effective cooperative use of URI scheme name space." ... Section 7.1: [[CREF9: TODO: We don't want this. --??]] I'm not sure what it is you don't want. I think it is useful that the IESG can be final arbiter, as it provides some room for making decisions that are not in strict accordance with the process requirements, without kicking the door open to making arbitrary and capricious decisions. There have been a few cases (I forget details) where the specific drafting of the process has seemed to be at odds with a common sense "do the right thing" approach - having a way to accommodate these within a clearlhy documented framework seems useful to me. ... Section 7.2: [[CREF10: Open Issue: I think the last phrase above about RFC 3978 is problematic, as it just serves to discourage registration. For example, third-party registrations may have no way to grant such rights or make such assertions. Similarly, a standard published by another SDO may have policy/ process issues having a request treated as an IETF contribution. Recommend deleting this sentence. --DT]] I'd suggest that at least the registration template submitted to IANA be treated as "IETF contribution", even if the rest of the document cannot, since IANA may need to republish that much. The registration template itself can be short and consist mainly of pointers to other documents, so I don't think that should be a great disincentive. ... Section 7.2: [[CREF11: Open Issue: Say more about guidance to the Designated Expert. Under what circumstance should this happen? --DT]] I'm not sure what guidance you have in mind here. Generally, I'd expect upgrades from provisional to permanent to meet the same requirements as permanent registrations (with provision for IESG last-say as noted above). That's pretty much covered in section 7.3. ... [[CREF12: Open Issue: Some of the fields above may serve to deter registration. Should some of them NOT be required for Provisional registrations (including third-party ones)? For example, the requirement to have clear security considerations is not appropriate for third-party registrations. Typically one is forced to fill in something like "Unknown, use with care." These seem to me to be more appropriate inside the specification (if any) in the references, rather than being required in the request template. Thus, as new specifications update the uses (e.g., allow use with another HTTP method), the IANA registry itself shouldn't be required to be updated. --DT]] Fair points. Part of the problem here, I think, is that the template serves two purposes: (a) registering a scheme that is fully described elsewhere, in which case its mainly a pointer to that specification, and (b) describing a scheme in use that is not described in another document (which could really apply only for provisional or historic schemes). I think the headings (especially security considerations) are useful as reminders of things to think about and maybe provide additional information. Maybe the template could be restructured as key information (Name, status, context of use, contact, change controller, and references); then have "Additional information" with sub-headings to be filled in as required, and all optional for provisional registrations? ... Thanks, #g -- On 14/02/2014 22:21, Dave Thaler wrote: > This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI > WG closed, we've gone back to it being an individual submission. > This version addresses some of the issues raised on -04 (see > draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as > noted below. There are still a number of open issues for which, with > the permission and help of the appsawg chairs, I have filed issue > tracker tickets to track. > > I have not filed tickets for things already addressed in this version. > These are enumerated below, and if there are disagreements on any > then we can file a ticket for it. > > 1) The IRI WG previously agreed that the fragment component is not > scheme-specific, and that the doc should be updated to clarify that > a scheme definition should only define the scheme-specific part. > This is now done at end of section 1. > > 2) Since the IRI WG was closed, I reverted most of the IRI-specific > changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04. > I left in text clarifying that a URI scheme name and an IRI scheme > name were the same and hence there aren't separate registries, since > apparently that was a common question on RFC 4395. > > 3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > at last IETF, the IRI WG previously agreed that the 4-week mailing > list review was optional for Provisional. RFC 4395 was ambiguous as > to optional vs mandatory. Updated text in section 7.2 to make it > explicit that it is only mandatory for Permanent. > > 4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > at last IETF, RFC 4395's convention for private namespaces (i.e., > converting "." to "-" in scheme names based on a domain name) > causes conflicts. Updated example to use "." instead of "-" to > reduce collisions. And open ticket #17 covers the rest of the > conflict problem. > > 5) Combined the Permanent, Provisional, and Historical URI Scheme > sub-registries into one URI Scheme registry with a status column. > This is done to make it easier to prevent duplicates and see > existing conventions, as well as to support the "Pending Review" > temporary state added in draft-ietf-iri-4395bis-irireg. > > -Dave > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 14, 2014 12:13 PM > To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry Masinter; Ted Hardie; Tony Hansen; Tony Hansen > Subject: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt > > > A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt > has been successfully submitted by Dave Thaler and posted to the IETF repository. > > Name: draft-thaler-appsawg-uri-scheme-reg > Revision: 00 > Title: Guidelines and Registration Procedures for New URI Schemes > Document date: 2014-02-14 > Group: Individual Submission > Pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-thaler-appsawg-uri-scheme-reg-00.txt > Status: https://datatracker.ietf.org/doc/draft-thaler-appsawg-uri-scheme-reg/ > Htmlized: http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00 > > > Abstract: > This document updates the guidelines and recommendations, as well as > the IANA registration processes, for the definition of Uniform > Resource Identifier (URI) schemes. It obsoletes RFC 4395. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Feb 17 04:31:34 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0B31A0379 for ; Mon, 17 Feb 2014 04:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0sjAVl4dRlx for ; Mon, 17 Feb 2014 04:31:26 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 232681A034B for ; Mon, 17 Feb 2014 04:31:26 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WFNM1-0007kh-gn; Mon, 17 Feb 2014 12:31:21 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WFNM0-0004tI-8f; Mon, 17 Feb 2014 12:31:21 +0000 Message-ID: <5301FF8A.5030005@ninebynine.org> Date: Mon, 17 Feb 2014 12:24:42 +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: Mark Nottingham , Dave Thaler References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> <9108BBA8-5FA3-4E52-816D-56E22BA3CA41@mnot.net> In-Reply-To: <9108BBA8-5FA3-4E52-816D-56E22BA3CA41@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/IgWIsQkIx6c5AdODoUrRnUSD3Sc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 12:31:29 -0000 Hi, Broadly, I concur or do not disagree with Mark's comments. A few additional thoughts interleaved. On 17/02/2014 06:12, Mark Nottingham wrote: > Hi Dave, > > I took a look through, and the draft looks very good; quite readable. > > A few notes I scratched down as I went through, FWIW: > > * Introduction - "discourage use of the same scheme name for different purposes." This is a bit ambiguous; e.g., I use http:// for the purposes of checking the weather and my bank balance, and that's OK. Suggest: "discourage handling of a scheme by in conflicting ways." > > * Introduction (and throughout) - there are a number of lowercase "should" and "may"s in the document; some people might complain. > > * Demonstratable... - s/demonstratable/demonstrable/ > > * Demonstratable - "...some parts of URI processing may be scheme-dependent." I think this needs to be stronger; at least "...are often scheme-dependent." > > * CREF1 - LGTM. > > * Syntactic Compatibility - "Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments). If they avoid use of "/", how do you tell what delimits dot-segments from other stuff? > > * Syntactic Compatibility - "...the first part of a URI is not an artistic indicator..." I'd drop "artistic". > > * Syntactic Compatibility - "Schemes that do not contain a conformant hierarchical structure in their SHOULD NOT use double slashes following the string." Why is this not a MUST NOT? > > * Well-Defined - "While URIs may or may not be defined as locators in practice, a scheme definition itself MUST be clear..." Does this really deserve to be a MUST? When advice is given about what to document elsewhere in the spec, it always seems to be a SHOULD. > > * Well-Defined - "In particular, the mapping SHOULD describe the mechanisms for encoding binary or character strings within valid character sequences in a URI." I feel like this ought to be more clearly qualified to cases where such content is valid for the application; some might read this as requiring a mapping for binary in all schemes. > > * Definition of Operations - HTTP calls them "methods", and this should be noted here to avoid confusing people (we saw it recently). > > * Definition of Operations - I'd like to see us encourage (but probably not require) schemes to define a *default* operation for locators; the AWWW calls this "dereferencing" and it would be nice to align the worldviews between the W3C and IETF here. It would also be good if we encouraged such default methods to be "safe" -- that is, not having surprising or undesired side effects, from the client's standpoint. This makes sense for many schemes, but not so much for "pure" identifier schemes like urn:, etc. I argued for something like this for the acct: scheme, but in the end did not persuade. > > * Scheme Name Considerations - There's a shift in use of language in this section in the two paragraphs starting with "Avoid..." -- it's direct, first-person advice, whereas the rest of the spec is more third-person. > > * Scheme Name Considerations - I'm very much against "private" / organisationally scoped registrations -- is the idea that someone can then make up new URI schemes without registering them? This seems counter to the purposes of having URIs, as per the AWWW. > +1 (I already commented on this in another message, but I'll emphasize my concurrence here.) > * CREF2 - The HTML5 folks have spec'd (not clear if they've implemented) web+, so we should at least talk about it. To me, the problem is that if somebody comes along and does something like email+, which one wins -- i.e. do I now have to handle both email+web+http:// and web+email+http:// as equivalent? Bleurgh. > FWIW, I'd say web+foo and email+foo are simply different schemes. There's no sense in which one can "win". > * CREF3 - As per above, I think that allowing domain-based URI schemes is a Bad Idea. What's the use case? > > * Guidelines for Provisional URI Scheme Registration - The first paragraph indicates that provisional is for "private" schemes. I think we need to have a discussion about that in the WG (perhaps in a separate thread), because AFAICT provisional is NOT being used that way; rather, it's being used to reserve namespace for parties that can't be bothered doing full registration. That's not to say that there's something wrong with that; as the draft points out, one motivation is to make registration easier; it's just that we should be honest about why we have provisional - I'd rather not encourage private URI use at all (but keep provisional). > > * Registration Procedures - I'd be much more comfortable if there were references in this section to the previous requirements; people often just skip to this section in this kind of RFC, oblivious to the carefully prepared requirements and arguments above. In an ideal world, I'd restructure the draft so that the whole thing read like a flow chart, but I'm not going to ask the WG to do that :) > > * Registration Procedures - "Unless Expert Review has explicitly rejected the registration request within two weeks, IANA should automatically add the registration to the registry as 'provisional." I'm a bit uncomfortable with this; if the Experts aren't on the ball, get sick, go on holiday, etc., we can end up with some surprising results. Can we just raise an exception to the ADs or something? > I think the idea was that a non-responsive expert would not block the process. In practice, to date, IANA keep prodding until they get a response (I sometimes benefit from a reminder, but I don't think I've every completely failed to respond in 2 weeks). #g -- > That's all I've got. Thanks again, > > > On 15 Feb 2014, at 9:21 am, Dave Thaler wrote: > >> This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI >> WG closed, we've gone back to it being an individual submission. >> This version addresses some of the issues raised on -04 (see >> draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as >> noted below. There are still a number of open issues for which, with >> the permission and help of the appsawg chairs, I have filed issue >> tracker tickets to track. >> >> I have not filed tickets for things already addressed in this version. >> These are enumerated below, and if there are disagreements on any >> then we can file a ticket for it. >> >> 1) The IRI WG previously agreed that the fragment component is not >> scheme-specific, and that the doc should be updated to clarify that >> a scheme definition should only define the scheme-specific part. >> This is now done at end of section 1. >> >> 2) Since the IRI WG was closed, I reverted most of the IRI-specific >> changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04. >> I left in text clarifying that a URI scheme name and an IRI scheme >> name were the same and hence there aren't separate registries, since >> apparently that was a common question on RFC 4395. >> >> 3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation >> at last IETF, the IRI WG previously agreed that the 4-week mailing >> list review was optional for Provisional. RFC 4395 was ambiguous as >> to optional vs mandatory. Updated text in section 7.2 to make it >> explicit that it is only mandatory for Permanent. >> >> 4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation >> at last IETF, RFC 4395's convention for private namespaces (i.e., >> converting "." to "-" in scheme names based on a domain name) >> causes conflicts. Updated example to use "." instead of "-" to >> reduce collisions. And open ticket #17 covers the rest of the >> conflict problem. >> >> 5) Combined the Permanent, Provisional, and Historical URI Scheme >> sub-registries into one URI Scheme registry with a status column. >> This is done to make it easier to prevent duplicates and see >> existing conventions, as well as to support the "Pending Review" >> temporary state added in draft-ietf-iri-4395bis-irireg. >> >> -Dave >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, February 14, 2014 12:13 PM >> To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry Masinter; Ted Hardie; Tony Hansen; Tony Hansen >> Subject: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt >> >> >> A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt >> has been successfully submitted by Dave Thaler and posted to the IETF repository. >> >> Name: draft-thaler-appsawg-uri-scheme-reg >> Revision: 00 >> Title: Guidelines and Registration Procedures for New URI Schemes >> Document date: 2014-02-14 >> Group: Individual Submission >> Pages: 18 >> URL: http://www.ietf.org/internet-drafts/draft-thaler-appsawg-uri-scheme-reg-00.txt >> Status: https://datatracker.ietf.org/doc/draft-thaler-appsawg-uri-scheme-reg/ >> Htmlized: http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00 >> >> >> Abstract: >> This document updates the guidelines and recommendations, as well as >> the IANA registration processes, for the definition of Uniform >> Resource Identifier (URI) schemes. It obsoletes RFC 4395. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Feb 17 07:24:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FEB1A04F9 for ; Mon, 17 Feb 2014 07:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n30T36Dma-ma for ; Mon, 17 Feb 2014 07:24:12 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 802FF1A0509 for ; Mon, 17 Feb 2014 07:23:58 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so5253422iga.1 for ; Mon, 17 Feb 2014 07:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=nVnoiQnHPoJxMUjx6sd1IT5967VCUxl0dygdju1S+p8=; b=j3zucByJvkgoCDzmZ3F57VpT875/bJMmEL42PfgCt7BhZjI3uVwyIANWL/SVoBcwz6 2aIMBc37q04a8SgABj13KDrJCLhLfbXQ4fRZmYZgV9WB+Gx2SrPq5uInQLCn8N0iefO2 0qSyGu2OrQsyeL2KsNP6Z95LbXYX+oBZtSzgopLCKHrIrxxsY9EL0enWR/f1ZLQTajbM AoxzbFWo50NEccIyTrz8ADtX7rYPRPp8LNAmLfg9a79fg/Eohet3l0QOTkWmOsLtDnke 87gjAHqb2WeiE4k757NSt2VMWOYmigLpvhqNbUJ08i0RHyAWZPML9YkbgmpbxWia6SSj BDzg== MIME-Version: 1.0 X-Received: by 10.42.92.194 with SMTP id u2mr17713060icm.19.1392650635952; Mon, 17 Feb 2014 07:23:55 -0800 (PST) Received: by 10.42.195.206 with HTTP; Mon, 17 Feb 2014 07:23:55 -0800 (PST) Date: Mon, 17 Feb 2014 10:23:55 -0500 Message-ID: From: Darrel Miller To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/ScflFfC4HB_gz9TRxsktY5EQH0g Subject: [apps-discuss] Question about json-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:24:14 -0000 In section 3 of the json-home spec[1], it states, > Resource Objects MUST have exactly one of the "href" and "href-vars" > properties. My understanding of this is that a resource must either provide a URL in the href property or a URI Template in the href-template property. I recently ran into an issue where I had a deployed json-home document with a resource that had a href property and it was decided to add support for an optional query parameter to the URI. Unfortunately, there is no way to change the json-home document to support this optional query parameter without making a breaking change. Is it really necessary to have both "href" and "href-template"? Can the presence of href-vars not be used as an indicator of something being a template? Is there some other way of supporting this evolution without having to introduce a new link relation type? Thanks, Darrel [1] http://tools.ietf.org/html/draft-nottingham-json-home-03#page-11 From nobody Mon Feb 17 09:09:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4261A0239 for ; Mon, 17 Feb 2014 09:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzfw-Q26rRfC for ; Mon, 17 Feb 2014 09:09:40 -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 BB8BD1A0207 for ; Mon, 17 Feb 2014 09:09:40 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1HH9Ved005618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 10:09:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: <53009C37.3030009@ninebynine.org> Date: Mon, 17 Feb 2014 09:09:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> References: <20140216035539.2686.qmail@joyce.lan> <53009C37.3030009@ninebynine.org> To: Pete Resnick , Barry Leiba X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9jlm3I7fFxkzWAop8Bt-JjSigJE Cc: IETF Apps Discuss Subject: [apps-discuss] Pete and Barry: now it is up to you (was: draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 17:09:42 -0000 There is clearly a question of whether the WEIRDS WG will be allowed to = use their current approach or be forced to change to templates. That = question cannot be answered by more messages on this mailing list. draft-ietf-weirds-using-http-08 has a protocol that would not be = acceptable if draft-ietf-appsawg-uri-get-off-my-lawn were already a BCP. = That determination should be answered sooner rather than later so that = the WG can progress with their protocol. --Paul Hoffman= From nobody Mon Feb 17 09:22:36 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D481A03F6 for ; Mon, 17 Feb 2014 09:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK3EgDcbYYmU for ; Mon, 17 Feb 2014 09:22:33 -0800 (PST) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id B57991A00B4 for ; Mon, 17 Feb 2014 09:22:33 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so14808957pdb.10 for ; Mon, 17 Feb 2014 09:22:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=l0xS71mPNraZBCAZJjyubWFUrAn6QL3Xsp0IkccmRTQ=; b=BaobMWjeX6KTqbEZm/9YKLJU8V3peszQ5NDtiJDJbgaJn1lb2sHpjBWeTuULjOOly+ 0lsvG19nCs3dn2uRkuMRE9pmG2fHNCndsLOfjuwesOSr6k3jC4cKKFaNzFjpTK47lK9K 5a79eyHKi7pLHUJasjLQDMVyXYxzjZUibtaN1EqgoIM3YiI73bLcIsHkh8mZwVan90hW aIHd0u74BzQq4bhJnKVlFK1BKOAg5e3X97kgHU4E7FJfx6GjManScfd3zphkU3XgZKgR +3Z43ZgoyTOFDclTo9chCazhFd/kAMVqLIiokda8n/rsd+RknQjvZnyvA/fALgyaY4rE tnIw== X-Gm-Message-State: ALoCoQkrftQCboLrvEp9EqKo8gnHIAbjiWyS4XYbC887zhPqNPTsB1babxpJjPHrJKoebsn58miV MIME-Version: 1.0 X-Received: by 10.68.202.8 with SMTP id ke8mr27857787pbc.86.1392657751267; Mon, 17 Feb 2014 09:22:31 -0800 (PST) Received: by 10.68.143.4 with HTTP; Mon, 17 Feb 2014 09:22:31 -0800 (PST) X-Originating-IP: [108.45.162.177] In-Reply-To: <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> References: <20140216035539.2686.qmail@joyce.lan> <53009C37.3030009@ninebynine.org> <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> Date: Mon, 17 Feb 2014 12:22:31 -0500 Message-ID: From: Andrew Newton To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CwB4jxXgSP8bbObAljW2hAXy5qc Cc: Pete Resnick , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Pete and Barry: now it is up to you (was: draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 17:22:35 -0000 On Mon, Feb 17, 2014 at 12:09 PM, Paul Hoffman wrote: > There is clearly a question of whether the WEIRDS WG will be allowed to use their current approach or be forced to change to templates. That question cannot be answered by more messages on this mailing list. > I think you have incorrectly framed the issue and resolution. The issue is if the WEIRDS WG is specifying a protocol with URI collisions. If they are, one of possible resolutions is to use URI templates. -andy From nobody Mon Feb 17 10:40:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650D71A0520 for ; Mon, 17 Feb 2014 10:40:12 -0800 (PST) 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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYrfUJSBwydE for ; Mon, 17 Feb 2014 10:40:10 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7DB1A04F0 for ; Mon, 17 Feb 2014 10:40:10 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id c14so12437230vea.17 for ; Mon, 17 Feb 2014 10:40:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8X3pFqWEgReN+9PqGsjeaG1Ng8Jmk4k7J5u94lN3E60=; b=mI1qTzwbLYvYAsGENGIork6NxOVpAp5a7HUgFKmnJF0aTwQ5/LT7OGwuREpo9BDhCy vA2RpmcvvfKo6l9xfkxIzp6mPpF5kTFTB8MB83fSK9doqD393tQ4dHM8acmAwOc6uwJz kQxt2Sydv//fGneY4awFmaT9oI21rHoYc6JniV7gtkeLZ8Jf7F1wR1dprLafxU2rQqCg rJ39IL3e9foj1ESRNZL/2ofd1po6wuvduNJZCnlcTqH0zgdIYgNhrQ4Niq+nLI8H8QHR JXFXsi4MKuxGhykhZBiR0dNSeORGIVlVsS9KcvF+AUs/cqmB4nf3dpG3TRfnmF9kY2nk 9I1Q== X-Gm-Message-State: ALoCoQm4U3tqEIzttbt7xmmeQAZRCiugL/ryrrMdT+wKgfTkgxDo/gNSUyajPFkbZh+YDn9d784X MIME-Version: 1.0 X-Received: by 10.52.188.41 with SMTP id fx9mr15031418vdc.19.1392662407297; Mon, 17 Feb 2014 10:40:07 -0800 (PST) Received: by 10.220.98.73 with HTTP; Mon, 17 Feb 2014 10:40:07 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20140216035539.2686.qmail@joyce.lan> <53009C37.3030009@ninebynine.org> <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> Date: Mon, 17 Feb 2014 10:40:07 -0800 Message-ID: From: Tim Bray To: Andrew Newton Content-Type: multipart/alternative; boundary=bcaec5485ca014532804f29e7c64 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lhiz0GNHUp_lrRf79wMBuD4LuRs Cc: Pete Resnick , Barry Leiba , Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Pete and Barry: now it is up to you (was: draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 18:40:12 -0000 --bcaec5485ca014532804f29e7c64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andy=E2=80=99s right, there are other ways out of the box. For example, to = use an HTTP header on their GET, or to use a POST rather than a GET with selector information in the message body. Or even better a PUT since it=E2=80=99s idempotent. On Mon, Feb 17, 2014 at 9:22 AM, Andrew Newton wrote: > On Mon, Feb 17, 2014 at 12:09 PM, Paul Hoffman > wrote: > > There is clearly a question of whether the WEIRDS WG will be allowed to > use their current approach or be forced to change to templates. That > question cannot be answered by more messages on this mailing list. > > > > I think you have incorrectly framed the issue and resolution. The > issue is if the WEIRDS WG is specifying a protocol with URI > collisions. If they are, one of possible resolutions is to use URI > templates. > > -andy > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --bcaec5485ca014532804f29e7c64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy=E2=80=99s right, there are other ways out of the box.= For example, to use an HTTP header on their GET, or to use a POST rather t= han a GET with selector information in the message body. =C2=A0Or even bett= er a PUT since it=E2=80=99s idempotent.


On Mon, Feb 1= 7, 2014 at 9:22 AM, Andrew Newton <andy@hxr.us> wrote:
On Mon, Feb 17, 2014 at 12:09 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> There is clearly a question of whether the WEIRDS WG will be allowed t= o use their current approach or be forced to change to templates. That ques= tion cannot be answered by more messages on this mailing list.
>

I think you have incorrectly framed the issue and resolution. The
issue is if the WEIRDS WG is specifying a protocol with URI
collisions. If they are, one of possible resolutions is to use URI
templates.

-andy

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

--bcaec5485ca014532804f29e7c64-- From nobody Mon Feb 17 11:08:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622281A051A for ; Mon, 17 Feb 2014 11:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIUy7ACVcNoJ for ; Mon, 17 Feb 2014 11:08:19 -0800 (PST) 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 9AE631A01F9 for ; Mon, 17 Feb 2014 11:07:44 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so2742760wib.6 for ; Mon, 17 Feb 2014 11:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eSPbkpoyfGUgNMm/Q+sM2Q2PFuo5W/3oNVXnxPaWB6k=; b=lIcByJ/JUkUp1eRz+yrPX7292cgLUurHBZjemHBr+lxYtgb+z1f4CSnjw8dq+68cIN 5WQASGed8TM5mhkVDuo4BRuZiZN8lqboAZVCUsB/sD1XCkx70a8UbL+t5f1BZQAa3CBy i/8J7IJQdO5dGoTbsA7Oq3DeVsYQcog+zRvZvex6m5vu0s82HchXlYRUkaNd8XOESD+r JirOamxDsr12hWqwmkiIcW+N34mPNIISWq9tx+RxyJWqNZUH694OQQ6Kc00Id1Z3QSC3 SSv2Qes//qFFBjE/K2Vxekg5mw/36WlsaS+ouZ71PBqXSy+I5XDbp77z166RlAANSqIy IC6g== MIME-Version: 1.0 X-Received: by 10.180.187.237 with SMTP id fv13mr14456361wic.26.1392664061505; Mon, 17 Feb 2014 11:07:41 -0800 (PST) Received: by 10.180.90.132 with HTTP; Mon, 17 Feb 2014 11:07:41 -0800 (PST) In-Reply-To: <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> References: <20140216035539.2686.qmail@joyce.lan> <53009C37.3030009@ninebynine.org> <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> Date: Mon, 17 Feb 2014 11:07:41 -0800 Message-ID: From: "Murray S. Kucherawy" To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c25a9cad8aa604f29ede11 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NAnruE0dTFg4eTQWxEMO2bvNDgg Cc: Pete Resnick , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Pete and Barry: now it is up to you (was: draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 19:08:21 -0000 --001a11c25a9cad8aa604f29ede11 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 17, 2014 at 9:09 AM, Paul Hoffman wrote: > There is clearly a question of whether the WEIRDS WG will be allowed to > use their current approach or be forced to change to templates. That > question cannot be answered by more messages on this mailing list. > > draft-ietf-weirds-using-http-08 has a protocol that would not be > acceptable if draft-ietf-appsawg-uri-get-off-my-lawn were already a BCP. > That determination should be answered sooner rather than later so that the > WG can progress with their protocol. Feedback about the content of draft-ietf-appsawg-uri-get-off-my-lawn is perfectly appropriate for this list. I don't believe there's any need to get the ADs to rule on anything at this point. Feedback specific to draft-ietf-weirds-using-http and how it resolves this question should appear on that WG's mailing list, and not here. I don't believe we need an AD ruling on anything there yet either; the WG is still doing its work on this document. -MSK, co-chair of both WGs --001a11c25a9cad8aa604f29ede11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 17, 2014 at 9:09 AM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
There is clearly a questi= on of whether the WEIRDS WG will be allowed to use their current approach o= r be forced to change to templates. That question cannot be answered by mor= e messages on this mailing list.

draft-ietf-weirds-using-http-08 has a protocol that would not be acceptable= if draft-ietf-appsawg-uri-get-off-my-lawn were already a BCP. That determi= nation should be answered sooner rather than later so that the WG can progr= ess with their protocol.

Feedback about the content of draft-ietf-appsawg-uri-get-off= -my-lawn is perfectly appropriate for this list.=A0 I don't believe the= re's any need to get the ADs to rule on anything at this point.

Feedback specific to draft-ietf-weirds-usi= ng-http and how it resolves this question should appear on that WG's ma= iling list, and not here.=A0 I don't believe we need an AD ruling on an= ything there yet either; the WG is still doing its work on this document.
-MSK, co-chair of both WGs
--001a11c25a9cad8aa604f29ede11-- From nobody Mon Feb 17 11:38:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5D71A0418 for ; Mon, 17 Feb 2014 11:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4M11bMWAzd8 for ; Mon, 17 Feb 2014 11:38:54 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id BDF561A0407 for ; Mon, 17 Feb 2014 11:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1392665932; x=1424201932; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Wg03GtAMbWYexRD0kOn8OdZhQtfFHio3+FAeg+91p20=; b=GW4xrsvgDxjY+HZ93vqtXN9SFVhuAUhlHWwPIxrveNsT1E3JPXvomR+V ty5tPAZgqviQlVtsHZSFNhQeFIamhOLGKFxvvVqehBd80H7m+BbYpHaGB 83gpBkwIL/Iuas3GFW/rbCigWVmNrcB6D7ShzQFqm9y2UyVnMgATLMZ19 g=; X-IronPort-AV: E=McAfee;i="5400,1158,7352"; a="59450221" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 17 Feb 2014 11:38:52 -0800 X-IronPort-AV: E=Sophos; i="4.95,862,1384329600"; d="scan'208,217"; a="27294594" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Feb 2014 11:38:51 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 11:38:50 -0800 Message-ID: <5302654A.30003@qti.qualcomm.com> Date: Mon, 17 Feb 2014 13:38:50 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <20140216035539.2686.qmail@joyce.lan> <53009C37.3030009@ninebynine.org> <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050505020703020407030105" X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/l4ioIrE3m7hFbIPW2TJysJlg9lU Cc: Barry Leiba , Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Pete and Barry: now it is up to you X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 19:38:57 -0000 --------------050505020703020407030105 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 2/17/14 12:40 PM, Tim Bray wrote: > On Mon, Feb 17, 2014 at 9:22 AM, Andrew Newton > wrote: > > On Mon, Feb 17, 2014 at 12:09 PM, Paul Hoffman > > wrote: >> There is clearly a question of whether the WEIRDS WG will be >> allowed to use their current approach or be forced to change to >> templates. That question cannot be answered by more messages on >> this mailing list. > > I think you have incorrectly framed the issue and resolution. The > issue is if the WEIRDS WG is specifying a protocol with URI > collisions. If they are, one of possible resolutions is to use URI > templates. > > > Andy's right, there are other ways out of the box. For example, to use > an HTTP header on their GET, or to use a POST rather than a GET with > selector information in the message body. Or even better a PUT since > it's idempotent. Yep. And as Murray said, the specific discussion belongs over on the WEIRDS list. The chairs of that WG (gee, do we know any of them?) should of course invite the right people into that discussion if they need specific inviting. And if progress can't be made on the list, perhaps some cross-group face-to-face time would solve the problem. (I wonder where and when that could happen... :-) ) Look, nobody died and made me (or Barry) king. This is a technical issue, and you folks need to figure it out. We (and the chairs) are here to help out if you finally decide, "We are not getting what these people are saying. Help us find a path out of this mess." But I don't think you all are there yet. It would help very much if both sides refrained from saying, "It's obvious that you don't get the obvious solution to this, which is obviously stated in our draft." Some folks are not understanding what the problem is (on both sides). Some folks are not explaining well enough for others to understand what the solution space is. If everyone gets on the same page, I'm hopeful that a good solution will at least be easier to see, if not "obvious". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------050505020703020407030105 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 2/17/14 12:40 PM, Tim Bray wrote:
On Mon, Feb 17, 2014 at 9:22 AM, Andrew Newton <andy@hxr.us> wrote:
On Mon, Feb 17, 2014 at 12:09 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
There is clearly a question of whether the WEIRDS WG will be allowed to use their current approach or be forced to change to templates. That question cannot be answered by more messages on this mailing list.

I think you have incorrectly framed the issue and resolution. The
issue is if the WEIRDS WG is specifying a protocol with URI
collisions. If they are, one of possible resolutions is to use URI
templates.

Andy’s right, there are other ways out of the box. For example, to use an HTTP header on their GET, or to use a POST rather than a GET with selector information in the message body.  Or even better a PUT since it’s idempotent.

Yep. And as Murray said, the specific discussion belongs over on the WEIRDS list. The chairs of that WG (gee, do we know any of them?) should of course invite the right people into that discussion if they need specific inviting. And if progress can't be made on the list, perhaps some cross-group face-to-face time would solve the problem. (I wonder where and when that could happen... :-) )

Look, nobody died and made me (or Barry) king. This is a technical issue, and you folks need to figure it out. We (and the chairs) are here to help out if you finally decide, "We are not getting what these people are saying. Help us find a path out of this mess." But I don't think you all are there yet.

It would help very much if both sides refrained from saying, "It's obvious that you don't get the obvious solution to this, which is obviously stated in our draft." Some folks are not understanding what the problem is (on both sides). Some folks are not explaining well enough for others to understand what the solution space is. If everyone gets on the same page, I'm hopeful that a good solution will at least be easier to see, if not "obvious".

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------050505020703020407030105-- From nobody Mon Feb 17 11:46:17 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5A1A01B0 for ; Mon, 17 Feb 2014 11:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYHVn7e9HIEd for ; Mon, 17 Feb 2014 11:46:13 -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 285EC1A0177 for ; Mon, 17 Feb 2014 11:46:13 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1HJk1e1013538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 12:46:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Mon, 17 Feb 2014 11:46:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <50CEC5B9-5B65-40E4-A176-5EAB3FE31B49@vpnc.org> References: <20140216035539.2686.qmail@joyce.lan> <53009C37.3030009@ninebynine.org> <0DB8F884-5E50-4DA2-AD0B-C07EBB2C8F47@vpnc.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4DbDJn-qIlzmLPqfdzTU-4Y0lIg Cc: Pete Resnick , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Pete and Barry: now it is up to you (was: draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 19:46:14 -0000 On Feb 17, 2014, at 11:07 AM, Murray S. Kucherawy = wrote: > Feedback about the content of draft-ietf-appsawg-uri-get-off-my-lawn = is perfectly appropriate for this list. =20 I believe what I said is feedback: > draft-ietf-weirds-using-http-08 has a protocol that would not be = acceptable if draft-ietf-appsawg-uri-get-off-my-lawn were already a BCP. That is, if Mark had gotten grumpier a year earlier and we already made = draft-ietf-appsawg-uri-get-off-my-lawn a BCP, it would *prevent* the = WEIRDS WG from doing what is in draft-ietf-weirds-using-http-08, = assuming that the Apps ADs wanted to enforce it. A BCP full of MUSTs = that are ignored does not sound like a good idea. Asking Pete and Barry to give direction now to this WG and/or to WEIRDS = seems appropriate, given the mere timing issue. --Paul Hoffman= From nobody Mon Feb 17 16:31:41 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EB51A00CB for ; Mon, 17 Feb 2014 16:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELlDaEsAgChw for ; Mon, 17 Feb 2014 16:31:37 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id C63631A029D for ; Mon, 17 Feb 2014 16:31:37 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.8.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7316E509B8; Mon, 17 Feb 2014 19:31:31 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: <5301FF8A.5030005@ninebynine.org> Date: Tue, 18 Feb 2014 11:31:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A7E0107-93D5-4800-858E-E7BB0899A4BE@mnot.net> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> <9108BBA8-5FA3-4E52-816D-56E22BA3CA41@mnot.net> <5301FF8A.5030005@ninebynine.org> To: Graham Klyne X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LRbQMJNmOW4KsZYhx6n1VmYQwb0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] URI scheme prefixes [was: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 00:31:40 -0000 On 17 Feb 2014, at 11:24 pm, Graham Klyne wrote: >> * CREF2 - The HTML5 folks have spec'd (not clear if they've = implemented) web+, so we should at least talk about it. To me, the = problem is that if somebody comes along and does something like email+, = which one wins -- i.e. do I now have to handle both email+web+http:// = and web+email+http:// as equivalent? Bleurgh. >>=20 >=20 > FWIW, I'd say web+foo and email+foo are simply different schemes. = There's no sense in which one can "win". My concern is that if we start using structure in schemes to denote = metadata (such as "this is OK to use in the Web security model" for = web+), it becomes possible that a scheme will need to use more than one = of these prefixes.=20 E.g., let's say "web+" and "foo+" are prefixes, and the "fnord" scheme = needs to use them both, for whatever it means. That means that the registered scheme might be "web+foo+fnord". Leaving = aside aesthetic issues*, there needs to be some very careful = specification both here and in the scheme prefix conventions, otherwise = the software looking for the "foo+" prefix isn't going to recognise the = scheme. Remember, the point of a prefix is so that *generic* software = can recognise something about the scheme. See, for example, the "web+" specification, which already tries to = register a prefix: = http://www.w3.org/html/wg/drafts/html/master/iana.html#web+-scheme-prefix = http://www.w3.org/html/wg/drafts/html/master/webappapis.html#custom-handle= rs > If the registerProtocolHandler() method is invoked with a scheme that = is neither a whitelisted scheme nor a scheme whose value starts with the = substring "web+" and otherwise contains only lowercase ASCII letters, = and whose length is at least five characters (including the "web+" = prefix), the user agent must throw a SecurityError exception. That means that foo+web+fnord won't work for the web+ use case, and if = foo+ is specified in the same manner, we're SOL. Now, we can say that there will only ever be one of these indicators at = a time, but if so, that should be explicit. Personally, I don't like = them anyway, so specifying them in such a restricted way may be a good = outcome. At any rate, since the W3C is still doing this, we do need to figure out = if we're going to allow prefixes to be registered, and if so, under what = conditions. Cheers, * That's not to say that aesthetics isn't worth considering. As web+ is = written, it's a huge incentive to create crazy, ugly URI schemes, so = they work in browsers; some might say "if they get popular, we'll just = whitelist them and they can omit web+", but X- taught us otherwise... -- Mark Nottingham http://www.mnot.net/ From nobody Mon Feb 17 17:39:25 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548F81A0280 for ; Mon, 17 Feb 2014 17:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH-rEFph4z20 for ; Mon, 17 Feb 2014 17:39:20 -0800 (PST) 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 99A151A01E7 for ; Mon, 17 Feb 2014 17:39:20 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id rl12so1863123iec.40 for ; Mon, 17 Feb 2014 17:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=G7JFhmZDCl95rWC6D3AU5z7q8r0gfU7cJxreZEwrCNE=; b=Uo0MkhXDoPacWtsiTPxlfDUukhBBZ1omzFkt886ooXkoym111go9ka37q8ewdoH1xd 1gioQu6k3qegQGq+TFDSwWRiw2m3dspkBAYOCs9ZCQLaFTX3y1BWvpOWsgtmDi2EbnKX 21W5p9Vty9g2a+sqFI76R2w6vtm4z7DS5WstPJQbKJj7U58aHpCHt05iNdJMESlgNl05 PT0fcYcwtSkIQpOoWHx7Fg8SmmbUMGM/SFCXq+tEaHhSxe/+452eAB++0BddSIxZ1giE SKTi091HS8CYpNXAGuBEhsYdqzNTYgChd1l8OtEfYNRaJRSCevyg5LBB52Ap6mub0hvi CcMg== MIME-Version: 1.0 X-Received: by 10.50.78.229 with SMTP id e5mr19168759igx.24.1392687557815; Mon, 17 Feb 2014 17:39:17 -0800 (PST) Received: by 10.42.195.206 with HTTP; Mon, 17 Feb 2014 17:39:17 -0800 (PST) In-Reply-To: <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> Date: Mon, 17 Feb 2014 20:39:17 -0500 Message-ID: From: Darrel Miller To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PZkYIvl4ZbzFCJMxHCV22jQA7oM Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 01:39:23 -0000 Dave, I read through the draft and I was hoping to find wording that would discourage the creation of URI schemes similar to those that have been created in the Windows Phone OS. Schemes like "Explorer.AssocActionId.BurnSelection", "Explorer.AssocActionId.EraseDisc", "Explorer.AssocActionId.EraseDisc" seem to be far from ideal scheme names. [1] Did I skip over the guidance that would prevent schemes like these or is the hope that by encouraging registration, this type of abomination could be avoided? Regards, Darrel [1] http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207065(v=vs.105).aspx On Fri, Feb 14, 2014 at 5:21 PM, Dave Thaler wrote: > This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI > WG closed, we've gone back to it being an individual submission. > This version addresses some of the issues raised on -04 (see > draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as > noted below. There are still a number of open issues for which, with > the permission and help of the appsawg chairs, I have filed issue > tracker tickets to track. > > I have not filed tickets for things already addressed in this version. > These are enumerated below, and if there are disagreements on any > then we can file a ticket for it. > > 1) The IRI WG previously agreed that the fragment component is not > scheme-specific, and that the doc should be updated to clarify that > a scheme definition should only define the scheme-specific part. > This is now done at end of section 1. > > 2) Since the IRI WG was closed, I reverted most of the IRI-specific > changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04. > I left in text clarifying that a URI scheme name and an IRI scheme > name were the same and hence there aren't separate registries, since > apparently that was a common question on RFC 4395. > > 3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > at last IETF, the IRI WG previously agreed that the 4-week mailing > list review was optional for Provisional. RFC 4395 was ambiguous as > to optional vs mandatory. Updated text in section 7.2 to make it > explicit that it is only mandatory for Permanent. > > 4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > at last IETF, RFC 4395's convention for private namespaces (i.e., > converting "." to "-" in scheme names based on a domain name) > causes conflicts. Updated example to use "." instead of "-" to > reduce collisions. And open ticket #17 covers the rest of the > conflict problem. > > 5) Combined the Permanent, Provisional, and Historical URI Scheme > sub-registries into one URI Scheme registry with a status column. > This is done to make it easier to prevent duplicates and see > existing conventions, as well as to support the "Pending Review" > temporary state added in draft-ietf-iri-4395bis-irireg. > > -Dave > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 14, 2014 12:13 PM > To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry Masinter; Ted Hardie; Tony Hansen; Tony Hansen > Subject: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt > > > A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt > has been successfully submitted by Dave Thaler and posted to the IETF repository. > > Name: draft-thaler-appsawg-uri-scheme-reg > Revision: 00 > Title: Guidelines and Registration Procedures for New URI Schemes > Document date: 2014-02-14 > Group: Individual Submission > Pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-thaler-appsawg-uri-scheme-reg-00.txt > Status: https://datatracker.ietf.org/doc/draft-thaler-appsawg-uri-scheme-reg/ > Htmlized: http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme-reg-00 > > > Abstract: > This document updates the guidelines and recommendations, as well as > the IANA registration processes, for the definition of Uniform > Resource Identifier (URI) schemes. It obsoletes RFC 4395. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Feb 17 19:27:23 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2191D1A0324 for ; Mon, 17 Feb 2014 19:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifs06DV1DUXa for ; Mon, 17 Feb 2014 19:27:17 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 565C51A0309 for ; Mon, 17 Feb 2014 19:27:17 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.878.16; Tue, 18 Feb 2014 03:27:13 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0878.008; Tue, 18 Feb 2014 03:27:13 +0000 From: Dave Thaler To: "darrel@tavis.ca" Thread-Topic: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt Thread-Index: AQHPKcEaJNqgQQL1fEW4nlD27YvlO5q1S01ggAAFZJCABPBFgIAAHNfw Date: Tue, 18 Feb 2014 03:27:12 +0000 Message-ID: <7a4437b4b0ed4b09930c396e39ba52b6@BY2PR03MB412.namprd03.prod.outlook.com> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(51704005)(83322001)(46102001)(54316002)(19580395003)(31966008)(56816005)(81816001)(90146001)(93516002)(4396001)(59766001)(69226001)(47736001)(56776001)(50986001)(80976001)(15202345003)(79102001)(33646001)(81686001)(74876001)(77982001)(92566001)(51856001)(74662001)(47976001)(76786001)(76796001)(83072002)(74502001)(85852003)(49866001)(87266001)(95416001)(74366001)(85306002)(94946001)(66066001)(65816001)(80022001)(76482001)(86362001)(2656002)(76576001)(63696002)(54356001)(47446002)(53806001)(87936001)(86612001)(94316002)(95666001)(93136001)(15975445006)(81542001)(81342001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:24EEF5BE.8DF553E9.1DF9F73.4EEBB978.20217; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/3_3c0hRc7o3K6sZxKPN4Q1ZWEGo Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 03:27:20 -0000 Darrel Miller writes: > I read through the draft and I was hoping to find wording that would > discourage the creation of URI schemes similar to those that have been > created in the Windows Phone OS. Schemes like > "Explorer.AssocActionId.BurnSelection", > "Explorer.AssocActionId.EraseDisc", "Explorer.AssocActionId.EraseDisc" > seem to be far from ideal scheme names. [1] >=20 > Did I skip over the guidance that would prevent schemes like these or is = the > hope that by encouraging registration, this type of abomination could be > avoided? >=20 > Regards, >=20 > Darrel >=20 > [1] http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj207065= (v=3Dvs.105).aspx It's an open issue covered by CREF3 at the end of section 3.8: > [[CREF3: Open Issue: > Are strings that look like reversed FQDNs (other than grandfathered > ones like "iris.beep") reserved for use as such? Proposed answer is > Yes, new schemes should not use a "." unless they are actually > constructed from a domain name. --DT]] And tracked by ticket #17: http://trac.tools.ietf.org/wg/appsawg/trac/ticke= t/17 Besides the above issue, the other reasons I'm aware of that those examples might be frowned on are already covered in section 3.8. -Dave From nobody Tue Feb 18 00:55:43 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3FC1A0058 for ; Tue, 18 Feb 2014 00:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boUGq_KbqRBC for ; Tue, 18 Feb 2014 00:55:38 -0800 (PST) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0671A00A6 for ; Tue, 18 Feb 2014 00:55:38 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WFgSk-0000bb-aJ; Tue, 18 Feb 2014 08:55:34 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WFgSj-0005eJ-8u; Tue, 18 Feb 2014 08:55:34 +0000 Message-ID: <53031DDF.2080000@ninebynine.org> Date: Tue, 18 Feb 2014 08:46:23 +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: Mark Nottingham References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> <9108BBA8-5FA3-4E52-816D-56E22BA3CA41@mnot.net> <5301FF8A.5030005@ninebynine.org> <0A7E0107-93D5-4800-858E-E7BB0899A4BE@mnot.net> In-Reply-To: <0A7E0107-93D5-4800-858E-E7BB0899A4BE@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/BZcfVP6AvqStt86NM-zCVBaSFbs Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] URI scheme prefixes [was: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 08:55:41 -0000 On 18/02/2014 00:31, Mark Nottingham wrote: > > On 17 Feb 2014, at 11:24 pm, Graham Klyne wrote: > >>> * CREF2 - The HTML5 folks have spec'd (not clear if they've implemented) web+, so we should at least talk about it. To me, the problem is that if somebody comes along and does something like email+, which one wins -- i.e. do I now have to handle both email+web+http:// and web+email+http:// as equivalent? Bleurgh. >>> >> >> FWIW, I'd say web+foo and email+foo are simply different schemes. There's no sense in which one can "win". > > My concern is that if we start using structure in schemes to denote metadata (such as "this is OK to use in the Web security model" for web+), it becomes possible that a scheme will need to use more than one of these prefixes. > Yes, I agree. That was the point of my comment: IMO, web+ and email+ are not (formally) structure, just a particular (and maybe fanciful) way of constructing a name. Apologies that I wasn't clearer about that. The problem comes, as you point out later, when other specifications try to exploit such fanciful name-forms in potentially inconsistent ways. #g -- > E.g., let's say "web+" and "foo+" are prefixes, and the "fnord" scheme needs to use them both, for whatever it means. > > That means that the registered scheme might be "web+foo+fnord". Leaving aside aesthetic issues*, there needs to be some very careful specification both here and in the scheme prefix conventions, otherwise the software looking for the "foo+" prefix isn't going to recognise the scheme. Remember, the point of a prefix is so that *generic* software can recognise something about the scheme. > > See, for example, the "web+" specification, which already tries to register a prefix: > http://www.w3.org/html/wg/drafts/html/master/iana.html#web+-scheme-prefix > http://www.w3.org/html/wg/drafts/html/master/webappapis.html#custom-handlers > >> If the registerProtocolHandler() method is invoked with a scheme that is neither a whitelisted scheme nor a scheme whose value starts with the substring "web+" and otherwise contains only lowercase ASCII letters, and whose length is at least five characters (including the "web+" prefix), the user agent must throw a SecurityError exception. > > That means that foo+web+fnord won't work for the web+ use case, and if foo+ is specified in the same manner, we're SOL. > > Now, we can say that there will only ever be one of these indicators at a time, but if so, that should be explicit. Personally, I don't like them anyway, so specifying them in such a restricted way may be a good outcome. > > At any rate, since the W3C is still doing this, we do need to figure out if we're going to allow prefixes to be registered, and if so, under what conditions. > > Cheers, > > * That's not to say that aesthetics isn't worth considering. As web+ is written, it's a huge incentive to create crazy, ugly URI schemes, so they work in browsers; some might say "if they get popular, we'll just whitelist them and they can omit web+", but X- taught us otherwise... > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Feb 18 23:18:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534A81A056C for ; Tue, 18 Feb 2014 23:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwJqwt76xJFh for ; Tue, 18 Feb 2014 23:18:11 -0800 (PST) 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 41E011A056B for ; Tue, 18 Feb 2014 23:18:11 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q59so5570wes.6 for ; Tue, 18 Feb 2014 23:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jppukRAv7wQndGRO3W2rukeBRyDyMUT6DoEdPEEoHgU=; b=fANzNFfLpxZEKfg9+aNev3SePy0RqbkcERiy321/W+3NrjU9HGU1GrMuTUn4jqXfvE Her9/TwdEgWT2SAT7rQj5BrGqfx8FKzEOz/CMByou1GTdh8b8PF1e7KvdIyvRVq2X4Jg 2b5aGPvQOLpmQ7BGLwPQH3gGBzEgFKmWYNRe8qMuM1AJBNcEh0/nu6789hz5YY0xYyFO YzZnn1dDXtitPXR0VTlu9XHJafn/IAOlDvcgu3IqeyPMSXYnBOLcCf/hpvHaGG3xtqMp BGpLxPbRBC4iGriStje37sDYkWUNwX+GFfPmB7NP2D17N1H9uk4enKzVt6IBjXc8tOD3 aFXg== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr27217099wjc.9.1392794287726; Tue, 18 Feb 2014 23:18:07 -0800 (PST) Received: by 10.180.90.132 with HTTP; Tue, 18 Feb 2014 23:18:07 -0800 (PST) Date: Tue, 18 Feb 2014 23:18:07 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b873a10c3e71f04f2bd30a8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/eYWqCvuYjKKqy7GuIKQPA03FoqQ Subject: [apps-discuss] IETF 89 APPSAWG/APPAREA agenda items X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 07:18:13 -0000 --047d7b873a10c3e71f04f2bd30a8 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, So far we have only received two requests for face time at APPSAWG in London, for about 15 minutes each. Besides that, we have our usual new WG/BoF overviews and some quick document status updates and administrivia, and we're waiting on our ADs to give us their agenda items, but apart from that the agenda is looking somewhat sparse as compared to our normal full docket. Thus, last call: Please submit requests for time slots in London for issues that require WG or APPS community attention ASAP. The draft agenda is already overdue, and the final agenda is due this coming Monday. -MSK, APPSAWG co-chair --047d7b873a10c3e71f04f2bd30a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

So far we have only received = two requests for face time at APPSAWG in London, for about 15 minutes each.= =A0 Besides that, we have our usual new WG/BoF overviews and some quick doc= ument status updates and administrivia, and we're waiting on our ADs to= give us their agenda items, but apart from that the agenda is looking some= what sparse as compared to our normal full docket.

Thus, last call: Please submit requests for time slots in London = for issues that require WG or APPS community attention ASAP.=A0 The draft a= genda is already overdue, and the final agenda is due this coming Monday.
-MSK, APPSAWG co-chair

--047d7b873a10c3e71f04f2bd30a8-- From nobody Wed Feb 19 01:29:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC4D1A02D9 for ; Wed, 19 Feb 2014 01:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dob9ux9CxZ7p for ; Wed, 19 Feb 2014 01:28:54 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 373111A0396 for ; Wed, 19 Feb 2014 01:28:54 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WG3ST-0002Ir-Ey; Wed, 19 Feb 2014 01:28:50 -0800 Message-ID: <5304794D.1030808@berkeley.edu> Date: Wed, 19 Feb 2014 10:28:45 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: darrel@tavis.ca, IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/h6NWbsaxe9twl3kj9YZskw19JHU Subject: Re: [apps-discuss] Question about json-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 09:29:00 -0000 hello darrel. On 2014-02-17, 16:23 , Darrel Miller wrote: > In section 3 of the json-home spec[1], it states, >> Resource Objects MUST have exactly one of the "href" and "href-vars" >> properties. > My understanding of this is that a resource must either provide a URL > in the href property or a URI Template in the href-template property. yes, i do think that this is the current model. but please note that there is a later, but related draft on "Link Hints": http://tools.ietf.org/html/draft-nottingham-link-hint this one is strictly about URIs (i.e., not templates), and basically factors out the capability to represent information that might be helpful when following a link. since in some of the work we've been doing we need this capability to also cover URI templates, there's also a "Link Descriptions" draft, which supports URI templates: http://tools.ietf.org/html/draft-wilde-link-desc there's quite a bit of overlap between those two drafts, but the second one might be interesting in terms of combining URIs and URI templates. > I recently ran into an issue where I had a deployed json-home document > with a resource that had a href property and it was decided to add > support for an optional query parameter to the URI. Unfortunately, > there is no way to change the json-home document to support this > optional query parameter without making a breaking change. i think that's due to *two* reasons. one reason is that yes, you made a change and would like to make that change in the home document. but more importantly, you've moved from using URIs to using URI templates. it's kind of hard to imagine how you can make that latter change without breaking things, when you assume that before that change, everything was happily working without having to support URI templates. > Is it really necessary to have both "href" and "href-template"? Can > the presence of href-vars not be used as an indicator of something > being a template? technically yes, but what you're doing then is to basically *only* support href-template (i.e., URI templates), and use the absence of variables to conclude that the template is one that does not contain any variables. which btw may not be what you should do, because there's no requirement that *all* variables in a template are described via href-vars. at least in our cases, we might happily omit variables *in the description* where their semantics are static and captured by the link relation. we would then only serve variable descriptions for those variables where interesting things (such as value ranges) change at runtime, so that clients can see those changing runtime constraints. > Is there some other way of supporting this evolution without having to > introduce a new link relation type? i don't think so, if you're really moving from a URI to a URI template. you could envision a design where you *only* use URI templates, and some of them happen to have no variables. then you could safely add a variable to such a template, but on the other hand, you would create a design where all clients must support URI templates, and not just URIs. 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 nobody Wed Feb 19 02:06:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32481A0448 for ; Wed, 19 Feb 2014 02:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5-OGe8PerSy for ; Wed, 19 Feb 2014 02:05:53 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id A6C321A012B for ; Wed, 19 Feb 2014 02:05:53 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] 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 1WG42G-0007qR-5m; Wed, 19 Feb 2014 02:05:50 -0800 Message-ID: <530481F8.3010708@berkeley.edu> Date: Wed, 19 Feb 2014 11:05:44 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: darrel@tavis.ca, IETF Apps Discuss References: <5304794D.1030808@berkeley.edu> In-Reply-To: <5304794D.1030808@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/sTr_6lxfWSrGV7Iz3LHs2waLkWg Subject: Re: [apps-discuss] Question about json-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 10:05:55 -0000 hello darrel. after thinking about this for a little while... On 2014-02-19, 10:28 , Erik Wilde wrote: > On 2014-02-17, 16:23 , Darrel Miller wrote: >> Is there some other way of supporting this evolution without having to >> introduce a new link relation type? > i don't think so, if you're really moving from a URI to a URI template. > you could envision a design where you *only* use URI templates, and some > of them happen to have no variables. then you could safely add a > variable to such a template, but on the other hand, you would create a > design where all clients must support URI templates, and not just URIs. ...i guess i missed the obvious possibility to allow both a URI and a URI template. i don't know why the current model specifically disallows this, but i guess you could change the model to allow both. then you could safely add a template, and still leave the URI in there. but in such a case, the link relation should probably say what to do in such a scenario: can clients freely choose between the URI and the template? or is the URI only for those clients not supporting templates? and this is where it gets a bit tricky, because strictly speaking, link relations do not even apply to templates: RFC 5988 predates templates, and thus does not say anything about them. i guess it would be nice to either revise RFC 5988 to also talk about templates, or to have an additional RFC about "Templated Web Linking". but that may be a bit more work than what you were asking for ;-) 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 nobody Wed Feb 19 07:04:16 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19F81A0206 for ; Wed, 19 Feb 2014 07:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkPZgn2IDcGa for ; Wed, 19 Feb 2014 07:04:11 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 822E41A01DE for ; Wed, 19 Feb 2014 07:04:11 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id lx4so300156iec.32 for ; Wed, 19 Feb 2014 07:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Chnupg7LH1gRw2uLy+ybI6il5VCdqh8NiJpvsU3MxP4=; b=ps5y98Jp0eVxltufHsyOUrNCqU0IWVoT21aGZncmzIBLFVo9zpZbTmjjJM9inj8rUu tF+YHW9n0o4FrS1H80PNSiMXRT4px2yEBleDzvxzWMxvuJRnQxPtFh6dhxVqOjAaaAOI dbLGz2o/XKMxF/gTDT8cwahlwKRbYpSt6JaKKXYIx7TmW+zonamneG25ZUwfYGWzySxZ VWeqqisJML8NniJj3oLh9HPou482wkhk7lvJH5eqL5FGEK3RJ/ecEA+lVMmNyRm13b+h qwrF4SXLuTSXQtIsE/h7b1TGfSs3uocg88a3GQRnf8pbXUJQtUpIxr0rHcZlAF/eEOtp dAhQ== MIME-Version: 1.0 X-Received: by 10.43.75.9 with SMTP id yy9mr2068193icb.54.1392822248025; Wed, 19 Feb 2014 07:04:08 -0800 (PST) Received: by 10.42.195.206 with HTTP; Wed, 19 Feb 2014 07:04:07 -0800 (PST) In-Reply-To: <530481F8.3010708@berkeley.edu> References: <5304794D.1030808@berkeley.edu> <530481F8.3010708@berkeley.edu> Date: Wed, 19 Feb 2014 10:04:07 -0500 Message-ID: From: Darrel Miller To: Erik Wilde Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/0N91B8bolN0urWeXEJgT91gPY1Q Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Question about json-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:04:14 -0000 Erik, Thanks for your feedback. I am familiar with the link-hints spec. My library for supporting json-home[1] uses my Link implementation[2] which has support for adding link hints. I was not familiar with your link-desc spec. I will investigate further. The scenario arose because we provided a link to a collection of items, e.g. http://api.acme.com/orders/recent The definition of the recent period was defined by the server. A request was made by a customer to enable them to define it. http://api.acme.com/orders/recent{?days} I see this evolution as a fairly normal one. It seems somewhat painful to have to mint a new extension link relation type to be able to support this. I see now that RFC 6570 states that, > Distinct field, element, or attribute names should be used to > differentiate protocol elements that carry a URI Template from those > that expect a URI reference. So that discourages attempting to re-use href to hold a template. The current json-home spec explicitly prevents href and href-values from existing at the same time. If that were to change, then it would be possible to have href and href-template at the same time. There does seem to be some merit to having a "default" href for clients that don't support templates and the more flexible template URI. And that would resolve my evolution problem. Regarding the issue of link relations not being aware of URI templates, my understanding of link relations seems to be much more liberal than most peoples'. >From RFC 5988 > a link relation type identifies the semantics of a link and > Link relation types can also be used to indicate that the target > resource has particular attributes, or exhibits particular > behaviours; for example, a "service" link implies that the identified > resource is part of a defined protocol (in this case, a service > description). I take this to mean, I can choose to define my link relation as requiring template processing of a link's target URI. Maybe I am stretching the intent, but I have yet to be convinced of any negative impacts that outweigh the benefits. Regards, Darrel [1] https://github.com/tavis-software/Tavis.home [2] https://github.com/tavis-software/Link On Wed, Feb 19, 2014 at 5:05 AM, Erik Wilde wrote: > hello darrel. > > after thinking about this for a little while... > > > On 2014-02-19, 10:28 , Erik Wilde wrote: >> >> On 2014-02-17, 16:23 , Darrel Miller wrote: >>> >>> Is there some other way of supporting this evolution without having to >>> introduce a new link relation type? >> >> i don't think so, if you're really moving from a URI to a URI template. >> you could envision a design where you *only* use URI templates, and some >> of them happen to have no variables. then you could safely add a >> variable to such a template, but on the other hand, you would create a >> design where all clients must support URI templates, and not just URIs. > > > ...i guess i missed the obvious possibility to allow both a URI and a URI > template. i don't know why the current model specifically disallows this, > but i guess you could change the model to allow both. then you could safely > add a template, and still leave the URI in there. > > but in such a case, the link relation should probably say what to do in such > a scenario: can clients freely choose between the URI and the template? or > is the URI only for those clients not supporting templates? > > and this is where it gets a bit tricky, because strictly speaking, link > relations do not even apply to templates: RFC 5988 predates templates, and > thus does not say anything about them. i guess it would be nice to either > revise RFC 5988 to also talk about templates, or to have an additional RFC > about "Templated Web Linking". but that may be a bit more work than what you > were asking for ;-) > > > 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 | > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Feb 19 08:44:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E21C1A04E7 for ; Wed, 19 Feb 2014 08:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqjbQy_xeNlE for ; Wed, 19 Feb 2014 08:44:36 -0800 (PST) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 54A281A01CE for ; Wed, 19 Feb 2014 08:44:36 -0800 (PST) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1WGAG7-00045r-I9; Wed, 19 Feb 2014 08:44:33 -0800 Message-ID: <5304DF6B.8090007@berkeley.edu> Date: Wed, 19 Feb 2014 17:44:27 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: darrel@tavis.ca References: <5304794D.1030808@berkeley.edu> <530481F8.3010708@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/VGqVQH8I7BqLgoDoPb-ChQR8H6U Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Question about json-home X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 16:44:39 -0000 hello darrel. On 2014-02-19, 16:04 , Darrel Miller wrote: > The scenario arose because we provided a link to a collection of items, e.g. > http://api.acme.com/orders/recent > The definition of the recent period was defined by the server. A > request was made by a customer to enable them to define it. > http://api.acme.com/orders/recent{?days} > I see this evolution as a fairly normal one. It seems somewhat > painful to have to mint a new extension link relation type to be able > to support this. that's true, but the main issue here seems to be that you're moving from a URI to a URI template, instead of moving from a URI template with no variables to one that has one. i see the first move as changing your interface, while the second move is much less problematic. > I see now that RFC 6570 states that, >> Distinct field, element, or attribute names should be used to >> differentiate protocol elements that carry a URI Template from those >> that expect a URI reference. > So that discourages attempting to re-use href to hold a template. yes, and i think the reason behind that is that URI templates need to be processed differently. so you cannot suddenly use a template in a place where you were using a URI before. it's a type error. over time (if URI template use picks up), i would expect languages and frameworks to support both (think xs:URItemplate and XQuery/XSLT helper functions to process them), with a URI then simply being a special case of a URI template. > The current json-home spec explicitly prevents href and href-values > from existing at the same time. If that were to change, then it would > be possible to have href and href-template at the same time. yes. i am not quite sure why it prohibits using both at the same time. as long as it would also say what that would mean, that might solve your problem. > There does seem to be some merit to having a "default" href for > clients that don't support templates and the more flexible template > URI. And that would resolve my evolution problem. yes. or, next time, you choose a design where you *always* use URI templates, and some of them simply have no variables. but that might annoy clients who now have to start understanding the URI template model, even if all they're ever using are plain URIs. > Regarding the issue of link relations not being aware of URI > templates, my understanding of link relations seems to be much more > liberal than most peoples'. From RFC 5988 >> a link relation type identifies the semantics of a link > and >> Link relation types can also be used to indicate that the target >> resource has particular attributes, or exhibits particular >> behaviours; for example, a "service" link implies that the identified >> resource is part of a defined protocol (in this case, a service >> description). > I take this to mean, I can choose to define my link relation as > requiring template processing of a link's target URI. Maybe I am > stretching the intent, but I have yet to be convinced of any negative > impacts that outweigh the benefits. i did not want to say that it's a bad idea to use link relations for URI templates. and i think what you're trying to do makes a lot of sense and is the right way to go. all i wanted to say was that if URI templates become more common, it might be useful to have "Web Linking" that addresses how to use them explicitly. 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 nobody Wed Feb 19 13:42:22 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB51A050B for ; Wed, 19 Feb 2014 13:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urhd-Dnoyx9a for ; Wed, 19 Feb 2014 13:42:19 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC3B1A04FB for ; Wed, 19 Feb 2014 13:42:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C14CD2940DA for ; Wed, 19 Feb 2014 15:42:15 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze5-YQe8iP1M for ; Wed, 19 Feb 2014 15:42:15 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9DFA02940CD for ; Wed, 19 Feb 2014 15:42:15 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8EA642940CA for ; Wed, 19 Feb 2014 15:42:15 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tvvh_bP1mk39 for ; Wed, 19 Feb 2014 15:42:15 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 668633F4108 for ; Wed, 19 Feb 2014 15:42:15 -0600 (CST) Date: Wed, 19 Feb 2014 15:42:14 -0600 (CST) From: Franck Martin To: apps-discuss@ietf.org Message-ID: <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.1.211.245] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF27 (Mac)/8.0.5_GA_5839) Thread-Topic: I-D Action: draft-ietf-appsawg-nullmx-00.txt Thread-Index: f+WLqgOShh6xfA6N0C7OZv4a9wBZrw== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/CMjNdWfAg5-K7eR1rrr9bnldsdg Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 21:42:21 -0000 This draft requires current filtering solutions to change behavior. The presence of an MX will indicate the domain is emailable (cf spamassassin rules) until the software is changed to recognize the 0. We will have different behavior while this is getting implemented. The same functionality can be achieved with example.com "v=SPF1 -all" *.example.com "v=SPF1 -all" Which would cover also any subdomain and will not have different interpretation while being deployed. ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: apps-discuss@ietf.org Sent: Saturday, February 15, 2014 1:03:19 AM Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : A NULL MX Resource Record for Domains that Accept No Mail Authors : John Levine Mark Delany Filename : draft-ietf-appsawg-nullmx-00.txt Pages : 5 Date : 2014-02-14 Abstract: When the 5321.MailFrom domain in an e-mail message has a DNS MX Resource Record (RR), it is making an explicit statement that it is willing to accept email. However, when the domain has just a DNS A or AAAA RR, there mail clients cannot easily tell whether the domain accepts mail, as many hosts on the Internet advertise an A or AAAA RR regardless of whether they want to accept email. The NULL MX RR formalizes the existing mechanism by which a domain announces that it accepts no mail. From nobody Wed Feb 19 14:03:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B491A0277 for ; Wed, 19 Feb 2014 14:03:55 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG5RIYs3RTOZ for ; Wed, 19 Feb 2014 14:03:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 31E921A0272 for ; Wed, 19 Feb 2014 14:03:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P4JKS5T5WG0000NK@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 19 Feb 2014 13:58:47 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P4J9ABAI0G00004W@mauve.mrochek.com>; Wed, 19 Feb 2014 13:58:44 -0800 (PST) Message-id: <01P4JKS49U0U00004W@mauve.mrochek.com> Date: Wed, 19 Feb 2014 13:51:32 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 19 Feb 2014 15:42:14 -0600 (CST)" <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> To: Franck Martin Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Rb7S0jRnarwoC_dMrmwIO36O-YQ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:03:55 -0000 > This draft requires current filtering solutions to change behavior. The > presence of an MX will indicate the domain is emailable (cf spamassassin rules) > until the software is changed to recognize the 0. We will have different > behavior while this is getting implemented. The domain validity check is extremely weak to begin with. And given the speed at which such rules have to evolve for other reasons, even if you think this deserves consideration - which I don't - it's a miniscule factor in the overall scheme of AS/AV solutions. > The same functionality can be achieved with > example.com "v=SPF1 -all" > *.example.com "v=SPF1 -all" It's not even remotely the same functionality. The point of the nullmx mechanism is to inform agents *sending* messages to the domain that there's no point in even bothering making a connection. To the best of my knowlege nobody looks at SPF records for domain before attempting to send mail to them. > Which would cover also any subdomain and will not have different > interpretation while being deployed. If you're seriously proposing that SMTP clients start looking at SPF records, that a MAJOR change that would be a major PITA to get deployed. Ned > ----- Original Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Sent: Saturday, February 15, 2014 1:03:19 AM > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > Title : A NULL MX Resource Record for Domains that Accept No Mail > Authors : John Levine > Mark Delany > Filename : draft-ietf-appsawg-nullmx-00.txt > Pages : 5 > Date : 2014-02-14 > Abstract: > When the 5321.MailFrom domain in an e-mail message has a DNS MX > Resource Record (RR), it is making an explicit statement that it is > willing to accept email. However, when the domain has just a DNS A > or AAAA RR, there mail clients cannot easily tell whether the domain > accepts mail, as many hosts on the Internet advertise an A or AAAA RR > regardless of whether they want to accept email. > The NULL MX RR formalizes the existing mechanism by which a domain > announces that it accepts no mail. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Feb 19 14:34:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4A11A025C for ; Wed, 19 Feb 2014 14:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0VY3LIyCb8H for ; Wed, 19 Feb 2014 14:34:39 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5038E1A0239 for ; Wed, 19 Feb 2014 14:34:39 -0800 (PST) Received: (qmail 96598 invoked from network); 19 Feb 2014 22:34:35 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 19 Feb 2014 22:34:35 -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; s=5305317b.xn--30v786c.k1402; i=johnl@user.iecc.com; bh=mTPP0Yo2SpVE3jSWGu6cV2lxnblE7aJKJoHJYQyfywI=; b=TwBUfxEBshDY2pNmSHlk8aLvXnynvTxvgasQgDewR0sR2m+D/VWWvw8YFEkt3uLuA344ZieV+C9YHC0BJ+k3acthppEHn83rV7phHvjDBVbjzzPikIKxPnksK4CmYmK2DGSlnIKBoFyIBwX2VLn2losrqcd/wX/UlNR3SyZ2G+sODGnKlWUZlhScWOV1BhvP02DI87sq1YNGz8fcEWuteqsBeOPW5zvuQ2uqUsOmws3jtpTFvd2xWe0VcQnsrqfc 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; s=5305317b.xn--30v786c.k1402; bh=mTPP0Yo2SpVE3jSWGu6cV2lxnblE7aJKJoHJYQyfywI=; b=LDPXtAOTFMzk7zDy/Za+KBE+d5Kg9pynz/UHXiLuNtrGhucHdOGFdm2mbY/+uEIIMa+DeFZUwbkXkuvyBMx+KzsXyHt/MIeMGEclcDOifpA7K5MCBY6a2dq/o3iR6tTgC7kEEUHhHY6Rl1BwuFYgnt1sPf3Bq7f7H7PGQRVIub0l8iCbrpqrxzHTGyCWogveNTRNMtfyD0yBUlIF04ku/WtBddk8hJR3y3XWSZMaHyXE2KpPsaCUbXLMBWVVhhln Date: 19 Feb 2014 22:34:11 -0000 Message-ID: <20140219223411.2948.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HALF8Qw4j-uoVT99nI4v_sGd3_0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 22:34:41 -0000 >The same functionality can be achieved with > >example.com "v=SPF1 -all" You might want to reread the draft, in particular Section 5, and reconsider that claim. Also, as the draft explains in Section 1, the point of nullmx is basically to undo the default to A/AAAA hack for domains with A/AAAA records that don't accept mail. Even if Spamassassin and other spam filters don't add rules to look for MX . they're no worse off than they are now. R's, John From nobody Wed Feb 19 15:51:42 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9EE1A040A for ; Wed, 19 Feb 2014 15:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQETVD3u3l7t for ; Wed, 19 Feb 2014 15:51:38 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA61A02DB for ; Wed, 19 Feb 2014 15:51:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5960F390040; Wed, 19 Feb 2014 17:51:34 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nazd8H-aU7AL; Wed, 19 Feb 2014 17:51:34 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3BBDF390058; Wed, 19 Feb 2014 17:51:34 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2614B39004D; Wed, 19 Feb 2014 17:51:34 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mTKoMYrtVcmo; Wed, 19 Feb 2014 17:51:34 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 08DFF390040; Wed, 19 Feb 2014 17:51:34 -0600 (CST) Date: Wed, 19 Feb 2014 17:51:32 -0600 (CST) From: Franck Martin To: Ned Freed Message-ID: <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> <01P4JKS49U0U00004W@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF27 (Mac)/8.0.5_GA_5839) Thread-Topic: I-D Action: draft-ietf-appsawg-nullmx-00.txt Thread-Index: jAKcQDKvYWUW5kcKBJV5bktpHdf7vQ== Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/nLBAdhcvUzHLHS3tK56mSj6GsUM Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 23:51:40 -0000 ----- Original Message ----- > From: "Ned Freed" > To: "Franck Martin" > Cc: apps-discuss@ietf.org > Sent: Wednesday, February 19, 2014 1:51:32 PM > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt > > > This draft requires current filtering solutions to change behavior. The > > presence of an MX will indicate the domain is emailable (cf spamassassin > > rules) > > until the software is changed to recognize the 0. We will have different > > behavior while this is getting implemented. > > The domain validity check is extremely weak to begin with. And given the > speed > at which such rules have to evolve for other reasons, even if you think this > deserves consideration - which I don't - it's a miniscule factor in the > overall scheme of AS/AV solutions. It is in spamassassin and others, not sure the word miniscule "apply" here. Furthermore anything that weakens anti-spam measure should not be encouraged by a body like IETF, which wants to increase the security of the Internet. > > > The same functionality can be achieved with > > > example.com "v=SPF1 -all" > > *.example.com "v=SPF1 -all" > > It's not even remotely the same functionality. The point of the nullmx > mechanism is to inform agents *sending* messages to the domain that there's > no point in even bothering making a connection. To the best of my knowlege > nobody looks at SPF records for domain before attempting to send mail to > them. Well, in another RFC, every domain should have an abuse@ and postmaster@ this domain. This seems in conflict. > > > Which would cover also any subdomain and will not have different > > interpretation while being deployed. > > If you're seriously proposing that SMTP clients start looking at SPF records, > that a MAJOR change that would be a major PITA to get deployed. > same as implementing this, it is a NS record lookup and special processing. From nobody Wed Feb 19 18:02:30 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5C81A02CE for ; Wed, 19 Feb 2014 18:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mn76umQYDN8 for ; Wed, 19 Feb 2014 18:02:26 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0E71A016A for ; Wed, 19 Feb 2014 18:02:26 -0800 (PST) Received: from [10.10.7.25] (64.1.210.5.ptr.us.xo.net [64.1.210.5]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s1K22JJS024163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Feb 2014 18:02:22 -0800 Message-ID: <530561F9.6070205@dcrocker.net> Date: Wed, 19 Feb 2014 18:01:29 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: draft-ietf-appsawg-nullmx.all@tools.ietf.org References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> In-Reply-To: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 19 Feb 2014 18:02:22 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/cE21Qmfo1sC67wxxZGxqYwmuUh8 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:02:28 -0000 Review of: A NULL MX Resource Record for Domains that Accept No Mail I-D: draft-ietf-appsawg-nullmx-00 Review by: D. Crocker Date: 19 Feb 2014 Summary: Internet mail transport address discovery relies on a default fallback use of the DNS A/AAAA record. This overloads the semantics of the record, causing attempts to send mail to hosts that do not support mail receipt. There is enough email traffic suffering this problem to warrant fixing. The NULL MX draft defines a means for a domain name to explicit declare that it is not valid to use it as an email address. The defined mechanism is simple and easy to implement. It seems likely to be quite useful. The specification document's writing is a bit rough and could benefit from some improvement. This is only an editorial issue for the document, with no changes needed in the technical content. Detailed Comments: > Abstract > > When the 5321.MailFrom domain in an e-mail message has a DNS MX > Resource Record (RR), it is making an explicit statement that it is > willing to accept email. The phrasing of this implies that the fact that it's a mailfrom address is somehow at the core of the problem or the mechanism here. It isn't. > However, when the domain has just a DNS A > or AAAA RR, there mail clients cannot easily tell whether the domain > accepts mail, as many hosts on the Internet advertise an A or AAAA RR > regardless of whether they want to accept email. I suggest a re-casting, along the lines of: Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record, which provides a fallback default. Unfortunately this means that the A/AAAA record is taken as a mail server address even when that address does not accept mail. An ability to explicitly announce that mail is not supported permits significant operational efficiencies. > The NULL MX RR formalizes the existing mechanism by which a domain > announces that it accepts no mail. > 1. Introduction > > This document formally defines the "NULL MX" as a simple mechanism by > which a domain can indicate that it will never accept email. > > SMTP clients have a prescribed sequence for resolving how to deliver > email to a domain. Section 5 of [RFC5321] covers this in detail, but > in essence the SMTP client first looks up a DNS MX RR and if that is > not found it falls back to looking up a DNS A or AAAA RR. Suggest adding: Hence this overloads an email service semantic onto a DNS record with a a different primary mission. > > Many domains do not accept email, but do have A or AAAA records. If > they have no MX records, senders will attempt to deliver mail to > those A or AAAA records. Swap the above 2 sentences: A domain has no MX records, senders will attempt to deliver mail to the hosts at the domain's A or AAAA record's addresses. However many domains do not accept email. > 2. SMTP server benefits > > Being able to detect domains that never accept email offers many > resource savings to an SMTP server. In the first instance, it can > choose to reject email during the SMTP conversation that does not > present a deliverable 5321.MailFrom domain. As phrased this seems to mean that having no mailfrom address will cause a delivery failure. Perhaps you mean something like: In the first instance, it can choose to reject incoming email, during the SMTP conversation, which contains a 5321.MailFrom domain that explicitly does not accept mail. > In the second instance, if an SMTP server accepts an email, it can be > confident that an attempt to send a non-delivery email will likely be > answered by another SMTP server. I don't understand this sentence. I also don't understand the term "non-delivery email". > This greatly helps to reduce non- > delivery queues. This contrasts greatly with the current situation > where a non-delivery email for, e.g., www.example.net, will sit in > the queue for a full queue lifetime as SMTP connection attempts to > www.example.net simply time out. > > 3. Parallel Considerations > > Clearly the perpetrators of abusive mail can adapt such that the > "vast class of email" that this mechanism helps identify, simply move > over to using 5321.MailFrom domains that have valid MX RRs. This sentence has an unstated premise that won't be obvious to some readers. Perhaps: Senders of abusive email often use addresses with domain names that do not accept mail. > 4. The NULL MX Resource Record > > To indicate that a domain never accepts email, it advertises a single > MX RR with a RDATA section consisting of preference number 0, and a > dot, i.e., the DNS root, as the mail exchanger domain, to denote that > there exists no mail exchanger for a domain. (The DNS root is not a > valid host name, which avoids any possibility that a NULL MX record > could be confused with an ordinary MX record.) > > The interpretation of a NULL MX RR only applies when the domain has a > single MX RR. If a domain advertises multiple MX RRs including a > NULL MX, the interpretation is as described in RFC5321. How will this record be interpreted, by a client that has not been modified to recognize the semantics defined her? > 5. Domains that do not send mail > > An SMTP server when presented with an "I never accept email" MX might > decline to accept such email as it knows that a response or non- > delivery notice will never be accepted, and that legitimate mail > rarely comes from domains that do not accept replies. This sentence is difficult to parse. Also, I suspect it is meant to be specific to an invalid mailfrom case, but it doesn't say that. > SMTP servers that reject mail because a MAIL FROM domain has a NULL > MX record should use a 550 reply code. should -> SHOULD > Although NULL MX often suggests that a domain sends no mail, it does > not say so explicitly. Operators may want to publish SPF [RFC4408] > -ALL policies to make an explicit statement. "often suggest"? Huh? Do you mean: A domain that does not accept mail, as declared by NULL MX, often will also not send mail. However this is only a likelihood. In order to make an explicit declaration that the domain is not valid in the rfc5321.mailfrom command, operators can publish SPF [RFC4408] -ALL policies. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Feb 19 22:13:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909CC1A040E for ; Wed, 19 Feb 2014 22:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icXddQ0bb8HV for ; Wed, 19 Feb 2014 22:13:13 -0800 (PST) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) by ietfa.amsl.com (Postfix) with ESMTP id 81CCC1A0263 for ; Wed, 19 Feb 2014 22:13:13 -0800 (PST) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 01:13:09 -0500 From: "MH Michael Hammer (5304)" To: "dcrocker@bbiw.net" , "draft-ietf-appsawg-nullmx.all@tools.ietf.org" Thread-Topic: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 Thread-Index: AQHPLd/P+nwP60xSzUWBnzIr4mKnt5q9qTLA Date: Thu, 20 Feb 2014 06:13:08 +0000 Message-ID: References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> In-Reply-To: <530561F9.6070205@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.231] 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 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/_lr5m5c6w_bw3LIQ0bFQMcJV0ME Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 06:13:28 -0000 > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of > Dave Crocker > Sent: Wednesday, February 19, 2014 9:01 PM > To: draft-ietf-appsawg-nullmx.all@tools.ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 >=20 > Review of: A NULL MX Resource Record for Domains that Accept No Mail > I-D: draft-ietf-appsawg-nullmx-00 > Review by: D. Crocker > Date: 19 Feb 2014 >=20 >=20 > Summary: >=20 > Internet mail transport address discovery relies on a default fallb= ack use > of the DNS A/AAAA record. This overloads the semantics of the record, > causing attempts to send mail to hosts that do not support mail receipt. > There is enough email traffic suffering this problem to warrant fixing. = The > NULL MX draft defines a means for a domain name to explicit declare that = it > is not valid to use it as an email address. >=20 > The defined mechanism is simple and easy to implement. It seems li= kely > to be quite useful. >=20 > The specification document's writing is a bit rough and could benef= it from > some improvement. This is only an editorial issue for the document, with= no > changes needed in the technical content. >=20 >=20 >=20 > Detailed Comments: >=20 > > Abstract > > > > When the 5321.MailFrom domain in an e-mail message has a DNS MX > > Resource Record (RR), it is making an explicit statement that it is > > willing to accept email. >=20 > The phrasing of this implies that the fact that it's a mailfrom address i= s > somehow at the core of the problem or the mechanism here. It isn't. >=20 >=20 > > However, when the domain has just a DNS A > > or AAAA RR, there mail clients cannot easily tell whether the domain > > accepts mail, as many hosts on the Internet advertise an A or AAAA R= R > > regardless of whether they want to accept email. >=20 > I suggest a re-casting, along the lines of: >=20 > Internet mail determines the address of a receiving server through > the DNS, first by looking for an MX record and then by looking for an > A/AAAA record, which provides a fallback default. Unfortunately this > means that the A/AAAA record is taken as a mail server address even when > that address does not accept mail. An ability to explicitly announce > that mail is not supported permits significant operational efficiencies. >=20 > > The NULL MX RR formalizes the existing mechanism by which a domain > > announces that it accepts no mail. >=20 >=20 >=20 > > 1. Introduction > > > > This document formally defines the "NULL MX" as a simple mechanism b= y > > which a domain can indicate that it will never accept email. > > I suppose that to be precise, the assertion is that it does not accept mail= for the TTL of the published NULL MX record. Never is a long time. > > SMTP clients have a prescribed sequence for resolving how to deliver > > email to a domain. Section 5 of [RFC5321] covers this in detail, bu= t > > in essence the SMTP client first looks up a DNS MX RR and if that is > > not found it falls back to looking up a DNS A or AAAA RR. >=20 > Suggest adding: >=20 > Hence this overloads an email service semantic onto a DNS record > with a a different primary mission. >=20 > > > > Many domains do not accept email, but do have A or AAAA records. If > > they have no MX records, senders will attempt to deliver mail to > > those A or AAAA records. >=20 > Swap the above 2 sentences: >=20 > A domain has no MX records, senders will attempt to deliver mail to > the hosts at the domain's A or AAAA record's addresses. However > many domains do not accept email. >=20 >=20 >=20 >=20 > > 2. SMTP server benefits > > > > Being able to detect domains that never accept email offers many > > resource savings to an SMTP server. In the first instance, it can > > choose to reject email during the SMTP conversation that does not > > present a deliverable 5321.MailFrom domain. >=20 > As phrased this seems to mean that having no mailfrom address will cause > a delivery failure. Perhaps you mean something like: >=20 > In the first instance, it can choose to reject incoming email, > during the SMTP conversation, which contains a 5321.MailFrom domain that > explicitly does not accept mail. >=20 >=20 > > In the second instance, if an SMTP server accepts an email, it can b= e > > confident that an attempt to send a non-delivery email will likely b= e > > answered by another SMTP server. >=20 > I don't understand this sentence. >=20 > I also don't understand the term "non-delivery email". >=20 >=20 > > This greatly helps to reduce non- > > delivery queues. This contrasts greatly with the current situation > > where a non-delivery email for, e.g., www.example.net, will sit in > > the queue for a full queue lifetime as SMTP connection attempts to > > www.example.net simply time out. > > > > 3. Parallel Considerations > > > > Clearly the perpetrators of abusive mail can adapt such that the > > "vast class of email" that this mechanism helps identify, simply mov= e > > over to using 5321.MailFrom domains that have valid MX RRs. >=20 > This sentence has an unstated premise that won't be obvious to some > readers. Perhaps: >=20 > Senders of abusive email often use addresses with domain names that > do not accept mail. >=20 >=20 >=20 > > 4. The NULL MX Resource Record > > > > To indicate that a domain never accepts email, it advertises a singl= e > > MX RR with a RDATA section consisting of preference number 0, and a > > dot, i.e., the DNS root, as the mail exchanger domain, to denote tha= t > > there exists no mail exchanger for a domain. (The DNS root is not a > > valid host name, which avoids any possibility that a NULL MX record > > could be confused with an ordinary MX record.) > > > > The interpretation of a NULL MX RR only applies when the domain has = a > > single MX RR. If a domain advertises multiple MX RRs including a > > NULL MX, the interpretation is as described in RFC5321. >=20 > How will this record be interpreted, by a client that has not been > modified to recognize the semantics defined her? >=20 >=20 > > 5. Domains that do not send mail > > > > An SMTP server when presented with an "I never accept email" MX migh= t > > decline to accept such email as it knows that a response or non- > > delivery notice will never be accepted, and that legitimate mail > > rarely comes from domains that do not accept replies. >=20 > This sentence is difficult to parse. Also, I suspect it is meant to be > specific to an invalid mailfrom case, but it doesn't say that. >=20 >=20 > > SMTP servers that reject mail because a MAIL FROM domain has a NULL > > MX record should use a 550 reply code. >=20 > should -> SHOULD >=20 >=20 > > Although NULL MX often suggests that a domain sends no mail, it does > > not say so explicitly. Operators may want to publish SPF [RFC4408] > > -ALL policies to make an explicit statement. >=20 > "often suggest"? Huh? Do you mean: >=20 > A domain that does not accept mail, as declared by NULL MX, often > will also not send mail. However this is only a likelihood. In order > to make an explicit declaration that the domain is not valid in the > rfc5321.mailfrom command, operators can publish SPF [RFC4408] -ALL > policies. >=20 >=20 >=20 >=20 >=20 > d/ >=20 >=20 > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Feb 20 01:05:48 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC7D1A003D for ; Thu, 20 Feb 2014 01:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpaYuaF0Q0U8 for ; Thu, 20 Feb 2014 01:05:44 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5EF1A004E for ; Thu, 20 Feb 2014 01:05:43 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4FAD2FA0065; Thu, 20 Feb 2014 09:05:39 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1392887137-1404-1403/12/14; Thu, 20 Feb 2014 09:05:37 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 20 Feb 2014 10:05:07 +0100 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <83b24d25-b3c2-4f31-8b39-af11d29249bd@gulbrandsen.priv.no> In-Reply-To: <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> <01P4JKS49U0U00004W@mauve.mrochek.com> <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/jdAtWN9vPfI5UjtdF-BALUh58Lw Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 09:05:47 -0000 On Thursday, February 20, 2014 12:51:32 AM CEST, Franck Martin wrote: > Well, in another RFC, every domain should have an abuse@ and > postmaster@ this domain. This seems in conflict. I can't remember what RFC that was, but I do seem to remember the requirement itself, and that it pertained to domains that have mail service. It did not require e.g. abuse@co.uk to exist, or abuse@l.google.com (the domain in which google's load balancers live). This applies, in pratice, to all protect-our-trademarks domains and to various intermediate things. Arnt From nobody Thu Feb 20 03:12:38 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2333A1A00CD for ; Thu, 20 Feb 2014 03:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLxAKcBuQb_m for ; Thu, 20 Feb 2014 03:12:34 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id D702F1A00D1 for ; Thu, 20 Feb 2014 03:12:33 -0800 (PST) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.883.10; Thu, 20 Feb 2014 11:12:29 +0000 Message-ID: <008701cf2e2b$f4bafbc0$4001a8c0@gateway.2wire.net> From: t.petch To: Arnt Gulbrandsen , References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> <01P4JKS49U0U00004W@mauve.mrochek.com> <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> <83b24d25-b3c2-4f31-8b39-af11d29249bd@gulbrandsen.priv.no> Date: Thu, 20 Feb 2014 11:06:56 +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.248.133] X-ClientProxiedBy: DB4PR07CA001.eurprd07.prod.outlook.com (10.242.229.11) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Forefront-PRVS: 01283822F8 X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(13464003)(24454002)(37745?= =?iso-8859-1?Q?4003)(51704005)(199002)(189002)(63696002)(47776003)(660660?= =?iso-8859-1?Q?01)(74502001)(80022001)(47446002)(74662001)(31966008)(8726?= =?iso-8859-1?Q?6001)(87286001)(61296002)(65816001)(62966002)(44716002)(62?= =?iso-8859-1?Q?236002)(79102001)(19580405001)(83322001)(19580395003)(8797?= =?iso-8859-1?Q?6001)(80976001)(94946001)(95416001)(85852003)(51856001)(83?= =?iso-8859-1?Q?072002)(46102001)(95666001)(94316002)(77156001)(77096001)(?= =?iso-8859-1?Q?85306002)(53806001)(76482001)(89996001)(42186004)(90146001?= =?iso-8859-1?Q?)(56816005)(54316002)(76786001)(93136001)(47736001)(692260?= =?iso-8859-1?Q?01)(49866001)(47976001)(50986001)(50226001)(92726001)(4473?= =?iso-8859-1?Q?6004)(93516002)(81342001)(81542001)(14496001)(93916002)(23?= =?iso-8859-1?Q?756003)(76796001)(33646001)(92566001)(4396001)(74876001)(8?= =?iso-8859-1?Q?6362001)(84392001)(74366001)(74706001)(88136002)(56776001)?= =?iso-8859-1?Q?(77982001)(59766001)(50466002)(74416001)(7726001)(2101003)?= =?iso-8859-1?Q?;DIR:OUT;SFP:1101;SCL:1;SRVR:AMSPR07MB050;H:AMXPRD0310HT00?= =?iso-8859-1?Q?2.eurprd03.prod.outlook.com;CLIP:157.56.248.133;FPR:6FD7F2?= =?iso-8859-1?Q?5C.A41E5CCA.A7D19F86.CCD78631.201B8;PTR:InfoNoRecords;A:0;?= =?iso-8859-1?Q?MX:1;LANG:en;?= X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kxsAAmZS1Ja1pj32junympzKiLs Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 11:12:37 -0000 ---- Original Message ----- From: "Arnt Gulbrandsen" To: Sent: Thursday, February 20, 2014 9:05 AM Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt > On Thursday, February 20, 2014 12:51:32 AM CEST, Franck Martin wrote: > > Well, in another RFC, every domain should have an abuse@ and > > postmaster@ this domain. This seems in conflict. > > I can't remember what RFC that was, but I do seem to remember the > requirement itself, and that it pertained to domains that have mail > service. It did not require e.g. abuse@co.uk to exist, or > abuse@l.google.com (the domain in which google's load balancers live). RFC1123 for postmaster RFC2142 for abuse Tom Petch > > This applies, in pratice, to all protect-our-trademarks domains and to > various intermediate things. > > Arnt From nobody Thu Feb 20 03:37:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B36E1A00AB for ; Thu, 20 Feb 2014 03:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCVbFNdZcjq2 for ; Thu, 20 Feb 2014 03:37:04 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02A1A00B3 for ; Thu, 20 Feb 2014 03:37:04 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 67E46FA009D; Thu, 20 Feb 2014 11:36:59 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1392896218-1404-1403/12/16; Thu, 20 Feb 2014 11:36:58 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Thu, 20 Feb 2014 12:36:28 +0100 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <4f2e6fc5-2139-406c-82e4-c8c6a32a46aa@gulbrandsen.priv.no> In-Reply-To: <008701cf2e2b$f4bafbc0$4001a8c0@gateway.2wire.net> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> <01P4JKS49U0U00004W@mauve.mrochek.com> <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> <83b24d25-b3c2-4f31-8b39-af11d29249bd@gulbrandsen.priv.no> <008701cf2e2b$f4bafbc0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/AOIkKahSdFbFzY4AmSG0Ci-5iBs Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 11:37:06 -0000 Tom Petch refreshes my memory: > RFC1123 for postmaster A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster". > RFC2142 for abuse organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name for which the associated function exists Ie. there is no conflict with the nullmx draft. (And, honestly, it would be strange to discover a conflict after ten years of deployment.) Arnt From nobody Thu Feb 20 05:40:26 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1719B1A0162 for ; Thu, 20 Feb 2014 05:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHYqsU_xiauJ for ; Thu, 20 Feb 2014 05:40:23 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C61A0160 for ; Thu, 20 Feb 2014 05:40:22 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l18so1493651wgh.9 for ; Thu, 20 Feb 2014 05:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=B6XwR80EsJ68Tfdt0PzP4lr/4GtMcxFpMDYzNDRne94=; b=K5nZAzrTnvF3mXIXGlmkvz6m/hmjFZ76cVKAATgl/+uNkq1WilmVZ+IcrxtETnS4o/ C4cmMXzlhjM0b59u0su0NYymAROYAK32YBn0MrX6Te8g1vWciPV3FdTeLEo2KgADtisW Vs0gjDOfSSvSNN4tH3mHPSM5JENbDkSLEcwE4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B6XwR80EsJ68Tfdt0PzP4lr/4GtMcxFpMDYzNDRne94=; b=bOjksZpejTZEmeR06/m92AuG8cpAZednZInK6AR12e4nHVZLAdKWXdl5BmuqO3niDd trfySb0IWqfW5dsfQwzYVB9u7OkIvdjBG6p1QT5lSB6FQ2J633OIphMTW5dE52xUqbaD aRONRkc9vjc3yrC33Oqhc0qsQt4DpIkWTR1MwppSxmPfnbj0G1tP1wvl3oXheZ+UgjOw aoMCoK+5dcZeaMWjol3RbfCN8/YWQJ9P7AGWTqicMNBuuO76BxM7UidRyFYykoJH1vTy H5Hn9T9+75z8nzkJptt3kmO0viWNueprXQhadZ7AovzDGfTNiO/XhZTIAPV8V6iGAu+H pMYQ== X-Gm-Message-State: ALoCoQmbCkPYI+hc9UJ/4qjNlZr+7bLBYKqwpCcNbXqw0/8UzBVlsYtz3W3TgsZueUaezdLgyN4f MIME-Version: 1.0 X-Received: by 10.194.110.135 with SMTP id ia7mr2091345wjb.5.1392903618414; Thu, 20 Feb 2014 05:40:18 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.195.12.137 with HTTP; Thu, 20 Feb 2014 05:40:18 -0800 (PST) In-Reply-To: <530561F9.6070205@dcrocker.net> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> Date: Thu, 20 Feb 2014 05:40:18 -0800 X-Google-Sender-Auth: bWruObaCWku6nMBxy388Iq7I5Q8 Message-ID: From: Kurt Andersen To: Dave Crocker Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/c6DV48kajpdKhbljMmD7obD4lCI Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 13:40:25 -0000 On Wed, Feb 19, 2014 at 6:01 PM, Dave Crocker wrote: >> Although NULL MX often suggests that a domain sends no mail, it does >> not say so explicitly. Operators may want to publish SPF [RFC4408] >> -ALL policies to make an explicit statement. > > > "often suggest"? Huh? Do you mean: > > A domain that does not accept mail, as declared by NULL MX, often will > also not send mail. However this is only a likelihood. In order to make an > explicit declaration that the domain is not valid in the rfc5321.mailfrom > command, operators can publish SPF [RFC4408] -ALL policies. I'd be even more explicit to ensure conformity of intent throughout this document and the implications for receivers that are listed throughout: "A domain that does not accept mail, as declared by NULL MX, SHOULD not send mail and SHOULD never be seen in 5321.Mailfrom and 5322.From fields. Operators can also publish SPF (RFC4408(bis?)) -ALL policies." --Kurt Andersen From nobody Thu Feb 20 05:59:40 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FB81A017F for ; Thu, 20 Feb 2014 05:59:39 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9HnzDvYUnqp for ; Thu, 20 Feb 2014 05:59:37 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 869921A0172 for ; Thu, 20 Feb 2014 05:59:37 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B74D440402 for ; Thu, 20 Feb 2014 08:59:33 -0500 (EST) Message-ID: <53060A45.3070401@viagenie.ca> Date: Thu, 20 Feb 2014 08:59:33 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> <01P4JKS49U0U00004W@mauve.mrochek.com> <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> In-Reply-To: <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/1UNuQafNXExuiE_lLNu7Jzmt7OE Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 13:59:39 -0000 Le 2014-02-19 18:51, Franck Martin a écrit : >>> This draft requires current filtering solutions to change behavior. The >>> presence of an MX will indicate the domain is emailable (cf spamassassin >>> rules) >>> until the software is changed to recognize the 0. We will have different >>> behavior while this is getting implemented. >> >> The domain validity check is extremely weak to begin with. And given the >> speed >> at which such rules have to evolve for other reasons, even if you think this >> deserves consideration - which I don't - it's a miniscule factor in the >> overall scheme of AS/AV solutions. > > It is in spamassassin and others, not sure the word miniscule "apply" here. Spamassassin updates its rules nightly. Other products do similar things. So not a problem IMHO. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Feb 20 06:02:27 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1461A017F for ; Thu, 20 Feb 2014 06:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN_iu_RgK-YE for ; Thu, 20 Feb 2014 06:02:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BBE631A0180 for ; Thu, 20 Feb 2014 06:02:16 -0800 (PST) Received: from [10.10.7.25] (64.1.210.19.ptr.us.xo.net [64.1.210.19]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s1KE28SX003795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Feb 2014 06:02:12 -0800 Message-ID: <53060AAD.6010601@dcrocker.net> Date: Thu, 20 Feb 2014 06:01:17 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kurt Andersen References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 20 Feb 2014 06:02:12 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Zw8jyprIIDjY--6k5nVF91hxhW0 Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:02:24 -0000 On 2/20/2014 5:40 AM, Kurt Andersen wrote: > "A domain that does not accept mail, as declared by NULL MX, SHOULD > not send mail and SHOULD never be seen in 5321.Mailfrom and 5322.From > fields. Operators can also publish SPF (RFC4408(bis?)) -ALL policies." +1 However a minor quibble caused by 'be seen' -- since they can't control spoofing -- prompts me to suggest more finicky language that I think is both more general and more specific: "When a domain is listed as not accepting mail, as declared by a NULL MX record, it also SHOULD NOT be authorized for use in any email address or or domain field. That is, if it is not used for receiving mail it is best not to use it with any other email function. Operators can also publish SPF (RFC4408(bis?)) -ALL policies." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Feb 20 11:21:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D697B1A024F for ; Thu, 20 Feb 2014 11:21:04 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz6OBvlFTXF6 for ; Thu, 20 Feb 2014 11:21:01 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 125361A024D for ; Thu, 20 Feb 2014 11:21:01 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so2313174pad.13 for ; Thu, 20 Feb 2014 11:20:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=DZ+NQGBw6wWGDW2eBHCmKJ5fFyUFlOIRd+sFs3xBKPY=; b=RXEYS0jGgk972ujoPnuHGKglwXMbwYzo8thowcFD4qmzmcgS53exrInClEODwYoFGn apV7AEIYDHrhmVdjBNqbBFJcDFESI91iqVqfvq/pgtGqjaewg/hZ53Fu6UmFKL3nWDNB rs6LIjfecWrpIRpttFgsun0k1dwpQ7mF/P/sN5dj3fkCehTML84Ti4v7zOI9qwfATjey WJDk5vvzIFHOJ7O5Omgj1j3nbSqxu0/vMvkqudDN/0/UfZtoHDxIqDtpfCTpSUgyCfoN TFm8271wzYn17jOrYUPH6L+MzGPI5jGGKnSF7HK9HNI+MHxDdr9Tqzz5LS66i6wGsyro QARg== X-Gm-Message-State: ALoCoQlWTK4s7Peznht7bAOh3aFVtFkwShD8E+FT1hDMv1nQ6z3OULofExueWl+nQa0z12ZQsAXn MIME-Version: 1.0 X-Received: by 10.67.1.202 with SMTP id bi10mr4185261pad.68.1392924057407; Thu, 20 Feb 2014 11:20:57 -0800 (PST) Received: by 10.68.143.4 with HTTP; Thu, 20 Feb 2014 11:20:57 -0800 (PST) X-Originating-IP: [192.149.252.135] Date: Thu, 20 Feb 2014 14:20:57 -0500 Message-ID: From: Andrew Newton To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9UuRkKi4pATLh2_rcNDVYSzy4hk Subject: [apps-discuss] comments on draft-ietf-appsawg-uri-get-off-my-lawn-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 19:21:05 -0000 Having just read the URI Design and Ownership draft, I have the following comments: 1) This document provides guidelines on URIs in general, yet some of the reasoning and advice seems very specific to HTTP URIs. And some of it seems counter to other URI types. Specifically regarding URNs, this draft runs counter to how URN namespaces are created. Section 2.3 states that specifications MUST NOT constrain or define structure in any path segment, yet according to RFC 3986 every part of a URN following the scheme name is the path of a URN. Given that every URN namespace specifically identifies its namespace identifier and that identifier IS part of the URI path of the URN, this advice is incompatible. 2) As I read this draft, it appears to be aimed at specifications re-using HTTP (though it is generalized) and therefore providing guidance on specifications re-using HTTP. Given that BCP 56 is broadly interpreted as 'use a different port for HTTP', this seems to be encouraging behavior that is shunned by BCP 56. Therefore, shouldn't this draft update BCP 56? 3) This draft updates RFC 3986, yet 3986 is a standards track document whereas this is a BCP document. Is that allowed? This is especially relevant given the update to 3986 changes URNs (see #1). 4) Section 1.1 exempts IANA. Why? And if the IANA registry is to be exempted, wouldn't this mean other types of registries could be exempted? This goes directly to the challenge against the WEIRDS output. WEIRDS is targeting IP address and domain name registries. 5) Appendix B states that URI templates are one solution to avoiding the problems given in this draft. Yet URI templates seem to run counter to the WEBARCH reference used by this draft, specifically Section 3.5.1 which was called out by this draft. URI templates are a method for allowing applications to conform to changing URI paths/queries, yet the advice of Section 3.5.1 is specifically about the importance of URI persistence. 6) In addition to the above, WEBARCH Section 3.5.0 states "Dereferencing a URI has a (potentially significant) cost in computing and bandwidth resources, may have security implications, and may impose significant latency on the dereferencing application. Dereferencing URIs should be avoided except when necessary." URI Templates as a solution cause an additional dereference and therefore are counter to this advice. While such dereferencing is an engineering tradeoff, this draft strikes a rigid tone in its advice (and the application so far on this mailing list amplifies this). If this draft is to reference an architecture document for the reasons to which its advice should be adhered, it should not also offer solutions which violate the architecture document. Or, alternatively, this draft and its application should be less rigid. 7) Paragraph 2 of Section 1 justifies this draft with the defense of practices which are not generally held as being good. Use of file type suffixes for content negotiation is specifically called out in the WEBARCH reference as something to be avoided. Additionally, there seems to be a disconnect between excusing packaged software vendors for the rigidity of their software yet holding specifications accountable. 8) This draft also makes the suggestion that some servers cannot adequately comply with the protocols upon which they operate, and therefore specifications should comply with the practices of this draft to route around these shortcomings. I do not think it is right for the IETF to encumber its specifications to alleviate the pain of shoddy server implementations. And if enough server implementations have issues with compliance, that really should be a driver to fixing the base protocol vs adjusting the things built upon it. In other words, if a significant number of HTTP servers cannot comply with portions of the HTTP protocol, we should fix HTTP which is the root cause of the problem. Overall I think much of the advice in this draft is very useful. I do think most of the MUST/MUST NOTs are too rigid. In fact, the 2119 language should probably be dropped in most of the places in favor of providing guidelines, not specific requirements, to future specification authors. Too much rigidity will cause thrashing during the IETF processes and will likely not accommodate future scenarios now unseen. -andy From nobody Thu Feb 20 11:32:21 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F951A01F2 for ; Thu, 20 Feb 2014 11:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8yrIw-wJsN6 for ; Thu, 20 Feb 2014 11:32:17 -0800 (PST) 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 6DBD11A015F for ; Thu, 20 Feb 2014 11:32:17 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id u57so1843541wes.11 for ; Thu, 20 Feb 2014 11:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OBs8/H85V+95MZ7swlrfHk3BCbqNTjDw94niFD1dHf0=; b=qaGHwaBpKus2/7rEccHsGhM/GabPJ9l3rbO5YsUEUz7HSWv2gy1NtMZwnZdAMuRLIW GV1tzfefqphDFlXWECEiK97cH3S9jdf1GgYGUvmPUx4rowdhlCeqWNLyVC3MMNpNmbkj OBMVmAucsnSWtgj5LbdJ/oCO5etpguvr47JCX/kpUGsdoq9+kVjmkdIweDZENnkdH9TQ ZLgTKoYYUxvUK6QNnpmuNa2I5LwcZw/7rRp1A6/IGqda/Srq+J4PEutfWipid73Ow9uF 7Ao9FscSRMqjxC4OCUYYnuuO7ZVD64wtXCV2RW9eQcqDDMnMhmguKy9kyJXTlc/yzR1o XULg== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr8604544wib.58.1392924733306; Thu, 20 Feb 2014 11:32:13 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 20 Feb 2014 11:32:13 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 11:32:13 -0800 Message-ID: From: Martin Thomson To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/kGcKQfWDxIzZDwQ0pGCYLhvKySQ Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-uri-get-off-my-lawn-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 19:32:19 -0000 I think that the idea that this is too HTTP specific may be a fair call, this being the big ticket item I think: On 20 February 2014 11:20, Andrew Newton wrote: > 1) This document provides guidelines on URIs in general, yet some of > the reasoning and advice seems very specific to HTTP URIs. And some of > it seems counter to other URI types. Specifically regarding URNs, this > draft runs counter to how URN namespaces are created. Section 2.3 > states that specifications MUST NOT constrain or define structure in > any path segment, yet according to RFC 3986 every part of a URN > following the scheme name is the path of a URN. Given that every URN > namespace specifically identifies its namespace identifier and that > identifier IS part of the URI path of the URN, this advice is > incompatible. I don't think that this is the problem you think it is. The advice is that standard X should not override the sovereignty of the owner of a particular part of URI space. In the case of URNs, the ownership arrangement might be such that owners naturally cede some degree of ownership. From nobody Thu Feb 20 12:12:53 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4861A02B8 for ; Thu, 20 Feb 2014 12:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwIR2luhmZg0 for ; Thu, 20 Feb 2014 12:12:51 -0800 (PST) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id D588F1A02C4 for ; Thu, 20 Feb 2014 12:12:50 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so2271849pdj.3 for ; Thu, 20 Feb 2014 12:12:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zwG0XhyDOuWtNWYPKOVYTgkj8aMaqoCAnR9FeWSyxC8=; b=CziGR3/jo+qc/PcuPNqD5RTGZ6EwKDmsJcr3j6aXH0+rLPr5Bq3vr858l7E6m5dao9 vLrB64tJjz0IYsc8apijFMJkkGAHQmNaKaUqLkosVTEbJyNHnf6kQisF0RyVK+ry8bCv HOZOmu53teDjxP19V3vj/JL1Kv67csa3JiO/dsKtIUWSe54XoCsuYXFk+3lWqxNMMGYz Wj16SJNSOuS/HZQQlo8ALiTt9O9komFzWKSCLgdqp7ef9LPkMA36WoFlINGtVlKjLqfr u/fiC091/DFoAdf/B4DVdc7I/726wjcmzpCXwEANq8w/A5x+o7IxQHJzRP5NZS/Ywhwv nWyw== X-Gm-Message-State: ALoCoQkedTvxzOPgr8AzQLOBR01Lc0fLH1cUWDBg9R5xvTTrdMU4SUvL1KcMJ8q0t+zJfqTOOsTa MIME-Version: 1.0 X-Received: by 10.66.163.2 with SMTP id ye2mr4268329pab.110.1392927167331; Thu, 20 Feb 2014 12:12:47 -0800 (PST) Received: by 10.68.143.4 with HTTP; Thu, 20 Feb 2014 12:12:47 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: References: Date: Thu, 20 Feb 2014 15:12:47 -0500 Message-ID: From: Andrew Newton To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aMeMaaQUqqFhzMTp4Ratu9ptUPQ Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-uri-get-off-my-lawn-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 20:12:52 -0000 On Thu, Feb 20, 2014 at 2:32 PM, Martin Thomson wrote: > I don't think that this is the problem you think it is. The advice is > that standard X should not override the sovereignty of the owner of a > particular part of URI space. In the case of URNs, the ownership > arrangement might be such that owners naturally cede some degree of > ownership. That maybe, but not as currently written. And if so, why are URNs the exception? Can we not allow for other exceptions? Again, this draft about URI rigidity is too rigid. :) And can't such an arrangement be said for every protocol? If you wish to use it, you cede some degree of ownership regarding how the bits flow across the wire. This draft offers some very good advice to spec authors especially with regards to being forward looking and being compatible within shared environments. That being said, it is not applicable to every situation and spec authors should have some wiggle room. -andy From nobody Thu Feb 20 13:55:24 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3959D1A02F0 for ; Thu, 20 Feb 2014 13:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTaSw3nN6lh2 for ; Thu, 20 Feb 2014 13:55:20 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id A6B681A0136 for ; Thu, 20 Feb 2014 13:55:19 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id q58so1894287wes.7 for ; Thu, 20 Feb 2014 13:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SqKLFUk1YjQlky0JjVEknT0coN5hCGHnPlFmzFcLytQ=; b=dS4rGkAOQjtgDcnA9gbVjVON+kG9PBkLfLU5gFCElydtiy0qZaV0CR/tIq5bDj7+AV 1EkxsNuryVGaTxn3D4dUu4KhrjW1cjvdDZzF2oE1OosGovO4gxVrvwEbT8tt04ObPCqA YNvNUW50AEI/ZSYKgm759uZAL9chhWTYxKYIGAGsrcGzwQkCWAnU3HETxZODwkbUtFRS HQDq7TUv5VI3fNf9XmefyDQ2xWcd7Ax0titsUVdRoy6lyq1QdDYqejTNlY284i/JGyGX GEvdahVnIqdNJ7tcLEQFfREX9MGHifNhDiiL5bVXixu3dfcFq5epj2RYHFlEkkubFQAo eusQ== MIME-Version: 1.0 X-Received: by 10.180.185.197 with SMTP id fe5mr417956wic.56.1392933315530; Thu, 20 Feb 2014 13:55:15 -0800 (PST) Received: by 10.227.10.196 with HTTP; Thu, 20 Feb 2014 13:55:15 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Feb 2014 13:55:15 -0800 Message-ID: From: Martin Thomson To: Andrew Newton Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/NdlgGSKVjfAslONjUxQi-O4IxIw Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-uri-get-off-my-lawn-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 21:55:22 -0000 On 20 February 2014 12:12, Andrew Newton wrote: > That maybe, but not as currently written. And if so, why are URNs the > exception? Can we not allow for other exceptions? Again, this draft > about URI rigidity is too rigid. :) I didn't mean to imply that URNs are special. Just that sometimes "ownership" isn't always as simple as what (I think) you implied above. From nobody Thu Feb 20 15:11:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D297E1A0336 for ; Thu, 20 Feb 2014 15:11:31 -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=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na8x3vl09K-w for ; Thu, 20 Feb 2014 15:11:25 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id D01BA1A033D for ; Thu, 20 Feb 2014 15:11:22 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id um1so2567702pbc.19 for ; Thu, 20 Feb 2014 15:11:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dZO0N+bw1+HRpYTyyThZ0ileXqPquxMsCCz6OZntGFo=; b=IFAt1v2S+CL1LzDoaWTyM2C8hE0gk5+PA+42NYcwLDg6g+tFI969R4fn9xAqPa1hFB HLa7sc7gIFwbfwsGD6E+dMwbp4oOJywVZCwfTfkab4qOT8dbGRn7Qw/NfMFMXQJ6uVfy zkouggRmKcP7HZ6y6S/juc81Ki/p0pRo7UrakYuFZVVL6s91p2ZWjMNZUlmpRoDXQB8C r5D7YuplkRs8Ztndag+wkUuxDpk3fJBOltK38y4zoT3qJCeaIqihSfEYh87Y8+3jFPZf RINctw+ei2d7M3wSbtq0kvjaP61jQXDt0ZC38yaMFh8Egie0LJQSj+OmGuETvujLwoQl nOew== X-Gm-Message-State: ALoCoQlJo0vAlWgw/b4+1s0GT+64ytgXdn8Xx7yikQQew0++JLl0k9kVFZDAN4RUrA7A7jy4fWwd MIME-Version: 1.0 X-Received: by 10.68.134.130 with SMTP id pk2mr4930804pbb.167.1392937879320; Thu, 20 Feb 2014 15:11:19 -0800 (PST) Received: by 10.68.143.4 with HTTP; Thu, 20 Feb 2014 15:11:19 -0800 (PST) X-Originating-IP: [108.45.162.177] In-Reply-To: References: Date: Thu, 20 Feb 2014 18:11:19 -0500 Message-ID: From: Andrew Newton To: Martin Thomson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/L1yy79RUJSk6Bj3vuFA-vMBO5YM Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-uri-get-off-my-lawn-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 23:11:32 -0000 On Thu, Feb 20, 2014 at 2:32 PM, Martin Thomson wrote: > I think that the idea that this is too HTTP specific may be a fair > call Which got me to thinking about RFC 4516. Does section 2.3 of this draft mean that new attribute types in LDAP may not show up in LDAP URLs? And more interestingly, does Section 2.4 completely void the extension mechanism in Section 2 of 4516? -andy From nobody Thu Feb 20 19:52:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6031A03E1 for ; Thu, 20 Feb 2014 19:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDSBYi7yuW_Y for ; Thu, 20 Feb 2014 19:52:46 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id DE5311A031B for ; Thu, 20 Feb 2014 19:52:45 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.0.883.10; Fri, 21 Feb 2014 03:52:40 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0878.008; Fri, 21 Feb 2014 03:52:40 +0000 From: Dave Thaler To: Graham Klyne Thread-Topic: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt Thread-Index: AQHPKcEaJNqgQQL1fEW4nlD27YvlO5q1S01ggAAFZJCABA9ugIAFtf2w Date: Fri, 21 Feb 2014 03:52:39 +0000 Message-ID: <365eaba6923149569140854c4bdd0815@BY2PR03MB412.namprd03.prod.outlook.com> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> <5301FD29.5000401@ninebynine.org> In-Reply-To: <5301FD29.5000401@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::3] x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(13464003)(57704003)(164054003)(51444003)(24454002)(189002)(199002)(377424004)(377454003)(479174003)(76576001)(76796001)(76786001)(19580395003)(19580405001)(83322001)(69226001)(94946001)(86612001)(85306002)(15202345003)(83072002)(56816005)(93516002)(85852003)(90146001)(93136001)(65816001)(95416001)(33646001)(561944002)(4396001)(74502001)(47446002)(74662001)(94316002)(31966008)(80022001)(81816001)(86362001)(15975445006)(92566001)(79102001)(47736001)(74876001)(46102001)(50986001)(47976001)(76482001)(59766001)(77982001)(54356001)(81686001)(54316002)(74706001)(56776001)(95666003)(49866001)(81342001)(53806001)(51856001)(2656002)(63696002)(80976001)(87266001)(74366001)(87936001)(81542001)(74316001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::3; FPR:E22CFDA5.9BFAA031.B4D331AB.C6E8E932.209A4; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wDBjZ34YNfKQp5296HwHThEfwhY Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 03:52:51 -0000 Graham Klyne writes:=20 > I'm responding with a perspective of being the current designated IANA > reviewer. > Broadly, I'm supportive of the changes proposed, and in particular to l= ower > the perceived barrier to provisional registration of schemes. Great, thanks for the careful review. =20 > Section 3.3 ("well defined"). One of the first questions I ask myself wh= en > reviewing a URI scheme proposal is: "What kinds of thing do URIs in this > scheme identify, or how do I find out?". I'd like to see all scheme > registrations providing a clear answer for this. Providing a clear answer to this and other questions is an example of=20 the burden that disincents people from registering. The act of writing responses, and ensuring that they are correct and readable (and in some cases, approved by management or legal or whoever else) is perceived as onerous compared to the marginal benefit the applicant gets. > One of the problems I have sometimes experienced in reviewing URI > scheme registration submissions is understanding what the corresponding > scheme is intended to identify. If it is a locator, then it's usually fa= irly clear. > But some schemes I've seen - particularly where used as particular identi= fiers > within other protocols - have been less clear (in their original submissi= ons). > Recent(ish) examples that come to mind are acct:, turn: and stun: (not > criticizing them, just trying to give examples of things that are not alw= ays > immediately clear). I agree. The larger question we should really be discussing is: why do we need to know? Would we rather have unregistered schemes that we don't know the answer for, or registered schemes that we don't know the answer fo= r. Currently none of the 4 stated goals of the registry really require such understanding. An understanding of the _syntax_ is useful for another unstated goal: improve compliance with guidelines/recommendations and thus interop with generic URI parsers, etc. But an understanding of=20 _semantics_ doesn't seem to be required for that either. So what goal do you think it's accomplishing? (Not to imply I don't think it's not valuabl= e.) In my opinion, we need to separate guidance to defining document writers from guidance and requirements to the person wanting to _register_ a scheme (keeping in mind that they could be unrelated, as in the third-party case). The bar for the latter should be low. Advice for the former should be lib= erally given, but not interfere with keeping the bar to _register_ low. =20 For example, you may recall that during the third-party registration experi= ment that Alexey and I did, all the Microsoft schemes came from Alexey instead o= f me, since the bar for third-party registration was lower... coming from me= =20 might imply I actually vouched that the information was correct, which was too onerous to do during the experiment. =20 > I think the text "Schemes that are not intended to be used as locators > SHOULD describe how the resource identified can be determined or > accessed by software that obtains a URI of that scheme." goes some way to > this, but that was present in the previous draft and didn't always get no= ticed. > Also, there is not always a mechanism that is available to software (e.g. > urn":). I'm wondering if this can be beefed up a bit... e.g. to lead wit= h > something like: >=20 > "URI scheme specifications should be clear about the kind of resource tha= t > they may identify, or the means (technical or non-technical) by which URI= s > are related to the resources they identify" >=20 > My text could surely be improved. The first part of this would apply to = a > scheme like "acct:" saying that an acct: URI identifies a user account in= some > domain or system (**); the latter would apply to locator schemes like htt= p:, > or identifier schemes like urn: where there is a defined administrative > delegation structure. >=20 > >=20 > In making this comment, I also note there is some slight overlap with mat= erial > covered in section 3.4. >=20 > ... >=20 > Section 3.8: >=20 > Re: "[[CREF2: Open Issue: Should we define a mechanism to register a > scheme prefix ("web+", "ms-", etc.)? --DT]]" >=20 > I think not. >=20 > I've not come across any great need for this, and I think it might even > encourage scheme proliferation in conflict with the exhortations in secti= on > 3.1 ("In general, the use and deployment of new schemes in the Internet > infrastructure may be costly; ...", etc.) I have certainly heard multiple requests for this because of the burden of registering one scheme. When someone wants a set of related ones, and possibly the ability to add more over time, I get asked if they can jus= t use a common prefix. Of course using a common prefix is good for understanding that they're related. But they're asking because of the burden of registering each one. So for example "ms-settings-*"=20 > Section 4 >=20 > re: [[CREF4: Open issue: previously this also RECOMMENDED following the > same guidelines as for permanent registration. However, this higher > bar disincented people to register schemes at all, and hence > interfered with the goals of the registry. Hence tentatively > removed, but need to confirm consensus on this. --DT]] >=20 > I've not seen any cases where this has been a problem, but maybe that's > because I mainly see a self-selecting population ;) (I.e. those who have > actually submitted a registration request.) Yes, that's why. But I guess my view goes back to my point above about guidance to doc authors vs guidance to applicants. =20 > Some time ago, we started creating a FAQ/guidance page at IANA for a > similar registry (message header fields), with the goal of demystifying t= he > process and encouraging early registration. Unfortunately, that effort f= izzled > (though I think an initial draft is still around on an IETF/IANA wiki pag= e.) >=20 > Maybe this kind of approach would be an alternative? I.e. create a FAQ, = and > direct readers to that page for provisional registration. The FAQ-as-gui= dance > can then be updated more easily than the BCP document (within its defined > constraints). >=20 > ... >=20 > Section 7.1 >=20 > [[CREF8: Open Issue: Should Provisional status just use First Come > First Serve? Someone suggested FCFS with Expert Review afterwards, > but the benefit and efficacy of a subsequent Expert Review seems > dubious to me and might only serve to deter registrations in the > first place, which is the problem we're trying to solve. --DT]] >=20 > Given the limited nature of URI scheme name space, I think that IESG/IANA > should always have final say about name allocation. Given that we try to > keep the bar low, I feel formal FCFS makes it too easy to use provisional > registration as a land grab - writing that into the spec would make it ha= rder > for an expert reviewer to push for alternatives where appropriate. (I th= ink > there is one occasion in the past few years where the choice of name has > been cause for push-back, so it's not a great problem.) The notion that the expert reviewer might push for alternatives is part of the disincentive to register in the first place. So I think that not havin= g FCFS for Provisional just results in the current mass unregistered use, which do= esn't help anyone. It's a no-win situation :) > As reviewer, I have tried to treat the role as providing guidance rather = than > as gatekeeper (I don't think I've ever recommended rejection of a > provisional registration request, though I do often make comments), so I'= m a > little troubled by the perception that expert review is a deterrent. Can= we > do something in the spec language to make this less of a concern? >=20 > E.g. "The purpose of expert review applied to provisional registration is= not > intended to impose onerous requirements on the proposals offered, but as = a > light-touch process to promote effective cooperative use of URI scheme > name space." I'm dubious that this would be perceived as less of a disincentive. >=20 > ... >=20 > Section 7.1: >=20 > [[CREF9: TODO: We don't want this. --??]] >=20 > I'm not sure what it is you don't want. The "--??" instead of "--DT" means it's not me. This comment was in the spec before I took over as primary editor. So the other authors will need to answer that. >=20 > I think it is useful that the IESG can be final arbiter, as it provides s= ome room > for making decisions that are not in strict accordance with the process > requirements, without kicking the door open to making arbitrary and > capricious decisions. There have been a few cases (I forget details) whe= re > the specific drafting of the process has seemed to be at odds with a comm= on > sense "do the right thing" approach - having a way to accommodate these > within a clearlhy documented framework seems useful to me. >=20 > ... >=20 > Section 7.2: >=20 > [[CREF10: Open Issue: I think the last > phrase above about RFC 3978 is problematic, as it just serves to > discourage registration. For example, third-party registrations > may have no way to grant such rights or make such assertions. > Similarly, a standard published by another SDO may have policy/ > process issues having a request treated as an IETF contribution. > Recommend deleting this sentence. --DT]] >=20 > I'd suggest that at least the registration template submitted to IANA be > treated as "IETF contribution", even if the rest of the document cannot, = since > IANA may need to republish that much. The registration template itself c= an > be short and consist mainly of pointers to other documents, so I don't th= ink > that should be a great disincentive. Are other IANA requests, like requests for a port number, treated as IETF contributions? I see nothing at http://www.iana.org/form/ports-servic= es or RFC 6335 that would indicate so. Why should this registry be different= ? >=20 > ... >=20 > Section 7.2: >=20 > [[CREF11: Open Issue: Say > more about guidance to the Designated Expert. Under what > circumstance should this happen? --DT]] >=20 > I'm not sure what guidance you have in mind here. Generally, I'd expect > upgrades from provisional to permanent to meet the same requirements as > permanent registrations (with provision for IESG last-say as noted above)= . >=20 > That's pretty much covered in section 7.3. I mean when would you actually take a Provisional application and say "hey IANA, this should really be Permanent even though they only asked for Provisional"? The only case I can think of is when someone violated the "For IETF Standards-Track documents, Permanent registration status is REQUIRED" requirement, but should that really be the job of the IESG to catch? Do we really need to say anything about the expert recommending an upgrade? -Dave >=20 > ... >=20 > [[CREF12: Open Issue: Some of the fields above may serve to deter > registration. Should some of them NOT be required for Provisional > registrations (including third-party ones)? For example, the > requirement to have clear security considerations is not appropriate > for third-party registrations. Typically one is forced to fill in > something like "Unknown, use with care." These seem to me to be more > appropriate inside the specification (if any) in the references, > rather than being required in the request template. Thus, as new > specifications update the uses (e.g., allow use with another HTTP > method), the IANA registry itself shouldn't be required to be > updated. --DT]] >=20 > Fair points. Part of the problem here, I think, is that the template ser= ves two > purposes: (a) registering a scheme that is fully described elsewhere, in = which > case its mainly a pointer to that specification, and (b) describing a sch= eme in > use that is not described in another document (which could really apply o= nly > for > provisional or historic schemes). >=20 > I think the headings (especially security considerations) are useful as > reminders of things to think about and maybe provide additional > information. >=20 > Maybe the template could be restructured as key information (Name, status= , > context of use, contact, change controller, and references); then have > "Additional information" with sub-headings to be filled in as required, a= nd all > optional for provisional registrations? >=20 > ... >=20 > Thanks, >=20 > #g > -- >=20 >=20 >=20 > On 14/02/2014 22:21, Dave Thaler wrote: > > This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI > > WG closed, we've gone back to it being an individual submission. > > This version addresses some of the issues raised on -04 (see > > draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as > > noted below. There are still a number of open issues for which, with > > the permission and help of the appsawg chairs, I have filed issue > > tracker tickets to track. > > > > I have not filed tickets for things already addressed in this version. > > These are enumerated below, and if there are disagreements on any > > then we can file a ticket for it. > > > > 1) The IRI WG previously agreed that the fragment component is not > > scheme-specific, and that the doc should be updated to clarify that > > a scheme definition should only define the scheme-specific part. > > This is now done at end of section 1. > > > > 2) Since the IRI WG was closed, I reverted most of the IRI-specific > > changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04. > > I left in text clarifying that a URI scheme name and an IRI scheme > > name were the same and hence there aren't separate registries, since > > apparently that was a common question on RFC 4395. > > > > 3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > > at last IETF, the IRI WG previously agreed that the 4-week mailing > > list review was optional for Provisional. RFC 4395 was ambiguous as > > to optional vs mandatory. Updated text in section 7.2 to make it > > explicit that it is only mandatory for Permanent. > > > > 4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation > > at last IETF, RFC 4395's convention for private namespaces (i.e., > > converting "." to "-" in scheme names based on a domain name) > > causes conflicts. Updated example to use "." instead of "-" to > > reduce collisions. And open ticket #17 covers the rest of the > > conflict problem. > > > > 5) Combined the Permanent, Provisional, and Historical URI Scheme > > sub-registries into one URI Scheme registry with a status column. > > This is done to make it easier to prevent duplicates and see > > existing conventions, as well as to support the "Pending Review" > > temporary state added in draft-ietf-iri-4395bis-irireg. > > > > -Dave > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, February 14, 2014 12:13 PM > > To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry Masinte= r; > Ted Hardie; Tony Hansen; Tony Hansen > > Subject: New Version Notification for draft-thaler-appsawg-uri-scheme- > reg-00.txt > > > > > > A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt > > has been successfully submitted by Dave Thaler and posted to the IETF > repository. > > > > Name: draft-thaler-appsawg-uri-scheme-reg > > Revision: 00 > > Title: Guidelines and Registration Procedures for New URI > Schemes > > Document date: 2014-02-14 > > Group: Individual Submission > > Pages: 18 > > URL: http://www.ietf.org/internet-drafts/draft-thaler-appsaw= g-uri- > scheme-reg-00.txt > > Status: https://datatracker.ietf.org/doc/draft-thaler-appsawg-u= ri- > scheme-reg/ > > Htmlized: http://tools.ietf.org/html/draft-thaler-appsawg-uri-sch= eme- > reg-00 > > > > > > Abstract: > > This document updates the guidelines and recommendations, as well a= s > > the IANA registration processes, for the definition of Uniform > > Resource Identifier (URI) schemes. It obsoletes RFC 4395. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > From nobody Thu Feb 20 23:27:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3381A0485 for ; Thu, 20 Feb 2014 23:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.542 X-Spam-Level: * X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5bL0RJrORwJ for ; Thu, 20 Feb 2014 23:27:55 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15C1A047D for ; Thu, 20 Feb 2014 23:27:54 -0800 (PST) Received: (qmail 35942 invoked from network); 21 Feb 2014 07:27:48 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 21 Feb 2014 07:27:48 -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; s=5306fff2.xn--9vv.k1402; i=johnl@user.iecc.com; bh=sNcZl4Ja2e7r9lev6IeuZ/wL57tCTRpKZ25u6WI2fTU=; b=Cb2Nksw3Z1V2/qiyTGb8ms+w6t3pWrosAGU2YsA8B+xmWwwndMBN9wFoT8be+AOkvPnrGsHA7tjU/NtU4+JaUi972V39mOLWVuS1T/WmqJ1mLzvyyM69vKkM3jY+B/e5CVFjowKWPYfzBXgmzj/sTwz/Av4j2hOtYv1zmME6r+t8XDOULir7jNKOSZu2lISrsDa05R/hLHadYdSV+JbqLZOemK0i5mkO/QFH9fh262Al8II+HRns2BZ7MuvceBRr 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; s=5306fff2.xn--9vv.k1402; bh=sNcZl4Ja2e7r9lev6IeuZ/wL57tCTRpKZ25u6WI2fTU=; b=ESTzVFUH6FCWAO+bMWB0+t4D2Mgdj3/4XtG2lPsqHH9WhcsrqjbEN8gxIrbAZesHacsmH95HMqWAWPP8PUWo0N2p+0No8XSYkX6n/lVMgLagZwPum9uEdKDoH6hQUL0aCcRxWDiEpbqquD9m4OPh0tYWEfcSsx/bmo0r2rnfJqD8cqXAOmXJYpiSJlWkepYIBez74/Oft62xX7hfjRYsbCOQUwYio91WgnK2TEtRvzs1qReys3Jn/8qNkXN8aksl Date: 21 Feb 2014 07:27:24 -0000 Message-ID: <20140221072724.76370.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <53060AAD.6010601@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/LkwO7XPyVSdWDEk6o9o6R-TDGnM Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 07:27:57 -0000 > "When a domain is listed as not accepting mail, as declared by a >NULL MX record, it also SHOULD NOT be authorized for use in any email >address or or domain field. That is, if it is not used for receiving >mail it is best not to use it with any other email function. Operators >can also publish SPF (RFC4408(bis?)) -ALL policies." I'm sympathetic to the intent, but I worry about the subtle changes to 5321 that this implies. Ned can probably think of six obscure but legitimate services that would break. I'm more inclined to note that for spam filtering purposes, many servers don't accept mail from domains they can't reply to, so if you want your mail delivered, MX . is probably not what you meant. R's, John From nobody Fri Feb 21 00:11:28 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D708F1A0152; Tue, 18 Feb 2014 11:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzizzqTLjs8r; Tue, 18 Feb 2014 11:40:28 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AA5251A052E; Tue, 18 Feb 2014 11:40:27 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id l18so3600367wgh.0 for ; Tue, 18 Feb 2014 11:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CRj7WuT5U216Jv6DWQsnzCTvLYk7lbn5J8RROpp7M8U=; b=cOCldMkTlFpIph4tYIAVxBmVORoouTTNyffKrZxYrtDjsuU+q8QiQrlOjXyIIMy7Iy tlqeC5NYL/RFpeVtSECsOxTBmM+RpBswsQZ5qYcDxcGumOV4IDUbmCWqzireBsdr+xPz aIN+PE7jEgfIbIQQm5ZOtuUPkvYkpZBgYoTSF6qQFQ82hsq8CAO0VSATP8wT17aCiu+D 4BjKZOQeZ74ohwGJ1RyFVo0N9B6cX+7WtB+VdY1l8se8OJPw3cwmw3S0zYaZpN1bydR5 6jTsDQVrJAK8kna01bK1epTnjSrzB1X3m7ELA1R16sFzM2O7OKJ5bsU+vj+0FZq+CAJU yXOg== MIME-Version: 1.0 X-Received: by 10.194.85.168 with SMTP id i8mr3446502wjz.81.1392752424290; Tue, 18 Feb 2014 11:40:24 -0800 (PST) Received: by 10.217.152.10 with HTTP; Tue, 18 Feb 2014 11:40:24 -0800 (PST) In-Reply-To: <51A57AA3.6000403@stpeter.im> References: <51A57AA3.6000403@stpeter.im> Date: Tue, 18 Feb 2014 13:40:24 -0600 Message-ID: From: Alan Johnston To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=089e010d7efc82902504f2b371cc Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/PDkqC-Bf8Zoxg8GDMhk2n_OWbuI X-Mailman-Approved-At: Fri, 21 Feb 2014 00:11:27 -0800 Cc: "apps-discuss@ietf.org" , "DRAGE, Keith \(Keith\)" , draft-ietf-cuss-sip-uui.all@tools.ietf.org, The IESG , "Vijay K. Gurbani" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-cuss-sip-uui-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 19:40:39 -0000 --089e010d7efc82902504f2b371cc Content-Type: text/plain; charset=ISO-8859-1 Peter, Thanks for the review. Somehow we missed seeing it, so apologies for the long delay. We have made all the changes you suggested, but won't be able to submit the I-D until March. Let us know if you have any concerns or comments. See below for a few comments. - Alan - On Tue, May 28, 2013 at 10:48 PM, Peter Saint-Andre wrote: > Greetings! > > I have been selected as the Applications Area Directorate [1] reviewer > for draft-ietf-cuss-sip-uui. Please resolve these comments along with > any other Last Call comments you might receive. Please wait for > direction from your document shepherd or AD before posting a new version > of the Internet-Draft. > > Document: draft-ietf-cuss-sip-uui-10 > Title: A Mechanism for Transporting User to User Call Control > Information in SIP > Reviewer: Peter Saint-Andre > Review Date: 2013-05-28 > IETF Last Call ends: 2013-05-29 > > Summary: The document is ready for advancement to Proposed Standard but > could do with a bit more polishing. > > Major Issues: > > None. > > Minor Issues: > > Section 3 states: > > For redirection and referral use cases and REQ-3, the header field > shall be included (escaped) into the Contact or Refer-To URI. > > No guidelines are provided for deciding between use of the Contact > header field or the Refer-To header field. Might that introduce the > possibility of interoperability problems? No, they are separate use cases. Rewrote this sentence to make this clearer. Which header is used is dependent on the use case, which is chosen by the UA initiating. As a result, there is no interop issues. > Also, a normative reference to > RFC 3515 seems needed here. > Added. > > In Section 4.1, has the ABNF been checked? > Yes. > > Section 4.2 states: > > Each octet of binary > data to be represented in the hex encoding MUST be mapped to two > hexadecimal digits (represented by ASCII characters 0-9, A-F and > a-f), each representing four bits within the octet. > > Is the output case-insensitive? > Yes. > > Also, in Section 4.2: > > Hex encoding is normally done as a token, > although quoted-string is permitted, in which case the quotes MUST be > ignored. > > The phrase "done as" is a bit loose; I assume you mean something like > "The hex-encoded value is normally represented using the 'token' > construction from RFC 3261, although the 'quoted-string' construction is > permitted..." > Done. > > In Section 5, what is the rationale for using a policy of "RFC Required" > rather than, say, "Specification Required"? Were the various RFC 5226 > options considered by the CUSS WG? > > Please note that Section 5 states: > > UUI packages defined using this SIP UUI mechanism MUST follow the > "RFC Required" guideline as defined in [RFC5226] and publish a > standards track RFC which describes the usage. > > However, Section 6.3 states: > > This specification establishes the uui-packages sub-registry under > http://www.iana.org/assignments/sip-parameters. New uui-packages > MUST follow the "Specification Required" guideline as defined in > [RFC5226]. > > Are those two statements in conflict? > We have changed it to "standards action" based on WG consensus and AD advice. > > In Section 5, condition #5 states: > > 5. The UUI data is not being utilized for user-to-user Remote > Procedure Call (RPC) calls. > > Is it possible to use the UUI header field for RPC calls, or in general > as a kind of back channel? If so, it would be good to discuss that in > the Security Considerations > No, we don't allow RFC call usages. > > Nits: > > It would be helpful to reference 4244bis on first mention of > History-Info. Also, isn't it properly "the History-Info header field"? > Done. Updated to RFC 7044. > > What is "hi-targeted-to-uri"? If that is a specification, a citation > would be helpful. > Added reference to RFC 7044. > > The following text would be better placed in the Terminology section > (or, at the least, before the first example that uses this convention, > not after the second example): > > Note that the tag convention from SIP Torture Test > Messages [RFC4475] is used to show that there are no line breaks in > the actual message syntax. > > Done. > Peter > > [1] > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > > > --089e010d7efc82902504f2b371cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Peter,

Thanks for the review. =A0Someho= w we missed seeing it, so apologies for the long delay.

We have made all the changes you suggested, but won't be able to = submit the I-D until March. =A0Let us know if you have any concerns or comm= ents.

See below for a few comments.

- Alan -


On Tue, May = 28, 2013 at 10:48 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
Greetings!

I have been selected as the Applications Area Directorate [1] reviewer
for draft-ietf-cuss-sip-uui. Please resolve these comments along with
any other Last Call comments you might receive. Please wait for
direction from your document shepherd or AD before posting a new version of the Internet-Draft.

Document: draft-ietf-cuss-sip-uui-10
Title: A Mechanism for Transporting User to User Call Control
Information in SIP
Reviewer: Peter Saint-Andre
Review Date: 2013-05-28
IETF Last Call ends: 2013-05-29

Summary: The document is ready for advancement to Proposed Standard but
could do with a bit more polishing.

Major Issues:

None.

Minor Issues:

Section 3 states:

=A0 =A0For redirection and referral use cases and REQ-3, the header field =A0 =A0shall be included (escaped) into the Contact or Refer-To URI.

No guidelines are provided for deciding between use of the Contact
header field or the Refer-To header field. Might that introduce the
possibility of interoperability problems?

N= o, they are separate use cases. =A0Rewrote this sentence to make this clear= er. =A0Which header is used is dependent on the use case, which is chosen b= y the UA initiating. =A0As a result, there is no interop issues.
=A0
Also, a normative reference t= o
RFC 3515 seems needed here.

Added.
=A0

In Section 4.1, has the ABNF been checked?

<= div>Yes.
=A0

Section 4.2 states:

=A0 =A0Each octet of binary
=A0 =A0data to be represented in the hex encoding MUST be mapped to two
=A0 =A0hexadecimal digits (represented by ASCII characters 0-9, A-F and
=A0 =A0a-f), each representing four bits within the octet.

Is the output case-insensitive?

Yes.
=A0

Also, in Section 4.2:

=A0 =A0Hex encoding is normally done as a token,
=A0 =A0although quoted-string is permitted, in which case the quotes MUST b= e
=A0 =A0ignored.

The phrase "done as" is a bit loose; I assume you mean something = like
"The hex-encoded value is normally represented using the 'token= 9;
construction from RFC 3261, although the 'quoted-string' constructi= on is
permitted..."

Done.
=A0<= /div>

In Section 5, what is the rationale for using a policy of "RFC Require= d"
rather than, say, "Specification Required"? Were the various RFC = 5226
options considered by the CUSS WG?

Please note that Section 5 states:

=A0 =A0UUI packages defined using this SIP UUI mechanism MUST follow the =A0 =A0"RFC Required" guideline as defined in [RFC5226] and publi= sh a
=A0 =A0standards track RFC which describes the usage.

However, Section 6.3 states:

=A0 =A0This specification establishes the uui-packages sub-registry under =A0 =A0http://www.iana.org/assignments/sip-parameters. =A0New uui-pac= kages
=A0 =A0MUST follow the "Specification Required" guideline as defi= ned in
=A0 =A0[RFC5226].

Are those two statements in conflict?

W= e have changed it to "standards action" based on WG consensus and= AD advice.
=A0

In Section 5, condition #5 states:

=A0 =A0 =A0 5. =A0The UUI data is not being utilized for user-to-user Remot= e
=A0 =A0 =A0 Procedure Call (RPC) calls.

Is it possible to use the UUI header field for RPC calls, or in general
as a kind of back channel? If so, it would be good to discuss that in
the Security Considerations

No, we don&= #39;t allow RFC call usages.
=A0

Nits:

It would be helpful to reference 4244bis on first mention of
History-Info. Also, isn't it properly "the History-Info header fie= ld"?

Done. =A0Updated to RFC 7044.=
=A0

What is "hi-targeted-to-uri"? If that is a specification, a citat= ion
would be helpful.

Added reference to RF= C 7044.
=A0

The following text would be better placed in the Terminology section
(or, at the least, before the first example that uses this convention,
not after the second example):

=A0 =A0Note that the <allOneLine> tag convention from SIP =A0Torture = Test
=A0 =A0Messages [RFC4475] is used to show that there are no line breaks in<= br> =A0 =A0the actual message syntax.


Done.


--089e010d7efc82902504f2b371cc-- From nobody Fri Feb 21 00:17:20 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BDF1A0009 for ; Fri, 21 Feb 2014 00:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJBFf9-IK016 for ; Fri, 21 Feb 2014 00:17:17 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB441A04C5 for ; Fri, 21 Feb 2014 00:17:17 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so536893wiw.3 for ; Fri, 21 Feb 2014 00:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DyWRJHXI90krzj2YyrLCdlYDEnFztzHLzrCjB9IWG18=; b=doaMdYM6DwK0p6JsWc5KcZjoHRhAOU/Zx6QMcJ4vYihhBH7SHRINPwIZDoDSmBfEh6 CzxGe1J/GMj5TdDMFSoZPCg21XNUdCjJdbiIZ8RYs2ZM9Pxe7pzr4rvBiMEki/5XQKHb kuZxa9hmJmSvdWqYsCpwBSgFvds++zk588yRrTh4L4BM2TGNb9EcJ4FYpk0Wt8rWtuBE 0pIZL6TBQYSkE5Pofbjz2LaTr8iQgKaftw/Xb2tAEiCe04nE7DF7MXB2ovaFDC5CMwPx xOQMP9a3ankC9XwVeEES592RsJTGaEG5w8O4C8ZIejYYUoQKA8xKEwI9UofACbYTvtMV EHRQ== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr1952695wib.5.1392970632809; Fri, 21 Feb 2014 00:17:12 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 21 Feb 2014 00:17:12 -0800 (PST) In-Reply-To: <53060AAD.6010601@dcrocker.net> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> Date: Fri, 21 Feb 2014 00:17:12 -0800 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=00248c0d7938c0567d04f2e63f52 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GABxhrDmEQRXX5s5XNDy5PFC_OQ Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 08:17:19 -0000 --00248c0d7938c0567d04f2e63f52 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 6:01 AM, Dave Crocker wrote: > "When a domain is listed as not accepting mail, as declared by a NULL > MX record, it also SHOULD NOT be authorized for use in any email address or > or domain field. That is, if it is not used for receiving mail it is best > not to use it with any other email function. Operators can also publish > SPF (RFC4408(bis?)) -ALL policies." > Better, but I find the use of "authorized" to be dodgy. I suggest s/authorized for use in/used in/. Also, to quibble about 2119 language: Since SHOULD NOT has been chosen here, under what circumstances might one legitimately deviate from that advice? This seems like MUST NOT territory to me. -MSK --00248c0d7938c0567d04f2e63f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 20, 2014 at 6:01 AM, Dave Crocker <dhc@dcrocke= r.net> wrote:
=A0 =A0=A0 "When a domain is listed as = not accepting mail, as declared by a NULL MX record, it also SHOULD NOT be = authorized for use in any email address or or domain field. That is, if it = is not used for receiving mail it is best not to use it with any other emai= l function. =A0Operators can also publish SPF (RFC4408(bis?)) -ALL policies= ."

Better, but I find the use of "author= ized" to be dodgy.=A0 I suggest s/authorized for use in/used in/.
<= br>
Also, to quibble about 2119 language: Since SHOULD NOT has be= en chosen here, under what circumstances might one legitimately deviate fro= m that advice?=A0 This seems like MUST NOT territory to me.

-MSK
--00248c0d7938c0567d04f2e63f52-- From nobody Fri Feb 21 00:55:01 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836CD1A003A for ; Fri, 21 Feb 2014 00:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFFtqhOam-EO for ; Fri, 21 Feb 2014 00:54:58 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC9D1A0032 for ; Fri, 21 Feb 2014 00:54:57 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 36031FA007F; Fri, 21 Feb 2014 08:54:53 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1392972892-1404-1403/11/19; Fri, 21 Feb 2014 08:54:52 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Fri, 21 Feb 2014 09:54:51 +0100 User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <1bb310f9-62c0-4440-b558-fa7ebaa26c50@gulbrandsen.priv.no> In-Reply-To: <20140221072724.76370.qmail@joyce.lan> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> <20140221072724.76370.qmail@joyce.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lirbyB6g0-F4EuAq16RbGebpWaY Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 08:55:00 -0000 On Friday, February 21, 2014 8:27:24 AM CEST, John Levine wrote: > I'm more inclined to note that for spam filtering purposes, many > servers don't accept mail from domains they can't reply to, so if you > want your mail delivered, MX . is probably not what you meant. +1 Arnt From nobody Fri Feb 21 03:38:08 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD021A00D4 for ; Fri, 21 Feb 2014 03:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBPraS80yFQE for ; Fri, 21 Feb 2014 03:38:02 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 343E81A0072 for ; Fri, 21 Feb 2014 03:38:02 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WGoQX-0004Vq-gx; Fri, 21 Feb 2014 11:37:57 +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 1WGoQW-0006R5-1h; Fri, 21 Feb 2014 11:37:57 +0000 Message-ID: <53073A80.7060602@ninebynine.org> Date: Fri, 21 Feb 2014 11:37:36 +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: Dave Thaler References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> <5301FD29.5000401@ninebynine.org> <365eaba6923149569140854c4bdd0815@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: <365eaba6923149569140854c4bdd0815@BY2PR03MB412.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/8yyk6kJlGMIv-SbC6evXDpeMNho Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 11:38:07 -0000 Dave, TL;DR: I've no objection to your points, just wanting to provide some feedback for the debate. I think our (small) differences hinge on the extent to which URI space (including provisional schemes) should be managed as a space of identifiers vs a desire for complete documentation of usage. I think that's a community consensus call, with reasonable views on all sides, and I'm OK with whatever point our community decides is most useful. In reading your responses, I'd also consider dropping even the FCFS constraint on provisional registration. I'd also be OK with dropping expert review for provisional registrations, if that's seen as a disincentive to registration. I'd still keep it for permanent registrations, as there is an issue of possible interference between different parts of the standards community, and given how fundamental URIs are to the architecture of the World Wide Web (which I think we'd agree is a pretty important application). My own concern is that some registrations look to me like protocol elements rather than identifiers, which don't have any need to be part of the URI space of *identifiers*. If one is to go to the trouble if designing a URI scheme, it seems a small step to indicate what it actually identifies. (FWIW, in reviewing proposals, I've questioned this aspect in provisional registration requests while making it clear that I'm not rejecting the proposal.) All of which, I think, resonates with your comments about separating registration requirements from guidance for scheme authors. #g -- On 21/02/2014 03:52, Dave Thaler wrote: > Graham Klyne writes: >> I'm responding with a perspective of being the current designated IANA >> reviewer. >> Broadly, I'm supportive of the changes proposed, and in particular to lower >> the perceived barrier to provisional registration of schemes. > > Great, thanks for the careful review. > >> Section 3.3 ("well defined"). One of the first questions I ask myself when >> reviewing a URI scheme proposal is: "What kinds of thing do URIs in this >> scheme identify, or how do I find out?". I'd like to see all scheme >> registrations providing a clear answer for this. > > Providing a clear answer to this and other questions is an example of > the burden that disincents people from registering. The act of writing > responses, and ensuring that they are correct and readable (and in some > cases, approved by management or legal or whoever else) is perceived as > onerous compared to the marginal benefit the applicant gets. > > >> One of the problems I have sometimes experienced in reviewing URI >> scheme registration submissions is understanding what the corresponding >> scheme is intended to identify. If it is a locator, then it's usually fairly clear. >> But some schemes I've seen - particularly where used as particular identifiers >> within other protocols - have been less clear (in their original submissions). >> Recent(ish) examples that come to mind are acct:, turn: and stun: (not >> criticizing them, just trying to give examples of things that are not always >> immediately clear). > > I agree. The larger question we should really be discussing is: why do we > need to know? Would we rather have unregistered schemes that we don't > know the answer for, or registered schemes that we don't know the answer for. > Currently none of the 4 stated goals of the registry really require such > understanding. An understanding of the _syntax_ is useful for another > unstated goal: improve compliance with guidelines/recommendations and > thus interop with generic URI parsers, etc. But an understanding of > _semantics_ doesn't seem to be required for that either. So what goal do > you think it's accomplishing? (Not to imply I don't think it's not valuable.) > > In my opinion, we need to separate guidance to defining document writers > from guidance and requirements to the person wanting to _register_ a scheme > (keeping in mind that they could be unrelated, as in the third-party case). > The bar for the latter should be low. Advice for the former should be liberally > given, but not interfere with keeping the bar to _register_ low. > > For example, you may recall that during the third-party registration experiment > that Alexey and I did, all the Microsoft schemes came from Alexey instead of > me, since the bar for third-party registration was lower... coming from me > might imply I actually vouched that the information was correct, which was > too onerous to do during the experiment. > >> I think the text "Schemes that are not intended to be used as locators >> SHOULD describe how the resource identified can be determined or >> accessed by software that obtains a URI of that scheme." goes some way to >> this, but that was present in the previous draft and didn't always get noticed. >> Also, there is not always a mechanism that is available to software (e.g. >> urn":). I'm wondering if this can be beefed up a bit... e.g. to lead with >> something like: >> >> "URI scheme specifications should be clear about the kind of resource that >> they may identify, or the means (technical or non-technical) by which URIs >> are related to the resources they identify" >> >> My text could surely be improved. The first part of this would apply to a >> scheme like "acct:" saying that an acct: URI identifies a user account in some >> domain or system (**); the latter would apply to locator schemes like http:, >> or identifier schemes like urn: where there is a defined administrative >> delegation structure. >> >> >> >> In making this comment, I also note there is some slight overlap with material >> covered in section 3.4. >> >> ... >> >> Section 3.8: >> >> Re: "[[CREF2: Open Issue: Should we define a mechanism to register a >> scheme prefix ("web+", "ms-", etc.)? --DT]]" >> >> I think not. >> >> I've not come across any great need for this, and I think it might even >> encourage scheme proliferation in conflict with the exhortations in section >> 3.1 ("In general, the use and deployment of new schemes in the Internet >> infrastructure may be costly; ...", etc.) > > I have certainly heard multiple requests for this because of the burden > of registering one scheme. When someone wants a set of related ones, > and possibly the ability to add more over time, I get asked if they can just > use a common prefix. Of course using a common prefix is good for > understanding that they're related. But they're asking because of the > burden of registering each one. So for example "ms-settings-*" > >> Section 4 >> >> re: [[CREF4: Open issue: previously this also RECOMMENDED following the >> same guidelines as for permanent registration. However, this higher >> bar disincented people to register schemes at all, and hence >> interfered with the goals of the registry. Hence tentatively >> removed, but need to confirm consensus on this. --DT]] >> >> I've not seen any cases where this has been a problem, but maybe that's >> because I mainly see a self-selecting population ;) (I.e. those who have >> actually submitted a registration request.) > > Yes, that's why. But I guess my view goes back to my point above > about guidance to doc authors vs guidance to applicants. > >> Some time ago, we started creating a FAQ/guidance page at IANA for a >> similar registry (message header fields), with the goal of demystifying the >> process and encouraging early registration. Unfortunately, that effort fizzled >> (though I think an initial draft is still around on an IETF/IANA wiki page.) >> >> Maybe this kind of approach would be an alternative? I.e. create a FAQ, and >> direct readers to that page for provisional registration. The FAQ-as-guidance >> can then be updated more easily than the BCP document (within its defined >> constraints). >> >> ... >> >> Section 7.1 >> >> [[CREF8: Open Issue: Should Provisional status just use First Come >> First Serve? Someone suggested FCFS with Expert Review afterwards, >> but the benefit and efficacy of a subsequent Expert Review seems >> dubious to me and might only serve to deter registrations in the >> first place, which is the problem we're trying to solve. --DT]] >> >> Given the limited nature of URI scheme name space, I think that IESG/IANA >> should always have final say about name allocation. Given that we try to >> keep the bar low, I feel formal FCFS makes it too easy to use provisional >> registration as a land grab - writing that into the spec would make it harder >> for an expert reviewer to push for alternatives where appropriate. (I think >> there is one occasion in the past few years where the choice of name has >> been cause for push-back, so it's not a great problem.) > > The notion that the expert reviewer might push for alternatives is part of > the disincentive to register in the first place. So I think that not having FCFS > for Provisional just results in the current mass unregistered use, which doesn't > help anyone. It's a no-win situation :) > >> As reviewer, I have tried to treat the role as providing guidance rather than >> as gatekeeper (I don't think I've ever recommended rejection of a >> provisional registration request, though I do often make comments), so I'm a >> little troubled by the perception that expert review is a deterrent. Can we >> do something in the spec language to make this less of a concern? >> >> E.g. "The purpose of expert review applied to provisional registration is not >> intended to impose onerous requirements on the proposals offered, but as a >> light-touch process to promote effective cooperative use of URI scheme >> name space." > > I'm dubious that this would be perceived as less of a disincentive. > >> >> ... >> >> Section 7.1: >> >> [[CREF9: TODO: We don't want this. --??]] >> >> I'm not sure what it is you don't want. > > The "--??" instead of "--DT" means it's not me. This comment was in the > spec before I took over as primary editor. So the other authors will > need to answer that. > >> >> I think it is useful that the IESG can be final arbiter, as it provides some room >> for making decisions that are not in strict accordance with the process >> requirements, without kicking the door open to making arbitrary and >> capricious decisions. There have been a few cases (I forget details) where >> the specific drafting of the process has seemed to be at odds with a common >> sense "do the right thing" approach - having a way to accommodate these >> within a clearlhy documented framework seems useful to me. >> >> ... >> >> Section 7.2: >> >> [[CREF10: Open Issue: I think the last >> phrase above about RFC 3978 is problematic, as it just serves to >> discourage registration. For example, third-party registrations >> may have no way to grant such rights or make such assertions. >> Similarly, a standard published by another SDO may have policy/ >> process issues having a request treated as an IETF contribution. >> Recommend deleting this sentence. --DT]] >> >> I'd suggest that at least the registration template submitted to IANA be >> treated as "IETF contribution", even if the rest of the document cannot, since >> IANA may need to republish that much. The registration template itself can >> be short and consist mainly of pointers to other documents, so I don't think >> that should be a great disincentive. > > Are other IANA requests, like requests for a port number, treated as > IETF contributions? I see nothing at http://www.iana.org/form/ports-services > or RFC 6335 that would indicate so. Why should this registry be different? > >> >> ... >> >> Section 7.2: >> >> [[CREF11: Open Issue: Say >> more about guidance to the Designated Expert. Under what >> circumstance should this happen? --DT]] >> >> I'm not sure what guidance you have in mind here. Generally, I'd expect >> upgrades from provisional to permanent to meet the same requirements as >> permanent registrations (with provision for IESG last-say as noted above). >> >> That's pretty much covered in section 7.3. > > I mean when would you actually take a Provisional application and say > "hey IANA, this should really be Permanent even though they only asked > for Provisional"? The only case I can think of is when someone violated > the "For IETF Standards-Track documents, Permanent registration status is > REQUIRED" requirement, but should that really be the job of the IESG to > catch? Do we really need to say anything about the expert recommending > an upgrade? > > -Dave > >> >> ... >> >> [[CREF12: Open Issue: Some of the fields above may serve to deter >> registration. Should some of them NOT be required for Provisional >> registrations (including third-party ones)? For example, the >> requirement to have clear security considerations is not appropriate >> for third-party registrations. Typically one is forced to fill in >> something like "Unknown, use with care." These seem to me to be more >> appropriate inside the specification (if any) in the references, >> rather than being required in the request template. Thus, as new >> specifications update the uses (e.g., allow use with another HTTP >> method), the IANA registry itself shouldn't be required to be >> updated. --DT]] >> >> Fair points. Part of the problem here, I think, is that the template serves two >> purposes: (a) registering a scheme that is fully described elsewhere, in which >> case its mainly a pointer to that specification, and (b) describing a scheme in >> use that is not described in another document (which could really apply only >> for >> provisional or historic schemes). >> >> I think the headings (especially security considerations) are useful as >> reminders of things to think about and maybe provide additional >> information. >> >> Maybe the template could be restructured as key information (Name, status, >> context of use, contact, change controller, and references); then have >> "Additional information" with sub-headings to be filled in as required, and all >> optional for provisional registrations? >> >> ... >> >> Thanks, >> >> #g >> -- >> >> >> >> On 14/02/2014 22:21, Dave Thaler wrote: >>> This draft replaces draft-ietf-iri-4395bis-irireg-04. Since the IRI >>> WG closed, we've gone back to it being an individual submission. >>> This version addresses some of the issues raised on -04 (see >>> draft-thaler-uri-scheme-reg-ps-01 and the discussion at last IETF) as >>> noted below. There are still a number of open issues for which, with >>> the permission and help of the appsawg chairs, I have filed issue >>> tracker tickets to track. >>> >>> I have not filed tickets for things already addressed in this version. >>> These are enumerated below, and if there are disagreements on any >>> then we can file a ticket for it. >>> >>> 1) The IRI WG previously agreed that the fragment component is not >>> scheme-specific, and that the doc should be updated to clarify that >>> a scheme definition should only define the scheme-specific part. >>> This is now done at end of section 1. >>> >>> 2) Since the IRI WG was closed, I reverted most of the IRI-specific >>> changes from RFC 4395 that were in draft-ietf-iri-4395bis-irireg-04. >>> I left in text clarifying that a URI scheme name and an IRI scheme >>> name were the same and hence there aren't separate registries, since >>> apparently that was a common question on RFC 4395. >>> >>> 3) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation >>> at last IETF, the IRI WG previously agreed that the 4-week mailing >>> list review was optional for Provisional. RFC 4395 was ambiguous as >>> to optional vs mandatory. Updated text in section 7.2 to make it >>> explicit that it is only mandatory for Permanent. >>> >>> 4) As noted in draft-thaler-uri-scheme-reg-ps and in my presentation >>> at last IETF, RFC 4395's convention for private namespaces (i.e., >>> converting "." to "-" in scheme names based on a domain name) >>> causes conflicts. Updated example to use "." instead of "-" to >>> reduce collisions. And open ticket #17 covers the rest of the >>> conflict problem. >>> >>> 5) Combined the Permanent, Provisional, and Historical URI Scheme >>> sub-registries into one URI Scheme registry with a status column. >>> This is done to make it easier to prevent duplicates and see >>> existing conventions, as well as to support the "Pending Review" >>> temporary state added in draft-ietf-iri-4395bis-irireg. >>> >>> -Dave >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Friday, February 14, 2014 12:13 PM >>> To: Larry Masinter; Dave Thaler; Ted Hardie; Dave Thaler; Larry Masinter; >> Ted Hardie; Tony Hansen; Tony Hansen >>> Subject: New Version Notification for draft-thaler-appsawg-uri-scheme- >> reg-00.txt >>> >>> >>> A new version of I-D, draft-thaler-appsawg-uri-scheme-reg-00.txt >>> has been successfully submitted by Dave Thaler and posted to the IETF >> repository. >>> >>> Name: draft-thaler-appsawg-uri-scheme-reg >>> Revision: 00 >>> Title: Guidelines and Registration Procedures for New URI >> Schemes >>> Document date: 2014-02-14 >>> Group: Individual Submission >>> Pages: 18 >>> URL: http://www.ietf.org/internet-drafts/draft-thaler-appsawg-uri- >> scheme-reg-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-thaler-appsawg-uri- >> scheme-reg/ >>> Htmlized: http://tools.ietf.org/html/draft-thaler-appsawg-uri-scheme- >> reg-00 >>> >>> >>> Abstract: >>> This document updates the guidelines and recommendations, as well as >>> the IANA registration processes, for the definition of Uniform >>> Resource Identifier (URI) schemes. It obsoletes RFC 4395. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> 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 nobody Fri Feb 21 06:45:06 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09C41A0316 for ; Fri, 21 Feb 2014 06:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJxU_rv5c2Vs for ; Fri, 21 Feb 2014 06:45:00 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CB97B1A0303 for ; Fri, 21 Feb 2014 06:45:00 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s1LEiqot031088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 06:44:55 -0800 Message-ID: <53076630.2080306@dcrocker.net> Date: Fri, 21 Feb 2014 06:44:00 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 21 Feb 2014 06:44:55 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/52mye75XdZ7ZL8Ns0dqAmR33_Ss Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:45:03 -0000 On 2/21/2014 12:17 AM, Murray S. Kucherawy wrote: > On Thu, Feb 20, 2014 at 6:01 AM, Dave Crocker > wrote: > > "When a domain is listed as not accepting mail, as declared by a > NULL MX record, it also SHOULD NOT be authorized for use in any > email address or or domain field. That is, if it is not used for > receiving mail it is best not to use it with any other email > function. Operators can also publish SPF (RFC4408(bis?)) -ALL > policies." > > Better, but I find the use of "authorized" to be dodgy. I suggest > s/authorized for use in/used in/. Except that 'authorized' is the essential point, to distinguish between legitimate uses and spoofing, etc. uses. The word 'legitimate' doesn't work well here. So 'authorized' seems the next closes. There are three essential problems with the original wording. The first is that domains don't 'send' mail. Also the word 'send' is frankly ambiguous in its own right here. And lastly is that the stricture needs to cover keep the domain name out of a number of different fields. > Also, to quibble about 2119 language: Since SHOULD NOT has been > chosen here, under what circumstances might one legitimately deviate > from that advice? This seems like MUST NOT territory to me. I copied the normative from the original, and -- wait for it -- don't have an opinion on the choice. On 2/20/2014 11:27 PM, John Levine wrote: > I'm sympathetic to the intent, but I worry about the subtle changes > to 5321 that this implies. Ned can probably think of six obscure but > legitimate services that would break. I've no idea what 'changes' are meant, and since they are stated, can't respond. My own reading of both the original text and my proffered replacement is that they don't change 5321 at all. > I'm more inclined to note that for spam filtering purposes, many > servers don't accept mail from domains they can't reply to, so if you > want your mail delivered, MX . is probably not what you meant. Something along those lines sounds like useful explanatory text. By narrowly citing replying, it excludes exclusion from other places such as Received header fields. That might be ok, but it's worth being clear about it now. That's why my suggested text was indiscriminate: if you declare you don't use it for 'sending' then keep it the heck out of /all/ places in email-related processing fields. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Feb 21 07:25:00 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CBD1A0185 for ; Fri, 21 Feb 2014 07:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjQ0tX4b0WlA for ; Fri, 21 Feb 2014 07:24:57 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id 647A01A016F for ; Fri, 21 Feb 2014 07:24:57 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58397) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1WGry4-0005IQ-DV (Exim 4.82_3-c0e5623) (return-path ); Fri, 21 Feb 2014 15:24:48 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WGry4-0002yx-3U (Exim 4.72) (return-path ); Fri, 21 Feb 2014 15:24:48 +0000 Date: Fri, 21 Feb 2014 15:24:48 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: dcrocker@bbiw.net In-Reply-To: <53076630.2080306@dcrocker.net> Message-ID: References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> <53076630.2080306@dcrocker.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/aqxN27W4rfoX39TpCzERFFgzdug Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 15:25:00 -0000 Dave Crocker wrote: > > By narrowly citing replying, it excludes exclusion from other places > such as Received header fields. That might be ok, but it's worth being > clear about it now. > > That's why my suggested text was indiscriminate: if you declare you > don't use it for 'sending' then keep it the heck out of /all/ places in > email-related processing fields. I think it would be wrong to go that far. You need to make a distinction between mail domains and host names. Domains in Received: and Message-ID: headers are host names, not mail domains, so it should be OK for them to be null MX domains. For instance, an admin might want to set up null MX records for client machines to indicate that they don't run MTAs. When a user runs an MUA on one of these client machines, their message submissions will contain the client machine host name in a Received: header and possibly also the Message-ID header. (Real world example: eng.cam.ac.uk, though they use a sinkhole MTA rather than null MX records.) A null MX record should just imply that an email address is invalid if it uses that domain. Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Cyclonic in south at first, otherwise northeasterly, 6 to gale 8, occasionally severe gale 9 at first. Very rough or high, becoming rough or very rough. Rain or squally showers. Moderate or good, occasionally poor. From nobody Fri Feb 21 07:34:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EC71A018F for ; Fri, 21 Feb 2014 07:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVg_WWDatI-M for ; Fri, 21 Feb 2014 07:34:43 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 625EF1A017D for ; Fri, 21 Feb 2014 07:34:43 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s1LFYXnV032399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 07:34:36 -0800 Message-ID: <530771D5.2000104@dcrocker.net> Date: Fri, 21 Feb 2014 07:33:41 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tony Finch References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> <53076630.2080306@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 21 Feb 2014 07:34:36 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/a-9H5xg_XhW9Oo-4S4FI53ZO_J0 Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:34:45 -0000 Tony, Thanks for working this through more carefully than I had. I agree with your assessment. A version of your first paragraph would be worth including in the document, I think, to help educate the reader. And your ending sentence is particularly nice, as a specification of the assertion that needs to be made, IMO. d/ On 2/21/2014 7:24 AM, Tony Finch wrote: > Dave Crocker wrote: >> >> By narrowly citing replying, it excludes exclusion from other places >> such as Received header fields. That might be ok, but it's worth being >> clear about it now. >> >> That's why my suggested text was indiscriminate: if you declare you >> don't use it for 'sending' then keep it the heck out of /all/ places in >> email-related processing fields. > > I think it would be wrong to go that far. You need to make a distinction > between mail domains and host names. Domains in Received: and Message-ID: > headers are host names, not mail domains, so it should be OK for them to > be null MX domains. > > For instance, an admin might want to set up null MX records for client > machines to indicate that they don't run MTAs. When a user runs an MUA on > one of these client machines, their message submissions will contain the > client machine host name in a Received: header and possibly also the > Message-ID header. > > (Real world example: eng.cam.ac.uk, though they use a sinkhole MTA rather > than null MX records.) > > > A null MX record should just imply that an email address is invalid if > it uses that domain. > > > Tony. > -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Feb 21 08:19:50 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD101A01F4 for ; Fri, 21 Feb 2014 08:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5L5HnUJU5i4 for ; Fri, 21 Feb 2014 08:19:47 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD6DE1A01EC for ; Fri, 21 Feb 2014 08:19:46 -0800 (PST) Received: (qmail 28966 invoked from network); 21 Feb 2014 16:19:41 -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:user-agent:cleverness; s=7125.53077c9d.k1402; i=johnl-iecc.com@submit.iecc.com; bh=9E4lApVZ/+L4/SSfol26lRT8/F1iPEr4HEuhGEa8+T4=; b=Md2O/TypEMCjhcjmmfIVdOe3xZrXdl5eP569p8rALb0ZY5RmoZ4Co1uvMoqxE7UUPGgVlj1syg1Djmfc965+RCnCqqJxaHn/wrEfpeoQ1K1oxRjKVZ7HIiy68P30bpSQ8YUFvQOa1zNnmfmfXX62SZiUgsgjPo+iQ6v9zlrMP5O7htKZVY0FRs9phVjhTC5BP2C6KneHpQ2fw/RTOVnEpv+BJJqSgAavwLyeiDs2kEcKXOV070h9YzfRiWcwKPl3 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:user-agent:cleverness; s=7125.53077c9d.k1402; olt=johnl-iecc.com@submit.iecc.com; bh=9E4lApVZ/+L4/SSfol26lRT8/F1iPEr4HEuhGEa8+T4=; b=fccCoUe4eoDJK0ONvmWBTlUYO0SQgLORP1pAYl1TS8h8PneMSk81acreijlainpVOq9Tg2AS8+OqBw1Ebd1aKS9JncEC+xEf1uwDtNFUVNHH9UjluF9xjcXGb/06Hvjmo3a/TbZJlbeLvtqoJE2zWNgx/Z+gptowTw4y+iqYlTiXZvZHNLW2c1eTsgUrGtkpvbS7Wf86HmAHHL3tYCGGcTiNqCEVQiQ8CA6Ie4VbKNH1T0Sp57MQnbIwkA6XtP7r Received: from joyce.lan ([24.59.92.2]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 21 Feb 2014 16:19:40 -0000 Date: 21 Feb 2014 11:19:40 -0500 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <53076630.2080306@dcrocker.net> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> <53076630.2080306@dcrocker.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/gt9r3X5u0SZLbSKLdLv8SSZlyRI Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 16:19:48 -0000 > On 2/20/2014 11:27 PM, John Levine wrote: >> I'm sympathetic to the intent, but I worry about the subtle changes >> to 5321 that this implies. Ned can probably think of six obscure but >> legitimate services that would break. > > I've no idea what 'changes' are meant, and since they are stated, can't > respond. My own reading of both the original text and my proffered > replacement is that they don't change 5321 at all. In RFC 5321 sec 4.5.5 on null reverse-path it says: All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path. That's the only text I can find that puts any conditions on reverse-path. Like I said, it's tacky to use a bounce address that isn't deliverable but it's always been valid, and spam filtering heuristics that use various sorts of DNS (or worse) callbacks to check its validity have been out of scope of 5321. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Feb 21 10:17:37 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325B61A0245 for ; Fri, 21 Feb 2014 10:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-OdLJJAdXqk for ; Fri, 21 Feb 2014 10:17:34 -0800 (PST) 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 3AAE61A0219 for ; Fri, 21 Feb 2014 10:17:34 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so1035475wgh.2 for ; Fri, 21 Feb 2014 10:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wnhAOtjsFUcNH7xehz7v0J02RMIvcll1QQQnTfccyxI=; b=m0yzgNj2qe3vnYZey27CgZ4JwBFmG+kjCJhtQHghjZ3vLL5dequJmOw5p7eMrLd/LO vkLTTJB1902+Ip1kVuyKZsfJLmguu+npHWtQyiGzF5VMcTHLjIqQUCA3sW9FcVfXwelo RBDuwKaD+ccbPKdnMqUduR3Bs2wHqvsM1f8Wh+mVG1YDP5Z11RPXzPJ/t6XfQiBN3Cdc HGhgiFZ2qVUI3tWv7k45jLPQoB05Xj9Hq3WmCwMZFffWimjqiRCKJIjdrICVepWoc+/d oFM76zCrPNgi830fZv+B8xH8QIyKRSP4TLTcnaEIu4XBBmDCYh2THNXft/KDAqR1dGwz HZSw== MIME-Version: 1.0 X-Received: by 10.194.77.7 with SMTP id o7mr8363703wjw.35.1393006649731; Fri, 21 Feb 2014 10:17:29 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 21 Feb 2014 10:17:29 -0800 (PST) Date: Fri, 21 Feb 2014 10:17:29 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7bfd05fc86ee5704f2eea27d Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/KUvhk8C8uEMKYtLTMkvtCCGD4Hg Subject: [apps-discuss] IETF 89 APPSAWG/APPAREA draft agenda X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 18:17:36 -0000 --047d7bfd05fc86ee5704f2eea27d Content-Type: text/plain; charset=ISO-8859-1 Colleagues, The draft agenda for the APPSAWG/APPAREA meeting at IETF 89 is now available. We apologize for the delay in posting it. http://www.ietf.org/proceedings/89/agenda/agenda-89-appsawg Please let us know ASAP if you made a request for time that we missed. The agenda is, as usual, very tight and, as usual, we got a lot of last-minute requests so it's quite possible something needs attention. The final agenda is due Monday. We don't have a lot of flexibility in terms of time. If you have more time than you need assigned to you, please let us know so we can reallocate accordingly. -MSK, APPSAWG co-chair --047d7bfd05fc86ee5704f2eea27d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

The draft agenda f= or the APPSAWG/APPAREA meeting at IETF 89 is now available.=A0 We apologize= for the delay in posting it.

http://www.ietf.org/proceedings/89/agenda= /agenda-89-appsawg

Please let us know ASAP if you made a request for time that we mi= ssed.=A0 The agenda is, as usual, very tight and, as usual, we got a lot of= last-minute requests so it's quite possible something needs attention.= =A0 The final agenda is due Monday.

We don't have a lot of flexibility in terms of time.=A0 = If you have more time than you need assigned to you, please let us know so = we can reallocate accordingly.

-MSK, APPSAWG co-cha= ir

--047d7bfd05fc86ee5704f2eea27d-- From nobody Fri Feb 21 10:44:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD561A056F for ; Fri, 21 Feb 2014 10:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTAfz7q2khuB for ; Fri, 21 Feb 2014 10:43:54 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA431A01ED for ; Fri, 21 Feb 2014 10:43:53 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id k14so2793960wgh.2 for ; Fri, 21 Feb 2014 10:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KHv4XGzJ32viUs+Ofucd5wZ7d57S9Z9+wmH+cnuz0Kw=; b=YQG5CGX9N6pIxPsC4viy2EyQUTM9Za+cmpGSBZb2WaqdlEd6Zn1NNoWdZV8tYDJSTp /3u2A41oUVFCGEfO/HBsGeELA1rQHYK2XETX04Y/pLlSye5TcPwudGcz0Kn9GrZXpz7w 8A0WEygI1gBHLhzs4JcVTDa0dFSy1PPYmFY/23778PHToHbZ1PL1UMR2+jU9syz3999N mRIywa2q/+nHfwy1jP/dZ/GQ8U5Ep+DHxke1IwnBe3GD3wrWm2W9lwnzJzNS8vUIvacI tY20bszNUHyZiQJUOkwGmWhYvW2tEKeDR2qnJ7YvtDX/rVT8+obVyrHfQBm3w2vGgG79 3tWg== MIME-Version: 1.0 X-Received: by 10.194.61.210 with SMTP id s18mr8583424wjr.10.1393008229650; Fri, 21 Feb 2014 10:43:49 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 21 Feb 2014 10:43:49 -0800 (PST) In-Reply-To: <53076630.2080306@dcrocker.net> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> <53076630.2080306@dcrocker.net> Date: Fri, 21 Feb 2014 10:43:49 -0800 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7b86d586b2990904f2ef00e9 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/9d982vCVaInXvI2B8OXxjRHP6qs Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 18:43:57 -0000 --047d7b86d586b2990904f2ef00e9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 21, 2014 at 6:44 AM, Dave Crocker wrote: > Except that 'authorized' is the essential point, to distinguish between > legitimate uses and spoofing, etc. uses. The word 'legitimate' doesn't > work well here. So 'authorized' seems the next closes. > > There are three essential problems with the original wording. The first > is that domains don't 'send' mail. Also the word 'send' is frankly > ambiguous in its own right here. And lastly is that the stricture needs > to cover keep the domain name out of a number of different fields. > My problem is that "SHOULD NOT be authorized for use" is a concept that exists entirely inside the ADMD creating the content; it points to something that's not subject to interoperability. "SHOULD NOT be used", by contrast, is something that a receiver can evaluate. --047d7b86d586b2990904f2ef00e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 21, 2014 at 6:44 AM, Dave Crocker <dhc@dcrocke= r.net> wrote:
Except that 'authoriz= ed' is the essential point, to distinguish between
legitimate uses and spoofing, etc. uses. =A0The word 'legitimate' d= oesn't
work well here. So 'authorized' seems the next closes.

There are three essential problems with the original wording. The first
is that domains don't 'send' mail. Also the word 'send'= is frankly
ambiguous in its own right here. And lastly is that the stricture needs
to cover keep the domain name out of a number of different fields.

My problem is that "SHOULD NOT be authoriz= ed for use" is a concept that exists entirely inside the ADMD creating= the content; it points to something that's not subject to interoperabi= lity.=A0 "SHOULD NOT be used", by contrast, is something that a r= eceiver can evaluate.
--047d7b86d586b2990904f2ef00e9-- From nobody Fri Feb 21 11:47:57 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12211A021B for ; Fri, 21 Feb 2014 11:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r-jMedYXEUA for ; Fri, 21 Feb 2014 11:47:53 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 406A91A0506 for ; Fri, 21 Feb 2014 11:47:53 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t61so2950852wes.0 for ; Fri, 21 Feb 2014 11:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hk1sYJoTGv475YLirDWYBrjLkp7V5Y6T+htV+EhjWCc=; b=htcb1rjn68i07sCp48ECLZiip23t8XPS+/FVXdrKDWA6zJeI/XjNC3aOdwVQDe4OV9 d23Lod9VTW6XgebAmyGMA80FR8vUBeYJWwEl0t2c5yI6K2EauIWctqP4WYyJYfgTHxcR 2ieS+ITe5YbvjvhFWOSbC/GCLm16YAQF12r7KiL+1ljlSN1Ofu3TVZ0usmZ8Cud6INSo sv79TLcgXu4gRIsQnxmdpGnyin6Ad+S+HDtG6YoQhVdKc3u7LCMZGIMpXqS8ie0Gx7Ap GxsmFlPzU6eoWTjLbKILhQfqUHBUfQ3qo6FcKt2yxhERIBq8NHoXmXDi2btyIGjYeDLI MUaQ== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr4659294wib.5.1393012068674; Fri, 21 Feb 2014 11:47:48 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 21 Feb 2014 11:47:48 -0800 (PST) Date: Fri, 21 Feb 2014 11:47:48 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=00248c0d79388575d604f2efe524 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/H_NlV3t3oUFoDCtQrQ5nGY_7ycM Subject: [apps-discuss] Slides (Re: IETF 89 APPSAWG/APPAREA draft agenda) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 19:47:55 -0000 --00248c0d79388575d604f2efe524 Content-Type: text/plain; charset=ISO-8859-1 If you are on the agenda and have slides to be projected for your timeslot, please send them to appsawg-chairs@tools.ietf.org by Sunday evening, the day before the meeting, in PDF form. We will not be able to accommodate USB sticks or other last-minute submissions. -MSK On Fri, Feb 21, 2014 at 10:17 AM, Murray S. Kucherawy wrote: > Colleagues, > > The draft agenda for the APPSAWG/APPAREA meeting at IETF 89 is now > available. We apologize for the delay in posting it. > > http://www.ietf.org/proceedings/89/agenda/agenda-89-appsawg > > Please let us know ASAP if you made a request for time that we missed. > The agenda is, as usual, very tight and, as usual, we got a lot of > last-minute requests so it's quite possible something needs attention. The > final agenda is due Monday. > > We don't have a lot of flexibility in terms of time. If you have more > time than you need assigned to you, please let us know so we can reallocate > accordingly. > > -MSK, APPSAWG co-chair > > --00248c0d79388575d604f2efe524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you are on the agenda and have slides to be projec= ted for your timeslot, please send them to appsawg-chairs@tools.ietf.org by Sunday evening, the d= ay before the meeting, in PDF form.=A0 We will not be able to accommodate U= SB sticks or other last-minute submissions.

-MSK


On Fri, Feb 21, 2014 at 10:17 AM, Murray S. Kucherawy <= superuser@gmail.com> wrote:
Colleagues,<= br>
The draft agenda for the APPSAWG/APPAREA meeting at IETF 89 is= now available.=A0 We apologize for the delay in posting it.

http://www.ietf.org/proceedings/89/agenda/agenda-89-apps= awg

Please let us know ASAP if you made a request for time that we mi= ssed.=A0 The agenda is, as usual, very tight and, as usual, we got a lot of= last-minute requests so it's quite possible something needs attention.= =A0 The final agenda is due Monday.

We don't have a lot of flexibility in terms of time.=A0 = If you have more time than you need assigned to you, please let us know so = we can reallocate accordingly.

-MSK, APPSAWG co-cha= ir


--00248c0d79388575d604f2efe524-- From nobody Fri Feb 21 11:59:04 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D511A0278 for ; Fri, 21 Feb 2014 11:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ygmtv4Gy6P_H for ; Fri, 21 Feb 2014 11:59:02 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 363B01A0267 for ; Fri, 21 Feb 2014 11:59:02 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s1LJwptB005708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 11:58:54 -0800 Message-ID: <5307AFC7.6070103@dcrocker.net> Date: Fri, 21 Feb 2014 11:57:59 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Dave Crocker References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> <53076630.2080306@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 21 Feb 2014 11:58:56 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/D1ed8r-usKFkAaWNuv1zxgmWDjk Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:59:03 -0000 On 2/21/2014 10:43 AM, Murray S. Kucherawy wrote: > On Fri, Feb 21, 2014 at 6:44 AM, Dave Crocker > wrote: > > Except that 'authorized' is the essential point, to distinguish between > legitimate uses and spoofing, etc. uses. The word 'legitimate' doesn't > work well here. So 'authorized' seems the next closes. > > There are three essential problems with the original wording. The first > is that domains don't 'send' mail. Also the word 'send' is frankly > ambiguous in its own right here. And lastly is that the stricture needs > to cover keep the domain name out of a number of different fields. > > > My problem is that "SHOULD NOT be authorized for use" is a concept that > exists entirely inside the ADMD creating the content; it points to > something that's not subject to interoperability. "SHOULD NOT be used", > by contrast, is something that a receiver can evaluate. We've all locked into some interesting linguistic challenges, though they seem to be getting cast in terms of a kind of email protocol challenge. To start: I'm not trying to change any existing email standards and don't think the current topic will do that., Rather, I'm trying to do two other things. One is to distinguish between activities authorized by the domain owner, versus those outside of the owner's control. And then to suggest proscription of what the domain owner authorizes for use. Simply put: If one publishes a NULL MX for the name, one shouldn't use that domain for an email address anywhere. (Tony's language was good for that I think.) And I've no idea whether should or must should be used -- and don't much care. But the linguistic wrinkle is that those nasty spoofers are sitting out there, getting in the way of generic language like "should not be used". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Feb 22 19:37:10 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A711A02AF for ; Sat, 22 Feb 2014 19:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQei1fi4LrVk for ; Sat, 22 Feb 2014 19:37:06 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 835931A0294 for ; Sat, 22 Feb 2014 19:37:06 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P4O3B3PXCG0000UP@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 22 Feb 2014 19:32:37 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P4NWNVLF6800004W@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 22 Feb 2014 19:32:35 -0800 (PST) Message-id: <01P4O3B2JHP800004W@mauve.mrochek.com> Date: Sat, 22 Feb 2014 19:23:57 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 19 Feb 2014 17:51:32 -0600 (CST)" <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <298464235.101520.1392846134250.JavaMail.zimbra@peachymango.org> <01P4JKS49U0U00004W@mauve.mrochek.com> <1417200617.105964.1392853892918.JavaMail.zimbra@peachymango.org> To: apps-discuss@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/HeHomEXyjHpVpMbl0OQKCkFpcbM Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2014 03:37:08 -0000 > ----- Original Message ----- > > From: "Ned Freed" > > To: "Franck Martin" > > Cc: apps-discuss@ietf.org > > Sent: Wednesday, February 19, 2014 1:51:32 PM > > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt > > > > > This draft requires current filtering solutions to change behavior. The > > > presence of an MX will indicate the domain is emailable (cf spamassassin > > > rules) > > > until the software is changed to recognize the 0. We will have different > > > behavior while this is getting implemented. > > > > The domain validity check is extremely weak to begin with. And given the > > speed > > at which such rules have to evolve for other reasons, even if you think this > > deserves consideration - which I don't - it's a miniscule factor in the > > overall scheme of AS/AV solutions. > It is in spamassassin and others, Along with hundreds of other tests, rules, criteria, etc. etc. > not sure the word miniscule "apply" here. You're right - I was being overly generous by calling it minescule. Of no real consequence would be a lot closer to the mark. > Furthermore anything that weakens anti-spam measure should not be encouraged by > a body like IETF, which wants to increase the security of the Internet. Sorry, that's nothing short of absurd. There are a myriad of antispam mechanisms in play - so many that pretty much every action we take in regards to email is going to have some impact somewhere. Just to point out the elephant in the corner here, it's obvious that increased use of end-to-end security is likely to have a seriously detrimental impact on various antispam measures. Does this translate to such work being off the table for the IETF. Clearly not. > > > > > The same functionality can be achieved with > > > > > example.com "v=SPF1 -all" > > > *.example.com "v=SPF1 -all" > > > > It's not even remotely the same functionality. The point of the nullmx > > mechanism is to inform agents *sending* messages to the domain that there's > > no point in even bothering making a connection. To the best of my knowlege > > nobody looks at SPF records for domain before attempting to send mail to > > them. > Well, in another RFC, every domain should have an abuse@ and postmaster@ this > domain. This seems in conflict. Others have pointed out that those other RFCs only apply to domains that actually run mail servers. > > > > > Which would cover also any subdomain and will not have different > > > interpretation while being deployed. > > > > If you're seriously proposing that SMTP clients start looking at SPF records, > > that a MAJOR change that would be a major PITA to get deployed. > > > same as implementing this, it is a NS record lookup and special processing. Incorrect. This is an added check of the result from the MX lookup that's already being performed by every SMTP client out there. No additional lookups are required. Ned From nobody Tue Feb 25 07:06:44 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72BE1A014F for ; Mon, 24 Feb 2014 07:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCRK_5ijONyt for ; Mon, 24 Feb 2014 07:48:51 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.10.7]) by ietfa.amsl.com (Postfix) with ESMTP id 934B11A0140 for ; Mon, 24 Feb 2014 07:48:51 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id CC0159D4438F1; Mon, 24 Feb 2014 09:48:50 -0600 (CST) Received: from colorado.websitewelcome.com (colorado.websitewelcome.com [192.185.82.155]) by gateway09.websitewelcome.com (Postfix) with ESMTP id B67B89D4438B7 for ; Mon, 24 Feb 2014 09:48:50 -0600 (CST) Received: from [70.113.58.209] (port=64597 helo=[192.168.200.35]) by colorado.websitewelcome.com with esmtpa (Exim 4.80.1) (envelope-from ) id 1WHxly-0005Qh-DS; Mon, 24 Feb 2014 09:48:50 -0600 Message-ID: <530B69DC.6090105@paulgrosso.name> Date: Mon, 24 Feb 2014 09:48:44 -0600 From: Paul Grosso User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: superuser@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - colorado.websitewelcome.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - paulgrosso.name X-BWhitelist: no X-Source-IP: 70.113.58.209 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.200.35]) [70.113.58.209]:64597 X-Source-Auth: paul+paulgrosso.name X-Email-Count: 2 X-Source-Cap: cGF1bGdyb3M7Y2xlYXJsaWc7Y29sb3JhZG8ud2Vic2l0ZXdlbGNvbWUuY29t Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/4cBLCrFt9Hxxx8V5V_0bDOufbOo X-Mailman-Approved-At: Tue, 25 Feb 2014 07:06:41 -0800 Cc: core , apps-discuss@ietf.org Subject: [apps-discuss] Comment in support of appsawg-xml-mediatypes-07 aka 3023-bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 15:48:53 -0000 Dear IETF, The W3C XML Core Working Group has continued to follow the progress of 3023-bis since our last comment of support sent November 14th. We have reviewed the 2014 February 6 draft at http://www.ietf.org/id/draft-ietf-appsawg-xml-mediatypes-07.txt and would like to support its transition to RFC. Our Working Group members have made several comments on earlier drafts as well as reviewed the comments and dispositions of others as evidenced by http://www.w3.org/XML/2012/10/3023bis/02-comments.html and http://www.w3.org/XML/2012/10/3023bis/06-comments.html and various emails archived in our groups mailing list at http://lists.w3.org/Archives/Public/public-xml-core-wg/2013Sep/0010 and http://lists.w3.org/Archives/Public/public-xml-core-wg/2013Sep/0019 and various other threads. We look forward to having an updated replacement to RFC 3023. Paul Grosso, co-chair for the W3C XML Core Working Group From nobody Tue Feb 25 11:30:54 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE21A01F4 for ; Tue, 25 Feb 2014 11:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.301 X-Spam-Level: X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMbqD6JwD47x for ; Tue, 25 Feb 2014 11:30:45 -0800 (PST) Received: from ntbbs.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0CE1A0186 for ; Tue, 25 Feb 2014 11:30:44 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3557; t=1393356641; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NrH9xdtN2FE9j8SFlpWKDBRfF8A=; b=YforfkeDkbPgoKQcFv5z GCPcjdYFC2by9esDPOTqh3QqLFbglHHVfvL18z+CALitILt1Uh7z1xPzy+PtMPEo X/gnKhaCVaDGfk+CJ0DyO0vj46b6yLAx2pcsKiM4F5StCHDI7FMzJWKPvfK0x08P uXAWe+GjaJNDvFc1rp4q+Hs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 25 Feb 2014 14:30:41 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2639101525.17582.5924; Tue, 25 Feb 2014 14:30:40 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3557; t=1393356004; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2rWr4Gs W3GE6NJloZxccdR5XxyQWOyVL95oRVfYOpM0=; b=s7uZ+yCh/vjXRAGfOzx3kt+ uX4R4j25qpD0VIvum6EYwTef0zKOpcIsSM9A1P8BHBcasCGkJRKdIMw9sj/xRtkf lfHyqIu++bG5jcpWFtPJ9FE6jGak9QgnMVBr4fSjHnxHnsRspszxkc9EOaxqHA1o E3TxR+kTIFlzeTdMTfA4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 25 Feb 2014 14:20:04 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2085383303.9.6580; Tue, 25 Feb 2014 14:20:03 -0500 Message-ID: <530CEF60.5020409@isdg.net> Date: Tue, 25 Feb 2014 14:30:40 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, "Murray S. Kucherawy" References: <20140215090319.9948.37708.idtracker@ietfa.amsl.com> <530561F9.6070205@dcrocker.net> <53060AAD.6010601@dcrocker.net> <53076630.2080306@dcrocker.net> <5307AFC7.6070103@dcrocker.net> In-Reply-To: <5307AFC7.6070103@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zVKrst8KKHCSKlrJKq18Z5QM1m4 Cc: draft-ietf-appsawg-nullmx.all@tools.ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2014 19:30:51 -0000 At the end of the day, this is a proposed optimization and enhancement to the MX record protocol handling logic. On the publishing side, it can ultimately change/add new protocol rules and guidelines: - Mail Domains MUST have MX preference non-zero values (PREF != 0) - Non-Mail Domains SHOULD have MX preference zero values (PREF == 0) For PREF!=0, the MUST is best to avoid NULL MX compliant systems skipping mail deliveries. If we allow a SHOULD, then the domain is open to false positive mail non-deliveries. For PREF==0, a SHOULD allows the outbound mail framework to decide how to best handle the mail delivery; a) by supporting this NULL MX proposal which will short circuit the delivery attempt and/or b) supporting the "Status Quo" of continuing to attempt to connect to what is probably a non-existing server. A domain declaring a MX with PREF == 0 could be declaring to the mail client world to avoid connecting to this host, but this waste and redundancy overhead is absorb in modern systems and thus is a non-issue for the most part. In our system, the domain will be permanently blocked after all attempts have been exhausted. It takes operator intervention to remove this auto-pilot block -- a rare procedure. So while the idea sounds simple, it may not be a simple implementation nor simple deployment (turning it on for updates). But it is an optimization to the MX logic and should be described as such avoiding the highly subjective reasonings dealing with mail filtering, anti-spam, reputation, etc. -- HLS On 2/21/2014 2:57 PM, Dave Crocker wrote: > On 2/21/2014 10:43 AM, Murray S. Kucherawy wrote: >> On Fri, Feb 21, 2014 at 6:44 AM, Dave Crocker > > wrote: >> >> Except that 'authorized' is the essential point, to distinguish >> between >> legitimate uses and spoofing, etc. uses. The word 'legitimate' >> doesn't >> work well here. So 'authorized' seems the next closes. >> >> There are three essential problems with the original wording. >> The first >> is that domains don't 'send' mail. Also the word 'send' is frankly >> ambiguous in its own right here. And lastly is that the >> stricture needs >> to cover keep the domain name out of a number of different fields. >> >> >> My problem is that "SHOULD NOT be authorized for use" is a concept that >> exists entirely inside the ADMD creating the content; it points to >> something that's not subject to interoperability. "SHOULD NOT be >> used", >> by contrast, is something that a receiver can evaluate. > > We've all locked into some interesting linguistic challenges, though > they seem to be getting cast in terms of a kind of email protocol > challenge. > > To start: I'm not trying to change any existing email standards and > don't think the current topic will do that., > > Rather, I'm trying to do two other things. One is to distinguish > between activities authorized by the domain owner, versus those > outside of the owner's control. And then to suggest proscription of > what the domain owner authorizes for use. > > Simply put: If one publishes a NULL MX for the name, one shouldn't > use that domain for an email address anywhere. (Tony's language was > good for that I think.) And I've no idea whether should or must > should be used -- and don't much care. > > But the linguistic wrinkle is that those nasty spoofers are sitting > out there, getting in the way of generic language like "should not be > used". > > d/ > > From nobody Tue Feb 25 12:39:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0A01A0796; Tue, 25 Feb 2014 12:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxjrNDdqs4tb; Tue, 25 Feb 2014 12:39:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C19E51A0789; Tue, 25 Feb 2014 12:39:35 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140225203935.10521.9570.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2014 12:39:35 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lUa65bhgHJtLqYw-1NyxT_TfxVM Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D ACTION:draft-ietf-appsawg-xml-mediatypes-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 20:39:39 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : XML Media Types Author(s) : H. Thompson, et al Filename : draft-ietf-appsawg-xml-mediatypes Pages : 32 Date : 2014-02-25 This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-xml-mediatypes-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-appsawg-xml-mediatypes"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-25123935.I-D@ietf.org> --NextPart-- From nobody Tue Feb 25 13:38:12 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56671A076D; Tue, 25 Feb 2014 13:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff5qunI1SoWe; Tue, 25 Feb 2014 13:38:02 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id E50261A06E8; Tue, 25 Feb 2014 13:38:01 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id s1PLbrrC018572; Tue, 25 Feb 2014 21:37:57 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1PLbpM3006989; Tue, 25 Feb 2014 21:37:51 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id s1PLbqkn014103; Tue, 25 Feb 2014 21:37:52 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s1PLbqOK014099; Tue, 25 Feb 2014 21:37:52 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Internet-Drafts@ietf.org References: <20140225203935.10521.9570.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 25 Feb 2014 21:37:52 +0000 In-Reply-To: <20140225203935.10521.9570.idtracker@ietfa.amsl.com> (Internet-Drafts@ietf.org's message of "Tue\, 25 Feb 2014 12\:39\:35 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/wY3JQlf4c4lKsWXCfhCHiwtWhDY Cc: apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D ACTION:draft-ietf-appsawg-xml-mediatypes-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2014 21:38:05 -0000 Internet-Drafts writes: > A new Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area > Working Group Working Group of the IETF. > > Title : XML Media Types > Author(s) : H. Thompson, et al > Filename : draft-ietf-appsawg-xml-mediatypes This draft has no substantive changes, but a number of wording improvements thanks to feedback received. Two subsections formerly in section 8, The '+xml' Naming Convention, have been moved to section 10, IANA Considerations, ditto. As in the past, a disposition of comments document for all comments received on draft -07 is available at http://www.w3.org/XML/2012/10/3023bis/07-comments.html and an editors' diff (better than the automatic one) is at http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-08_diff.html Time to declare victory and move on? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Wed Feb 26 12:28:14 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1F91A01B3 for ; Wed, 26 Feb 2014 12:28:09 -0800 (PST) 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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-KdrE4tDn1k for ; Wed, 26 Feb 2014 12:28:03 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D78091A00D7 for ; Wed, 26 Feb 2014 12:28:03 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4BCE34010C; Wed, 26 Feb 2014 13:28:02 -0700 (MST) Message-ID: <530E4E51.2020205@stpeter.im> Date: Wed, 26 Feb 2014 13:28:01 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/rRxTPz5te6_fPdJxLXWJaKOBmAk Subject: [apps-discuss] JCARDCAL WG summary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 20:28:10 -0000 Here is a status report on the JCARDCAL WG. The group is not meeting in London (and in fact has never met face-to-face). It is chartered to work on JSON representations of vCard and iCalendar data, i.e.: - draft-ietf-jcardcal-jcard (now RFC 7095) - draft-ietf-jcardcal-jcal (submitted to the IESG, on the telechat agenda for March 20) Once draft-ietf-jcardcal-jcal is published as an RFC, the WG will declare success and shut down. Peter -- Peter Saint-Andre https://stpeter.im/ From nobody Wed Feb 26 13:20:31 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F3C1A0732 for ; Wed, 26 Feb 2014 13:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QccchNXFFQjG for ; Wed, 26 Feb 2014 13:20:20 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 487AC1A06BC for ; Wed, 26 Feb 2014 13:20:20 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id q108so2976934qgd.10 for ; Wed, 26 Feb 2014 13:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=1E6yrisiTiPcE+fpuEkLntlHL87OVjHqvBrmnsPeV28=; b=LNMGR1XU+qz3N00ZBQ9mDFdAYpAytKCJ4SABIZJWoNskffyJTCDJId8S25hAuo1Ulp PkgxlUtGe7UwQoy7wWtE5O2aZxA6lEuxN/9dUDyf5UxXr/j2+HViu3PyBLl+kKCvkDyF ofz22Tv20DrmtANj5I/EgL+fnqqAL1i49Sn+zMWkVCmP1hPhCfYnPWRq/ky5Pnrif2bd vEv/HBpx2hKwVmHDnnNH16AxZRKJPgtGJt0Di4NIMOHxOcKRJk1SlrRLpx51Rl5AUWjr 8lAyQBFD7OX089sFBBLA3PB/sr2KhOEG83uycKKhFVqPEOSIFzNyp9t7+6qAXc28gU+G H2oQ== MIME-Version: 1.0 X-Received: by 10.140.102.167 with SMTP id w36mr2197183qge.109.1393449618776; Wed, 26 Feb 2014 13:20:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.26.11 with HTTP; Wed, 26 Feb 2014 13:20:18 -0800 (PST) Date: Wed, 26 Feb 2014 13:20:18 -0800 X-Google-Sender-Auth: l5gOB5ipSLSdC6kwAdQir68KQ8c Message-ID: From: Applications Area Directors To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/2Sy0rqaBKWHx_ClkuAthct3v1H4 Subject: [apps-discuss] Working group summaries you'll start seeing X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2014 21:20:21 -0000 The App ADs have asked the chairs to post summaries of working group status (for WGs that are not meeting in London) and working group sessions (for WGs that are meeting) between now and the end of the London meeting. Peter has posted the first of those summaries, about jcardcal; thanks. You'll all be seeing the rest of the summaries during this week and next. Off-list feedback about whether these summaries are useful to you is welcome. Barry and Pete From nobody Wed Feb 26 17:31:03 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3DF1A07A0 for ; Wed, 26 Feb 2014 17:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lGPNg9Z-ykd for ; Wed, 26 Feb 2014 17:30:54 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E86CB1A0792 for ; Wed, 26 Feb 2014 17:30:53 -0800 (PST) Received: from crankycanuck.ca (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 656798A031 for ; Thu, 27 Feb 2014 01:30:51 +0000 (UTC) Date: Wed, 26 Feb 2014 20:30:49 -0500 From: ajs@anvilwalrusden.com To: apps-discuss@ietf.org Message-ID: <20140227013049.GE1231@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/7AbVHsItod9tutkV6kIVXdusB70 Subject: [apps-discuss] WG Summary: SPFbis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2014 01:30:55 -0000 Dear Colleagues, The SPFbis WG will not meet at IETF 89. The Sender Policy Framework (SPF) specification (draft-ietf-spfbis-4408bis) has been sent to the RFC Editor. This is the only document the working group is working on. We think once this document is published, we'll be ready to close. Best regards, SM & Andrew (SPFBIS Chairs) From nobody Wed Feb 26 23:15:32 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977C51A07C1 for ; Wed, 26 Feb 2014 23:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFHn9g20y4eE for ; Wed, 26 Feb 2014 23:15:25 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3100E1A079D for ; Wed, 26 Feb 2014 23:15:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=650; q=dns/txt; s=iport; t=1393485324; x=1394694924; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=396WHqHIH+vq90UgBkcbyIHYCX1Hoz9KBs8RCJgjgU4=; b=h6PY/3nL5t8eIqp0m0XkvHta13NOMkDZI1B1BDfr3NRK2cI8qpWy8Gyr WoZtEJvx4u8CljCWW88wauhE9OQkXkFs0ey6Lsj5HNf041KRfkjitWKTp 8rPDXFFqaUuL9yYEkcuaVmgIM2lwzbObMzvAUzJXRHBeXxbDMBH7lp0AK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFABTlDlOQ/khN/2dsb2JhbABagwaEFb4FgRUWdIJPVQE1AgUWCwILAwIBAgErIA0BBwEBh3WpFqEKF4EpjSuCdYFJAQOYOJIpgy47gS4k X-IronPort-AV: E=Sophos;i="4.97,552,1389744000"; d="scan'208";a="5616806" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 27 Feb 2014 07:15:23 +0000 Received: from mctiny.local ([10.61.170.83]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1R7FL1q005393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 07:15:22 GMT Message-ID: <530EE609.8030206@cisco.com> Date: Thu, 27 Feb 2014 08:15:21 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/zG1Gz1v1DV_qGMJgUKg7uM6oUsQ Subject: [apps-discuss] WG summary: qresync X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2014 07:15:29 -0000 Dear Colleagues, This is a status report for the qresync working group. The working group was chartered to update & obsolete RFCs 4551 and 5162. Discussion and development took place on the imapext list. This work has been completed and draft-ietf-qresync-rfc5162bis-10 now resides in the RFC-Editor queue. The group will go dormant until an RFC pops out, at which point we expect to conclude, having never met in person. Thanks and congratulations to co-authors Alexey Melnikov and Dave Cridland who also co-chaired the group, as well as the participants of the working group who validated the changes. Eliot co-chair qresync From nobody Thu Feb 27 00:54:58 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F74A1A0059 for ; Thu, 27 Feb 2014 00:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Mvo831i4Bb for ; Thu, 27 Feb 2014 00:54:55 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 82ADA1A0075 for ; Thu, 27 Feb 2014 00:54:54 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-db-530efd5bf13e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 56.D7.04853.B5DFE035; Thu, 27 Feb 2014 09:54:52 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 09:54:51 +0100 From: Salvatore Loreto To: Applications Area Directors , Apps Discuss Thread-Topic: HyBi wg summary Thread-Index: AQHPM5mTEi8b6pdBkUWtpAgJFAB6bA== Date: Thu, 27 Feb 2014 08:54:50 +0000 Message-ID: <7318AD87-CE2E-4B70-8E61-7B0CA3D0F105@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <07AA9406ADAB6F4EBAA8618290CBBC04@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW7MX75gg2WnuCx6H6xmsVj9cgWb A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXxp1mjoI2n4vWq8gbGe5xdjJwcEgImEt0z e1kgbDGJC/fWs3UxcnEICZxglFjw5xYThLOEUeLlpL+MIFVsAmYSzx9uYQaxRQQSJCY+2sYO YgsLSEjsff+LHSIuK3Hl1wZGCFtPouf/SyCbg4NFQFXie3cZSJhXwF5iyq9drCC2kECAxPmH 68BsToFAiQOXtoHZjEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0ksuv0Z ql5HYsHuT2wQtrXE7vMzoOLaEssWvmaGuEFQ4uTMJywTGMVmIVkxC0n7LCTts5C0z0LSvoCR dRWjZHFqcXFuupGBXm56bolealFmcnFxfp5eceomRmBsHdzy22gH48k99ocYpTlYlMR5r7PW BAkJpCeWpGanphakFsUXleakFh9iZOLglGpgbN0+f5/ErQSn9e57Sli+xXJoBXLc1JX8wav3 Y8VjZQmFny8eLy7gMD9510G8oCxMzutf7pxbCgIPFl3WlX7D46gsvy5Cs3nj/fvs4SI5p/mW ZkWyeLnG3mhPjz7dqPWlceMz1dwZT1jOMC/Qs2ZIUJh2oUgnbIrvmUqmP+8W5Pyf5LX0Zzmv EktxRqKhFnNRcSIAK5ZmNXsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/fceGZvND90qDHpTz9plDNWhsn1c Subject: [apps-discuss] HyBi wg summary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2014 08:54:56 -0000 HyBi wg is not meeting in London. There is consensus on not stop the mux extension work within the HyBi wg and instead move the discussion in the httpbis wg=20 to define how WebSocket semantic fits in the HTTP2 framing level and then make advantage of the HTTP2 mux. There is an ongoing mail discussion in httpbis mailing list about WebSocket and a scheduled discussion in London=20 The only draft still pending in the wg is the draft-ietf-hybi-permessage-co= mpression the chair have to review it and eventually send to the IESG if the HTTPbis wg agrees to take on the WebSocket evolution (i.e. WebSocket= over HTTP2), and I hope it will, then after we finalise the work on draft-ietf-hybi-permessage-compression the wg can be closed IMO br Salvatore On Feb 26, 2014, at 11:20 PM, Applications Area Directors wrote: > The App ADs have asked the chairs to post summaries of working group > status (for WGs that are not meeting in London) and working group > sessions (for WGs that are meeting) between now and the end of the > London meeting. Peter has posted the first of those summaries, about > jcardcal; thanks. You'll all be seeing the rest of the summaries > during this week and next. >=20 > Off-list feedback about whether these summaries are useful to you is welc= ome. >=20 > Barry and Pete >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Feb 27 12:02:46 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B781A064C for ; Thu, 27 Feb 2014 12:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svin159l81F5 for ; Thu, 27 Feb 2014 12:02:42 -0800 (PST) Received: from snt0-omc3-s3.snt0.hotmail.com (snt0-omc3-s3.snt0.hotmail.com [65.55.90.142]) by ietfa.amsl.com (Postfix) with ESMTP id 96D301A0552 for ; Thu, 27 Feb 2014 12:02:42 -0800 (PST) Received: from SNT146-W21 ([65.55.90.136]) by snt0-omc3-s3.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Feb 2014 12:02:41 -0800 X-TMN: [b0jK94b2i0qIjicNs0iqEggwz14nQnFI] X-Originating-Email: [xml4ietf@live.com] Message-ID: Content-Type: multipart/alternative; boundary="_7b3880ee-0719-46e2-b8df-2d9ce4e725cf_" From: Brian Aberle To: "apps-discuss@ietf.org" Date: Thu, 27 Feb 2014 13:02:40 -0700 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2014 20:02:41.0105 (UTC) FILETIME=[DEDD4C10:01CF33F6] Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/GvsAbNe3btZSX5X91VEznqfIraA Subject: [apps-discuss] RFC for XMLObject Parsing X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2014 20:02:45 -0000 --_7b3880ee-0719-46e2-b8df-2d9ce4e725cf_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello World=2C I am seeking community feedback regarding an official alternative to SAX an= d DOM. I have put together several examples that show performance numbers = which alone justify this alternative to SAX or DOM. There are other reason= s as well=2C primarily - the argument for "Object Oriented Design" in the a= pplication layer. This issue in discussion here before the community is: D= o we want an RFC for this? Maybe not. Maybe so. We don't all want to kee= p inventing the wheel. The concept is simple. It is "XML Serialization".X= MLObject Parsing? We don't need to invent new words=2C but we must also no= te that "Serialization" includes neither Keyed XML Updates nor Object Insta= nce Reference counting. We also don't need fancy things that we just don't= need=2C however I have prepared an example using CORBA that does need this= (and we needed it on the $2B NCIS project). This concept was identified qu= ickly by Bjarne Stroustrup in this thread: http://www.artima.com/forums/fl= at.jsp?forum=3D226&thread=3D204721Today that thread has: 20 replies on = 2 pages. Most recent reply: Feb 12=2C 2010 12:43 AM by = Brian Aberle =20 I recommend that this thread be continuation from that one=2C where we reso= lve to solve an identified need (for and RFC?) That is the question. I hav= e prepared a rough and rogue draft on this concept http://www.codeproject.c= om/Articles/37850/XMLFoundation-2 I have received much valuable feedback in= the public forum at the bottom of that article over the past decade++=3B = The roughness of the draft HTML doc describing this stuff=2C should not ref= lect on the polished and refined all encompassing open source implementatio= n.I had developed/co-developed 2 XML Parsers prior to the finalization of X= ML 1.0. That is rather simple stuff in terms of implementation - fact back= ed by the "Yet Another" factor in available XML Parsers. "XML Serializatio= n" is perhaps slightly more complex in implementation. We need to use the = new word "XML Object Parsing" or perhaps "XML Serialization++" to describe = the even more complex implementation which addresses the needs raised in th= e above two public threads over the past decade.Since the very purpose of I= ETF is designed to prevent us all from re-inventing the wheel when we colle= ctively can identify a need for it=2C (each of us would create our own cool= version no doubt) but collectively we would roll nowhere that way - Should= we have an RFC for this? That is the question. =20 World=2C what do you think?=20 = --_7b3880ee-0719-46e2-b8df-2d9ce4e725cf_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
He= llo World=2C

=

I am seeking community= feedback regarding an official alternative to SAX and DOM. =3B I have = put together several examples that show performance numbers which alone jus= tify =3Bthis alternative to SAX or DOM. =3B There are other reasons= as well=2C primarily =3B- the argument for "Object Oriented Design" in=  =3Bthe application layer. =3B This issue in discussion here = =3Bbefore the community is: Do we want an RFC for this? =3B Maybe not.&= nbsp=3B Maybe so. =3B We don't all want to keep inventing the wheel.&nb= sp=3B The concept is simple. =3B It is "XML Serialization".

XMLObject Parsing? =3B We don't need t= o invent new words=2C but we must also note that "Serialization" =3Binc= ludes neither =3BKeyed =3BXML Updates nor Object Instance Reference= counting. =3B We also don't need fancy things that we just don't = =3Bneed=2C =3Bhowever I have prepared an example using CORBA that does = need this(and we needed it on the $2B NCIS project). =3B This =3Bco= ncept was identified quickly by Bjarne Stroustrup in this thread: =3B <= /font><= /font>http://www.artima.com/forums/flat.jsp?forum=3D226&=3Bthread=3D204721<= /a>

= Today<= /a> that thread has: = 20 replies on 2 pages. Mo= st recent reply: Feb 12=2C 2= 010 12:43 AM by <= font color=3D"#0068cf" face=3D"Tahoma" size=3D"2">Brian Aberle =3B =3B =3B

I recommend =3Bthat =3Bthis threa= d =3Bbe continuation from that one=2C where we resolve to solve an iden= tified need (for and RFC?) =3B That is the question. I have prepared a = rough and rogue draft on this concept =3Bhttp://www.codeproject.com/Articles/37850/XM= LFoundation-2 =3BI have received much valuable feedback in the public fo= rum at the bottom of that article over the past decade++=3B =3B The rou= ghness of the draft HTML doc describing this stuff=2C should not reflect on= the polished and refined all encompassing open source implementation.

I had developed/co-developed 2 XML = Parsers prior to the finalization of XML 1.0. =3B That is rather simple= stuff in terms of implementation - fact =3Bbacked by the "Yet Another"= factor in available XML Parsers. =3B "XML Serialization" is perhaps&nb= sp=3Bslightly more complex in implementation. =3B =3BWe need to use= the new word "XML Object Parsing" or perhaps "XML Serialization++" to desc= ribe the =3Beven more complex implementation =3Bwhich addresses the= needs raised in =3Bthe above two public threads over the past decade.<= /font>

Since the very purpose of = =3BIETF is designed to prevent us all from re-inventing the wheel when we c= ollectively can identify a need for it=2C (each =3Bof us would =3Bc= reate our own cool version no doubt) but collectively we would =3Broll = nowhere that way - Should we have an RFC for this? =3B That is the ques= tion.
 =3B
World=2C what do you think?

 =3B
=
= --_7b3880ee-0719-46e2-b8df-2d9ce4e725cf_-- From nobody Thu Feb 27 16:17:45 2014 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F601A016E for ; Thu, 27 Feb 2014 16:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejtTvFbklbAm for ; Thu, 27 Feb 2014 16:17:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 577101A01BC for ; Thu, 27 Feb 2014 16:17:37 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB597.namprd03.prod.outlook.com (10.255.93.37) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 28 Feb 2014 00:17:33 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Fri, 28 Feb 2014 00:17:33 +0000 From: Dave Thaler To: "apps-discuss@ietf.org" Thread-Topic: New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt Thread-Index: AQHPKcEaJNqgQQL1fEW4nlD27YvlO5q1S01ggAAFZJCAFI1XEA== Date: Fri, 28 Feb 2014 00:17:33 +0000 Message-ID: <39eeb93d9b7b439a86efc735bf04ebc8@BY2PR03MB412.namprd03.prod.outlook.com> References: <20140214201230.23637.87657.idtracker@ietfa.amsl.com> <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: <6485d2fdca9a447784465263cdcf8d32@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.108.71.45] x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(63696002)(69226001)(79102001)(47446002)(74662001)(81542001)(59766001)(77982001)(31966008)(74502001)(87266001)(2656002)(81342001)(19273905006)(74876001)(76796001)(76576001)(15975445006)(87936001)(81816001)(95416001)(15202345003)(95666003)(4396001)(33646001)(74366001)(46102001)(53806001)(575784001)(86362001)(54356001)(92566001)(51856001)(93136001)(93516002)(54316002)(56776001)(76482001)(74706001)(94316002)(74316001)(90146001)(47736001)(49866001)(561944002)(19580395003)(83322001)(80976001)(94946001)(81686001)(47976001)(50986001)(66066001)(83072002)(80022001)(15395725003)(65816001)(85852003)(85306002)(24736002)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB597; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:199.108.71.45; FPR:B056F676.89DE93D9.69D6D584.87ECE57D.201EF; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/bQpo4-whMrzq3Pw1AKf2wu4f9Pw Subject: Re: [apps-discuss] New Version Notification for draft-thaler-appsawg-uri-scheme-reg-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2014 00:17:41 -0000 > 4) As noted in my presentation at last IETF and=20 > draft-thaler-uri-scheme-reg- ps-01, RFC 4395's convention for private=20 > namespaces (converting "." to "-" in scheme names based on a domain=20 > name) causes conflicts. Updated example to use "." instead of "-" > to reduce collisions. And open ticket #17 covers the rest of the=20 > conflict problem. I just went through the site http://appurl.org/docs/quickstart=20 which Mike Amundsen pointed to last August in https://mailarchive.ietf.org/arch/msg/apps-discuss/SZ_s1HYoTWZTBiX0CeYOnNqM= lfo It says: > AppURL recommends you use your website's (sub)domain as your scheme. > For example, we picked grid6.us as the URL scheme for our Grid6=20 > example app, because that's where its website lives. So this directly conflicts with the RFC 4395 guidance to use a *reversed*=20 domain name, and just reinforces that the problem is even worse than=20 stated in the problem statement document. I see Larry recommended they get their proposal reviewed by the apps area (http://lists.w3.org/Archives/Public/www-tag/2013Aug/0026.html) but the bad guidance on their page hasn't changed. -Dave