From nobody Wed Aug 2 10:18:54 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53117131C28; Wed, 2 Aug 2017 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net 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 L9Y_wxYOZNyt; Wed, 2 Aug 2017 10:18:51 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944CC131C25; Wed, 2 Aug 2017 10:18:51 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v72HJFHJ015102 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Aug 2017 10:19:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1501694356; bh=zoFDscr9ZEJE6umnUXSaVno7QEThL9qMd5tc3pGub7A=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=Sy6mY6k2Dmyg4zIUZ2AtY96TfUNN4irgYAwpaJkoc8ZmhvLGFPaavVb+D0DKfJm4U 5FQTI5JLEIzYZ2SxP5ictG3Rd/fUzoHOld5pZkRgKVNfSOo9+tor85Vk8CkKnOpibr JuvJ14d11kffaSpH24D5kxcn1wQLZ4BG5+UtKhmI= To: art@ietf.org Cc: tjw ietf , "dnsop-chairs@ietf.org" References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> From: Dave Crocker Organization: Brandenburg InternetWorking Reply-To: dcrocker@bbiw.net Message-ID: <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> Date: Wed, 2 Aug 2017 10:18:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 17:18:52 -0000 On 7/28/2017 8:54 AM, Adam Roach wrote: > The document is pretty clear about its intended scope, containing > statements like: > >> Only the right-most names are registered in the IANA Underscore table > > and > >> The current definition of a global underscore registry attends only to >> the "upper-level" names used for these RRs, that is the "_proto" names. > > But then the table includes things like "_ldap" and "_certificates". The > only SRV records for (e.g.) LDAP will look like "_ldap._tcp...", which > (according Howdy. (Posting this on ART, since that's got the active thread on attrleaf, for the moment.) Thanks for the thoughtful comments on the draft. I've been mulling over the challenges of this registration topic for more than a decade, constantly being hoisted on the petard of established practice... First, underscores can be used for multiple levels of node name. Trying to deal with that fully, in a single spec produced an especially confused draft, roughly 10 years ago. More recently it became clear that this is best handled by the described simplification the spec now declares -- essentially distinguishing between 'top-level' underscore names and separately deal with those below. But, as you note, this is not fully or adequately implemented in the latest versions of the draft. But I'll leave details about further fixes for that, for the moment, because... Second, and much worse, is that the original documentation of underscore use created an inherently-problematic arrangement: Attempting to synthesize some of the registration by incorporating entries in independent registration tables documented in SRV and URI specifications. The semantics therefore would mean there would be more than one 'authority' for name registration. This is a registration model designed to produce collisions. Efforts have been to retrofit an administrative model that accommodated this, where the idea of real-time conflict detection and resolution -- by infinitely diligent and perfectly perceptive -- IANA staff is one of the more recent suggestions. Unfortunately, there is an essential and practical difference between 'excellent' and 'perfect', where the latter is an inappropriate goal for human performance. I've come to the conclusion that "accommodating" the established registration practices is a fundamentally wrong path. The only way to solve a problem of multiple registration authorities is to create a single registration authority. That is, the right path is to create a simple and obvious registration model, and, separately, go back and fix the problematic documents. Therefore I propose to: 1. Have this document define the simple, sole, authoritative mechanism for registering "top-level" (global scope) underscore names. 2. Create a separate document that specifies modifications to the SRV and URI documents, rationalizing the use of underscore names, through the mechanism defined in -attrleaf-. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 2 17:35:55 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577AB127601 for ; Wed, 2 Aug 2017 17:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BHdVx0YrTtMP for ; Wed, 2 Aug 2017 17:35:51 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF904126C7A for ; Wed, 2 Aug 2017 17:35:50 -0700 (PDT) Received: (qmail 55740 invoked from network); 3 Aug 2017 00:35:48 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Aug 2017 00:35:48 -0000 Date: 3 Aug 2017 00:35:26 -0000 Message-ID: <20170803003526.2349.qmail@ary.lan> From: "John Levine" To: art@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 00:35:52 -0000 In article <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> you write: > 2. Create a separate document that specifies modifications to the >SRV and URI documents, rationalizing the use of underscore names, >through the mechanism defined in -attrleaf-. It seems a bit late to change SRV. Or would you only adjust the documentation to match observed reality? For URI, it points at other RFCs to get the protocol/service and enumservice names. Are you proposing to change URI to add an extra level of name, or do you want to reach through and change the enumservice RFCs too? R's, John From nobody Wed Aug 2 17:42:34 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EDE129AEB for ; Wed, 2 Aug 2017 17:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbiw.net 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 5XdFdBkikMlK for ; Wed, 2 Aug 2017 17:42:32 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AE31287A5 for ; Wed, 2 Aug 2017 17:42:32 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v730gv7j013397 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Aug 2017 17:42:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1501720978; bh=P2JjrTexaIFrddZUsb0cko1EwgGnMG4uI+D5ornNKc0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gOxo2Mdby1YbLeVGABz9FPvj+nU3k4m4ngFXfXlC4QJJ+sxFhA4qPvmF4H/Aoww2P DiZyUUrAmoIaMS92FheDVpbd9FTEWG6HvCkIPC62cvniheWM03xcCtNhnFDVZXOhRi st9fChm7PikQlb7vA93KXN4nASx2vgccWLzWLyKQ= To: John Levine , art@ietf.org References: <20170803003526.2349.qmail@ary.lan> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> Date: Wed, 2 Aug 2017 17:42:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170803003526.2349.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 00:42:33 -0000 On 8/2/2017 5:35 PM, John Levine wrote: > In article <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> you write: >> 2. Create a separate document that specifies modifications to the >> SRV and URI documents, rationalizing the use of underscore names, >> through the mechanism defined in -attrleaf-. > > It seems a bit late to change SRV. Or would you only adjust the > documentation to match observed reality? The latter. The change is to the registration process, not to SRV, per se. That is, take a snapshot of the existing SRV underscore usage and re-specify it in terms of an underscore registry, rather than in terms of an inheritance from another registry. > For URI, it points at other RFCs to get the protocol/service and > enumservice names. Are you proposing to change URI to add an > extra level of name, or do you want to reach through and change > the enumservice RFCs too? Same approach as for SRV. Shift to use the underscore registry. My understanding is that URI has little adoption, so even if the result is some usage changes, that might not be intolerable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 2 17:46:58 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808C21287A5 for ; Wed, 2 Aug 2017 17:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=tX8V7xPG; dkim=pass (1536-bit key) header.d=taugh.com header.b=Wr7a7jkS 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 Lkyxq6sRQzuY for ; Wed, 2 Aug 2017 17:46:56 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111C31275FD for ; Wed, 2 Aug 2017 17:46:55 -0700 (PDT) Received: (qmail 58214 invoked from network); 3 Aug 2017 00:46:54 -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; s=e363.5982727e.k1707; bh=Y8j5MBM1k6NE40W4ID0emE2xJxZogt6urYEP0notn/s=; b=tX8V7xPGMudjSGNfOxjOr0UwML0jkujq8nlmxK0VomL4BUwzF/SwnDya2CjLaVKWr/oELWY9VN7TYG0lHtitMEICa23OTaF0FO3ZBdgn2WAbQHBjOrdG2feFa8K0PmWCqAcXU+4qNgIMGs+qGXGnruoe8/+yUKTHzxOYHVjuUq7Ra797Ew14w5QaJltIOnq13RhMYXIClQTKzldrBYKj21Z4RWrO5QIBDYLbxYeX7bi7/MhvW8oco3wQk+0d16Rn 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; s=e363.5982727e.k1707; bh=Y8j5MBM1k6NE40W4ID0emE2xJxZogt6urYEP0notn/s=; b=Wr7a7jkSmqMXTSw1eliMCaxwpwJ3msIfVB90ub+7GOguzFB0a519sl14ThZcq6cElMpmD/quvjwg8A9pVlw30u++7zllyPQUR6qahlALlcgOvzOpSWdVhteVGPVyuRwIETCeNI6fVUYV4ZFM4C0vgJFo4JF/Zry0m8pMvrhuPKQDoJ+b5cqin4kA9L9MC1ote1FeGj72s6U6kKEGHIAgxPiTa1/k+qlTVUry1xnHtYtb4FHnj/MlO4EWlAqlaZLm Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 03 Aug 2017 00:46:54 -0000 Date: 2 Aug 2017 20:46:54 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" Cc: art@ietf.org In-Reply-To: <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 00:46:57 -0000 On Wed, 2 Aug 2017, Dave Crocker wrote: > Same approach as for SRV. Shift to use the underscore registry. My > understanding is that URI has little adoption, so even if the result is some > usage changes, that might not be intolerable. It is my impression that you can count the number of prtocols used in SRV records on the fingers of one hand, and the number of enumservice types that people actually use on the fingers of the other, so that's probably workable. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 3 01:47:39 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A341321F5 for ; Thu, 3 Aug 2017 01:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5dwvn04WCeRg for ; Thu, 3 Aug 2017 01:47:36 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB0A126CC4 for ; Thu, 3 Aug 2017 01:47:36 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d145so3881505qkc.2 for ; Thu, 03 Aug 2017 01:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2X/k+glyxkd6461QvNJ0z6XzBtKnq/+X+vjMJ8lsaB0=; b=RikErq2eu1O6jYUfiqDfR+NTZ+vZOBEp64DQVE7SMl60BmOer5TyNEVCjTuz+SYHzV P4QdqoEHoXzTUfd8KzqXsuTjCt1+1HnRLw04H0CzXhEKm+z2FG3sp4BT080W4oRG8/91 hNiZ+kYA5uqiEE7TC27dX3jBk4KqEQk7/0s6/vLYuwRTvo5Ui1VtKdFo3K57wNzorRPn tDvGtS54u7EfXCqqi2PGuz8avc0Ib1uhb9xfpRxZoaRQteSMWcxE0mEJ7JCM0V4EqxAO jk2HpCVABtoU5ZVrgWrUmsnXRqPdymTzWc7xa9aH+/evOOnm2Z+etRQ6k6iUc14EWtWY EBMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2X/k+glyxkd6461QvNJ0z6XzBtKnq/+X+vjMJ8lsaB0=; b=W7f84qkbKlF3z2HdRev4ceF9DHcC01UCk1tG3gS/dihf3887+mMfd7xjs39nH8tlOI 4tAF7IPAj9Esk+ggtkM4p9UhNIdH+x4RnOcL621OWSrY45b14BB6SntOtir4695nxm/b y3HbuNrPDSOFTu+eSO5LY5ZZ6Ds2VPBx4Q8HGDYDyCIjFk7OF27eA+fs8m/DEWlOVvmp b5LiBOHJm8rYF0WmT9AuVeoEt48fdOLxuXCLp7aC/6cwnFXr+947UnumspnLd5TicJih zMPZbbNWulzYokOgPOSRhPDrGg6sBzpDpN4KDLsWv5gAY5TLPQYr6Mb5W/b3BMfdKSBF 1dHQ== X-Gm-Message-State: AHYfb5iUhOwv6L7LNF7gEGg8gMoXPy0T9APjaVNPVsTilJ4Z69TPuMDv LTv3+l0DfeBzHFaffcKjvyiMLHk4a7JSFQ8= X-Received: by 10.55.164.7 with SMTP id n7mr1251761qke.343.1501750055118; Thu, 03 Aug 2017 01:47:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.58.200 with HTTP; Thu, 3 Aug 2017 01:47:34 -0700 (PDT) From: Herbert Van de Sompel Date: Thu, 3 Aug 2017 10:47:34 +0200 Message-ID: To: art@ietf.org Cc: Herbert Van de Sompel , Michael Nelson , Geoffrey Bilder , "John A. Kunze" , Simeon Warner Content-Type: multipart/alternative; boundary="94eb2c07583c93ad810555d56e4a" Archived-At: Subject: [art] "identifier" relation type X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 08:47:39 -0000 --94eb2c07583c93ad810555d56e4a Content-Type: text/plain; charset="UTF-8" hi all, Yesterday, I submitted the following I-D: "Identifier: A Link Relation to Convey a Preferred URI for Referencing" You can find it in the datatracker at: https://datatracker.ietf.org/doc/draft-vandesompel-identifier/ A pretty HTML version is at: http://signposting.org/identifier/spec/ The GitHub repository is at: https://github.com/hvdsomp/signposting This effort is related to the "Signposting the Scholarly Web" effort, see http://signposting.org/ Feedback is welcome. Greetings Herbert Van de Sompel -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ http://orcid.org/0000-0002-0715-6126 == --94eb2c07583c93ad810555d56e4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi all,=

Yesterday, I submitted the followin= g I-D:

"Identifier: A Link Relation to Convey a Preferred URI for Refer= encing"

You can find it in th= e datatracker at:


A pretty HTML v= ersion is at:

=

The GitHub repository is at:

<= a href=3D"https://github.com/hvdsomp/signposting">https://github.com/hvdsom= p/signposting

This effort is related to th= e "Signposting the Scholarly Web" effort, see http://signposting.org/

Feedb= ack is welcome.

Greetings

Herbert Van de Sompel


--
Herbert Van de Sompel
Digital Library Research &= ; Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl= .gov/herbertv/
http://orcid.org/0000-0002-0715-6126

=3D=3D
--94eb2c07583c93ad810555d56e4a-- From nobody Thu Aug 3 15:21:48 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA57131CB5; Thu, 3 Aug 2017 15:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 zeAJiP3YYakD; Thu, 3 Aug 2017 15:21:45 -0700 (PDT) Received: from mail1.g15.pair.com (mail1.g15.pair.com [66.39.65.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B6812711E; Thu, 3 Aug 2017 15:21:45 -0700 (PDT) Received: from mail1.g15.pair.com (localhost [127.0.0.1]) by mail1.g15.pair.com (Postfix) with ESMTP id 9A7DDBDD59; Thu, 3 Aug 2017 18:21:44 -0400 (EDT) Received: from [192.168.90.152] (209-6-217-99.s353.c3-0.smr-ubr1.sbo-smr.ma.cable.rcncustomer.com [209.6.217.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail1.g15.pair.com (Postfix) with ESMTPSA id 6A73CBDD98; Thu, 3 Aug 2017 18:21:44 -0400 (EDT) To: Noah Mendelsohn Cc: "dispatch@ietf.org" , "art@ietf.org" , "uri-review@ietf.org" References: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> From: David Booth Message-ID: Date: Thu, 3 Aug 2017 18:21:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] [Uri-review] [dispatch] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 22:21:47 -0000 On 07/31/2017 12:17 AM, Noah Mendelsohn wrote: [ . . . ] > A little history on the drafts at: > > https://www.w3.org/2001/tag/doc/SchemeProtocols.html > > There were two of these drafts, [ . . . ] It sounds to me like the history that you just explained in email would be a perfect addition to those draft documents, as an editor note, so that people who find them can more easily understand their context. Thanks, David Booth From nobody Thu Aug 3 17:06:17 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D403F1241FC for ; Thu, 3 Aug 2017 17:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com 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 XwJHMYJgPZZP for ; Thu, 3 Aug 2017 17:06:13 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC87131FF2 for ; Thu, 3 Aug 2017 17:06:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.41,318,1498485600"; d="scan'208,217";a="166587110" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 04 Aug 2017 10:05:03 +1000 X-IronPort-AV: E=McAfee;i="5900,7806,8610"; a="442717673" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcbni.tcif.telstra.com.au with ESMTP; 04 Aug 2017 10:05:03 +1000 Received: from wsapp5872.srv.dir.telstra.com (10.75.11.108) by wsmsg3751.srv.dir.telstra.com (172.49.40.172) with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 4 Aug 2017 10:05:03 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5872.srv.dir.telstra.com (10.75.11.108) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 4 Aug 2017 10:04:56 +1000 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Fri, 4 Aug 2017 10:04:56 +1000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9oVFW0frMmB1Ef2SI9Whgiq+p9McBjGvc7/kOk9P+sI=; b=PDlPKGqlT7JGBaXO5b44LDKEY1wpAh49H098PDp5hSnqcYxRBkGorB27YzLrpU3dZ+KyIytopCX1xg1RBNxTprzhloyCW2WldRVRljwGbAldMvklOqhE/FEG19Tm4n38Yel/+Fq2R0TOPrxKIj0Cap29I6YhQ7lejjEYyQi3brU= Received: from MEXPR01MB1382.ausprd01.prod.outlook.com (10.171.18.21) by MEXPR01MB1381.ausprd01.prod.outlook.com (10.171.18.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Fri, 4 Aug 2017 00:04:48 +0000 Received: from MEXPR01MB1382.ausprd01.prod.outlook.com ([10.171.18.21]) by MEXPR01MB1382.ausprd01.prod.outlook.com ([10.171.18.21]) with mapi id 15.01.1304.025; Fri, 4 Aug 2017 00:04:48 +0000 From: "Manger, James" To: Herbert Van de Sompel , "art@ietf.org" CC: "John A. Kunze" , Simeon Warner , Michael Nelson , Geoffrey Bilder Thread-Topic: [art] "identifier" relation type Thread-Index: AQHTDDU/sIKtC9v3JE6J4LF6dFBPa6JzRq0g Date: Fri, 4 Aug 2017 00:04:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.185.254] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MEXPR01MB1381; 7:yXGsmCadcsNW2N8AQ4c4Db61zd1RpHX1G6Xi46j9ggkHsYpjPs7oUP8MaUOMycPJK8Fp990hl8ZpqqShzMKMolmUvYy65c93OCJvQhd8S4mhQlyXwegq9MglCVDfalvS909d+lTMpjOLsD5coB+LTPiXEJtppIoqZ1IosDpReQFuz6AKJsh8PrGV7RunStoKw5qAhHk99J9F4RZelTJCAr1AYV6n0ret8B1zzjogf1aHDSOI1X9mVLUImDGXKkSm22ceDZ9aoiAHlomW9+VNBcL3G8HzwWLfl3dHc2+PzAvxlEisMJQ3rJ8tj9weIyfyKXDXsXUj0WjACbRnOZx8zkhUQXprax9qqLB7utQ6hJIwx1Q+XzzkVIF5fCAhZYF5hYPiGzjK7xk/R6IhHcsyFGLV1ORE9ePtkRxVs01goMZZ9BYEyMOqSQqW9szfnt4ABR/e5j41I21upIPetx9ju/SxxlxN/G5K7m/5xnlSMxeR/OkhM4/W+J/xqVttW3xhYVc4rd2U0as4tQCxJARLpXB7BvL4wXi3U2XrygmC1k9tTXTGY6rQwh0rYlOHUTA7KH41wOjYjkEumujMY73ePvV4cwJflGs0c0yYSfITiklzUolPvmSySTy2nwxMRaGuc6GWpkXSZmEMc7DxoQHQXO/sy7WILgXUR3upaV8YtpWvSXW2aDSthpQIaNY/1QiaETObtsuBzTR4jLcUfeu3BJ+3rkdTc9IlL4yukrG2l2NgKH1z9lWR5/c6aJsawPhEO801I45TkzOPsprCqiERc8XQjH70hXelf9UD8OgY2oQ= x-ms-office365-filtering-correlation-id: 16f49594-5c91-4dc5-09d5-08d4dacc6bb3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MEXPR01MB1381; x-ms-traffictypediagnostic: MEXPR01MB1381: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(1591387915157); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MEXPR01MB1381; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MEXPR01MB1381; x-forefront-prvs: 0389EDA07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39400400002)(39850400002)(39450400003)(39410400002)(199003)(189002)(55016002)(6306002)(54906002)(8936002)(236005)(54896002)(9686003)(74316002)(101416001)(81156014)(99286003)(81166006)(8676002)(39060400002)(42882006)(2950100002)(54356999)(6506006)(6436002)(76176999)(229853002)(6246003)(77096006)(50986999)(3280700002)(53936002)(7696004)(7736002)(33656002)(38730400002)(86362001)(189998001)(106356001)(105586002)(97736004)(5660300001)(790700001)(478600001)(3846002)(102836003)(2501003)(6116002)(68736007)(966005)(2906002)(14454004)(25786009)(8656003)(2900100001)(4326008)(66066001)(72206003)(606006)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MEXPR01MB1381; H:MEXPR01MB1382.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MEXPR01MB13826B11611153CD4031E292E5B60MEXPR01MB1382ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 00:04:48.0224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB1381 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [art] "identifier" relation type X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 00:06:16 -0000 --_000_MEXPR01MB13826B11611153CD4031E292E5B60MEXPR01MB1382ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12YW5kZXNvbXBlbC1pZGVu dGlmaWVyLw0KDQpUaGUgY2hvaWNlIG9mIOKAnGlkZW50aWZpZXLigJ0gYXMgdGhlIGxhYmVsIGNv dWxkbuKAmXQgYmUgbW9yZSBnZW5lcmljLiBIb3cgYWJvdXQgdXNpbmcgc29tZXRoaW5nIHRoYXQg aXMgYSB0YWQgbW9yZSBzcGVjaWZpYyAmIGRlc2NyaXB0aXZlLCBzdWNoIGFzIOKAnHJlZi1pZOKA nSBvciDigJxyZWZlcmVuY2XigJ0gb3Ig4oCcY2Fub25pY2FscmVm4oCdPyDigJxjYW5vbmljYWxy ZWbigJ0gaGFzIHRoZSBjdXRlIGJlbmVmaXQgb2YgcHV0dGluZyBpdHMgZGVzY3JpcHRpb25zIG5l YXIgKGluIGFuIGFscGhhYmV0aWNhbGx5LXNvcnRlZCBsaXN0KSB0byB0aG9zZSBvZiDigJxjYW5v bmljYWzigJ0gYW5kIOKAnGJvb2ttYXJr4oCdIHRoYXQgYXJlIG9ubHkgc3VidGx5IGRpZmZlcmVu dC4NCg0KaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvbGluay1yZWxhdGlvbnMvbGlu ay1yZWxhdGlvbnMueGh0bWwNCg0KYm9va21hcmsgICAgICAgIEdpdmVzIGEgcGVybWFuZW50IGxp bmsgdG8gdXNlIGZvciBib29rbWFya2luZyBwdXJwb3Nlcy4NCmNhbm9uaWNhbCAgICAgICAgIERl c2lnbmF0ZXMgdGhlIHByZWZlcnJlZCB2ZXJzaW9uIG9mIGEgcmVzb3VyY2UgKHRoZSBJUkkgYW5k IGl0cyBjb250ZW50cykuDQpjYW5vbmljYWxyZWYgICAgR2l2ZXMgYSBwZXJtYW5lbnQgbGluayBm b3IgdGhlIHB1cnBvc2Ugb2YgcmVmZXJlbmNpbmcgdGhlIHJlc291cmNlLg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQo= --_000_MEXPR01MB13826B11611153CD4031E292E5B60MEXPR01MB1382ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tQVUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12YW5kZXNv bXBlbC1pZGVudGlmaWVyLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dmFuZGVzb21wZWwtaWRlbnRpZmllci88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGUgY2hvaWNlIG9mIOKAnGlkZW50aWZpZXLigJ0gYXMgdGhlIGxhYmVsIGNv dWxkbuKAmXQgYmUgbW9yZSBnZW5lcmljLiBIb3cgYWJvdXQgdXNpbmcgc29tZXRoaW5nIHRoYXQg aXMgYSB0YWQgbW9yZSBzcGVjaWZpYyAmYW1wOyBkZXNjcmlwdGl2ZSwNCiBzdWNoIGFzIOKAnHJl Zi1pZOKAnSBvciDigJxyZWZlcmVuY2XigJ0gb3Ig4oCcY2Fub25pY2FscmVm4oCdPyDigJxjYW5v bmljYWxyZWbigJ0gaGFzIHRoZSBjdXRlIGJlbmVmaXQgb2YgcHV0dGluZyBpdHMgZGVzY3JpcHRp b25zIG5lYXIgKGluIGFuIGFscGhhYmV0aWNhbGx5LXNvcnRlZCBsaXN0KSB0byB0aG9zZSBvZiDi gJxjYW5vbmljYWzigJ0gYW5kIOKAnGJvb2ttYXJr4oCdIHRoYXQgYXJlIG9ubHkgc3VidGx5IGRp ZmZlcmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2xpbmstcmVsYXRpb25zL2xpbmstcmVs YXRpb25zLnhodG1sIj5odHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9saW5rLXJlbGF0 aW9ucy9saW5rLXJlbGF0aW9ucy54aHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPmJvb2ttYXJrJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEdpdmVzIGEgcGVybWFuZW50IGxpbmsgdG8gdXNlIGZvciBib29rbWFya2luZyBwdXJw b3Nlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Y2Fub25p Y2FsICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Rlc2ln bmF0ZXMgdGhlIHByZWZlcnJlZCB2ZXJzaW9uIG9mIGEgcmVzb3VyY2UgKHRoZSBJUkkgYW5kIGl0 cyBjb250ZW50cykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PmNhbm9uaWNhbHJlZiAmbmJzcDsmbmJzcDsmbmJzcDtHaXZlcyBhIHBlcm1hbmVudCBsaW5rIGZv ciB0aGUgcHVycG9zZSBvZiByZWZlcmVuY2luZyB0aGUgcmVzb3VyY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MEXPR01MB13826B11611153CD4031E292E5B60MEXPR01MB1382ausp_-- From nobody Thu Aug 3 19:13:16 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6496E131C26 for ; Thu, 3 Aug 2017 19:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Z48i_S0wiOzz for ; Thu, 3 Aug 2017 19:13:13 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3352E129ADD for ; Thu, 3 Aug 2017 19:13:13 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 77so1856296itj.1 for ; Thu, 03 Aug 2017 19:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P9OqvUeI9GDueQoNBw8WPWAUO3zOZgFsMN+T6GZeYxw=; b=vV7TdO1OlYXOQUCWlzBgMjPFXiKkA149Ot4RwtG3ClCRafiIUrtMVu7yakzrOsdFKm 2yA+yYmyqZwLOMUbQljvEWfoo/W75vVktGR0+cTEMJJGzw/RNOEb5X81K7urgczFLpJx hcrn4dydVwgQfEZsR8/EMs92whyEfUfAqkG1cVX5w68Phr4y3GxmVMFPpT5EA0lvmdSe +eh+Pd/2v6NmiE5nHwgIMX1ZFpOd3sfMIwUM1z8gy1N+dvxBzSTweMnREdBB/CgQzgKq ypPcLTSTBZ6smP/smz72pOzt20QTASOSMHHT3aaM+j/BlXhJIHuJg8lzr9Yg6ERjBUSC v2pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P9OqvUeI9GDueQoNBw8WPWAUO3zOZgFsMN+T6GZeYxw=; b=RgNbYuxCbZ6EIi7W7BdMSFcu5R3UDcgrnwbHEZ86Wwopx/jn8LQDZO36oci/g54UWm KNopuL0p1nLTFp8UQV/ExQkvZdLJWKBwasfmfqkiWAf3YCR2Iv3L/RrTGnYRxf9Seu41 5Foul3EWbXaLV/W+Ney01CWYPIAJJsI/paFP9BBCH8qhCKIKPYCsdsrVVZsNHfJxDwrA ORlvOOq7KUKVj8vDjM0vkOAA2tHhQztGnvjQZihbUybnb9q+uTCnyeVMoBILQ/cZ/hZo 4nHzSsBeLh8ropL8OWBx94gKFDwYt178n62bWmyQwTUJ875w35Ij080GnYcXZzLEIAl3 svCg== X-Gm-Message-State: AHYfb5h877ddNpBGo2QoyK1r2qm2tTy1qTsjCHb0fi2x4fVFD3hm1/cG 02pIolWj53E7WQ8W6I9qMYary7mofw== X-Received: by 10.36.181.85 with SMTP id j21mr601603iti.165.1501812792613; Thu, 03 Aug 2017 19:13:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 3 Aug 2017 19:13:12 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 4 Aug 2017 12:13:12 +1000 Message-ID: To: "Manger, James" Cc: Herbert Van de Sompel , "art@ietf.org" , "John A. Kunze" , Geoffrey Bilder , Michael Nelson , Simeon Warner Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] "identifier" relation type X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 02:13:14 -0000 On 4 August 2017 at 10:04, Manger, James wrote: > canonical Designates the preferred version of a resource (the IRI > and its contents). > > canonicalref Gives a permanent link for the purpose of referencing the > resource. Given the title of the I-D as "A Link Relation to Convey a Preferred URI for Referencing", and its similarity to the definition for "canonical", and the explanation in the draft regarding "canonical", this doesn't seem right. Maybe you could approach this differently and use "alternate" and defined a new preferred attribute to that. From nobody Wed Aug 9 16:25:47 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B1E126DD9 for ; Wed, 9 Aug 2017 16:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 52sdgQs_h45s for ; Wed, 9 Aug 2017 16:25:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C27126C2F for ; Wed, 9 Aug 2017 16:25:43 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v79NPcpb023307 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 9 Aug 2017 18:25:40 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Dave Crocker , John Levine , art@ietf.org References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> From: Adam Roach Message-ID: <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> Date: Wed, 9 Aug 2017 18:25:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> Content-Type: multipart/alternative; boundary="------------DE03B6E4F5E51F1A36C360B9" Content-Language: en-US Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 23:25:46 -0000 This is a multi-part message in MIME format. --------------DE03B6E4F5E51F1A36C360B9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/2/17 7:42 PM, Dave Crocker wrote: > On 8/2/2017 5:35 PM, John Levine wrote: >> In article <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> you >> write: >>> 2. Create a separate document that specifies modifications to the >>> SRV and URI documents, rationalizing the use of underscore names, >>> through the mechanism defined in -attrleaf-. >> >> It seems a bit late to change SRV. Or would you only adjust the >> documentation to match observed reality? > > The latter. The change is to the registration process, not to SRV, > per se. That is, take a snapshot of the existing SRV underscore usage > and re-specify it in terms of an underscore registry, rather than in > terms of an inheritance from another registry. That would appear to call for a slightly more narrow scope than the current document, which claims to be registering underscore usage for SRV, TXT, and URI RRs as well as (and I don't quite get this) NAPTR RRs. The reason I don't get the NAPTR treatment is: my understanding of NAPTR records doesn't include any kind of underscore-prefixed name components at all. My knowledge of NAPTR is mostly informed by SIP's usage of NAPTR; but I'm pretty sure that, in a generic sense, the overall procedure here is to feed in an underscore-free name in as your query, and to get back a giant slew of records that indicate various available services in their respective "Service" fields, along with a string transform that should be applied to the original name, the result of which is then fed back into another query for the service of interest. I have to concede that the situation around registration of NAPTR Service values has always baffled me, and section 9 of RFC 3403 makes essentially no sense as far as I can tell. SIP solved this problem in its little corner of the NAPTR world with the registry at . I have no idea how other protocols are supposed to deal with this situation; or, indeed, how one might hope to avoid collisions if the "MPLS-TP Shared Ring Protection" mechanism and the "Message Session Relay Protocol" both decided to use a NAPTR Service value of "MSRP+D2T". Practically, for this document, I would recommend having a unified table for SRV and URI records, initially containing: 1. _tcp 2. _udp 3. _sctp (implict in rfc6733) There's also the odd matter of _LDAP, _HTTP, and _OCSP, used by RFC4386 in what I presume was a misunderstanding of what was meant by "Proto" in SRV's definition of that term -- I would think we want to put these in the table but mark them experimental and/or deprecated. In fact, I think we would want to stipulate that new entries in this registry cannot contain any value other than those registered at . I would recommend documenting and registering the underscore leaf nodes used by TXT records as a completely separate concern and in a different IANA table (although still as part of this document), as they mean something rather different than what's defined for SRV and URI. I believe the initial tables looks something like this at the moment (although I may have overlooked one or two): 1. _domainkey 2. _dmarc (rfc7489) 3. _spf 4. _vouch 5. _tcp (implicit in rfc6764, rfc7808) If you want to fix the NAPTR Service registry issue I highlight above, I would recommend doing this in a different document. It feels like a rather different problem, and the presence of the SIP registry (which would need to be subsumed into any complete registry) would seem to make it much more complicated to deal with. /a --------------DE03B6E4F5E51F1A36C360B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/2/17 7:42 PM, Dave Crocker wrote:
On 8/2/2017 5:35 PM, John Levine wrote:
In article <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> you write:
    2. Create a separate document that specifies modifications to the
SRV and URI documents, rationalizing the use of underscore names,
through the mechanism defined in -attrleaf-.

It seems a bit late to change SRV.  Or would you only adjust the
documentation to match observed reality?

The latter.  The change is to the registration process, not to SRV, per se.  That is, take a snapshot of the existing SRV underscore usage and re-specify it in terms of an underscore registry, rather than in terms of an inheritance from another registry.

That would appear to call for a slightly more narrow scope than the current document, which claims to be registering underscore usage for SRV, TXT, and URI RRs as well as (and I don't quite get this) NAPTR RRs. The reason I don't get the NAPTR treatment is: my understanding of NAPTR records doesn't include any kind of underscore-prefixed name components at all. My knowledge of NAPTR is mostly informed by SIP's usage of NAPTR; but I'm pretty sure that, in a generic sense, the overall procedure here is to feed in an underscore-free name in as your query, and to get back a giant slew of records that indicate various available services in their respective "Service" fields, along with a string transform that should be applied to the original name, the result of which is then fed back into another query for the service of interest.

I have to concede that the situation around registration of NAPTR Service values has always baffled me, and section 9 of RFC 3403 makes essentially no sense as far as I can tell. SIP solved this problem in its little corner of the NAPTR world with the registry at <https://www.iana.org/assignments/sip-table/sip-table.xhtml>. I have no idea how other protocols are supposed to deal with this situation; or, indeed, how one might hope to avoid collisions if the "MPLS-TP Shared Ring Protection" mechanism and the "Message Session Relay Protocol" both decided to use a NAPTR Service value of "MSRP+D2T".

Practically, for this document, I would recommend having a unified table for SRV and URI records, initially containing:
  1. _tcp
  2. _udp
  3. _sctp (implict in rfc6733)

There's also the odd matter of _LDAP, _HTTP, and _OCSP, used by RFC4386 in what I presume was a misunderstanding of what was meant by "Proto" in SRV's definition of that term -- I would think we want to put these in the table but mark them experimental and/or deprecated. In fact, I think we would want to stipulate that new entries in this registry cannot contain any value other than those registered at <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>.


I would recommend documenting and registering the underscore leaf nodes used by TXT records as a completely separate concern and in a different IANA table (although still as part of this document), as they mean something rather different than what's defined for SRV and URI. I believe the initial tables looks something like this at the moment (although I may have overlooked one or two):

  1. _domainkey
  2. _dmarc (rfc7489)
  3. _spf
  4. _vouch
  5. _tcp (implicit in rfc6764, rfc7808)


If you want to fix the NAPTR Service registry issue I highlight above, I would recommend doing this in a different document. It feels like a rather different problem, and the presence of the SIP registry (which would need to be subsumed into any complete registry) would seem to make it much more complicated to deal with.

/a

--------------DE03B6E4F5E51F1A36C360B9-- From nobody Wed Aug 9 16:37:02 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115DD1287A5 for ; Wed, 9 Aug 2017 16:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=lpMhUoBL; dkim=pass (1536-bit key) header.d=taugh.com header.b=pCkPjRxH 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 4_STT68kzL4T for ; Wed, 9 Aug 2017 16:36:58 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D567131CCC for ; Wed, 9 Aug 2017 16:36:57 -0700 (PDT) Received: (qmail 40641 invoked from network); 9 Aug 2017 23:36:56 -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; s=9ebf.598b9c98.k1707; bh=WvmH7bKPBLbnbhyVg26n5PT2uZjYYZKudgri4u6YC9E=; b=lpMhUoBLj2WvthHH+MQtl6+Yol0shhOEF+o/LPNRi28g673+5fjvUwP74Dokho+ThWcd5Xc9h1ctcluAOkW5+v1WAKGgbzaKNQmR8gRCBHwbWxsJuS8LI1kYP94J76OlwuW3jZ0wkBagytZ+a7zc30heZC48c7a0HOjBsZ0nbA/VDhF9epzl4ACrqU7xpsVNPdZBchFWWOrdRvNK8qZsqPi2w4OD4uxx8DepbjI9VToNOYvsE9CIWBHnacdF0Usl 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; s=9ebf.598b9c98.k1707; bh=WvmH7bKPBLbnbhyVg26n5PT2uZjYYZKudgri4u6YC9E=; b=pCkPjRxHz4b3soGg8DeMg2sZws0Vjp+bgGoyIvPA4QRt68gR5XnMtslzc+hPAEXBhnTlCH0cXidlHTkLe1mbQRswe0jMZC0z71PHgzin3Vy3/0S0HksOep7PofQ+csy2Mz9HOOK+bolQa4zj3NWd9uz8R6biQzda1mNMhsKuYlKHCMVjnRGUQq/WLjV0N2wpohis9tx8ld2YnO6FYyF3jLdkEdZmA+Q+jyYipIsD76zX8Amlfnorg5IZDEQjACyH Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 09 Aug 2017 23:36:56 -0000 Date: 9 Aug 2017 19:36:55 -0400 Message-ID: From: "John R Levine" To: "Adam Roach" Cc: "Dave Crocker" , art@ietf.org In-Reply-To: <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 23:37:00 -0000 On Wed, 9 Aug 2017, Adam Roach wrote: > That would appear to call for a slightly more narrow scope than the current > document, which claims to be registering underscore usage for SRV, TXT, and > URI RRs as well as (and I don't quite get this) NAPTR RRs. ... See rfc3588 which has some _sctp names for NAPTR records. > I would recommend documenting and registering the underscore leaf nodes used > by TXT records as a completely separate concern and in a different IANA table That would rather defeat the purpose here, since the goal is to identify and ideally prevent name collisions. Or are you saying that names for TXT and for SRV or URI are separate namespaces? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Aug 9 16:46:06 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E9C131CFE for ; Wed, 9 Aug 2017 16:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wJEIzCWmKezJ for ; Wed, 9 Aug 2017 16:46:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368C2126C2F for ; Wed, 9 Aug 2017 16:46:03 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 7119E24AE12; Wed, 9 Aug 2017 23:44:33 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C91D8160041; Wed, 9 Aug 2017 23:44:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9C5981600A3; Wed, 9 Aug 2017 23:44:38 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YHTuUvzF6gqS; Wed, 9 Aug 2017 23:44:38 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4F0C1160041; Wed, 9 Aug 2017 23:44:38 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8FE6481E236C; Thu, 10 Aug 2017 09:44:36 +1000 (AEST) To: "John R Levine" Cc: "Adam Roach" , art@ietf.org, Dave Crocker From: Mark Andrews References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> In-reply-to: Your message of "09 Aug 2017 19:36:55 -0400." Date: Thu, 10 Aug 2017 09:44:36 +1000 Message-Id: <20170809234436.8FE6481E236C@rock.dv.isc.org> Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 23:46:05 -0000 In message , "John R Levine" writes: > On Wed, 9 Aug 2017, Adam Roach wrote: > > That would appear to call for a slightly more narrow scope than the current > > document, which claims to be registering underscore usage for SRV, TXT, and > > URI RRs as well as (and I don't quite get this) NAPTR RRs. ... > > See rfc3588 which has some _sctp names for NAPTR records. > > > I would recommend documenting and registering the underscore leaf nodes used > > by TXT records as a completely separate concern and in a different IANA table > > That would rather defeat the purpose here, since the goal is to identify > and ideally prevent name collisions. Or are you saying that names for TXT > and for SRV or URI are separate namespaces? Unless you have non-overlapping syntax rules they can't be seperate namespaces. As long as they both have a single prefix underscore they are both in the same namespace. > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Aug 9 17:43:00 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1144132139 for ; Wed, 9 Aug 2017 17:42:59 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=IQG8/PMd; dkim=pass (1536-bit key) header.d=taugh.com header.b=pBgsp2um 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 Fcr8I92xfdbu for ; Wed, 9 Aug 2017 17:42:57 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E16131CB2 for ; Wed, 9 Aug 2017 17:42:57 -0700 (PDT) Received: (qmail 45726 invoked from network); 10 Aug 2017 00:42:56 -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; s=b29c.598bac10.k1707; bh=cRIijLu3WO+LwtPPPE++WZH5nls9OsWcFiCsnKG8UqA=; b=IQG8/PMdYITBDOj2ihMrWvy//M2Uq97dwBSrZTSEsDYwlVzPPkL7bvLnss61l1Vtu/H1rzLVaNY9iOGp91qn3nLO5Ih2eSPU4YWKuKIHSaroBd+QqHPSKIWtwnT6bwif9T+v0SwGMviQjE2XRbrUHjR3hFF9uDvVER6DIphk/f3xJRuy5Q82RCj0omoRL84CjehsUdMrYcEZHtLRKzfinhQAh+ihytywJrLXqfJ7gku6ebIuhIxWovZcJjdpw4vB 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; s=b29c.598bac10.k1707; bh=cRIijLu3WO+LwtPPPE++WZH5nls9OsWcFiCsnKG8UqA=; b=pBgsp2umWrM7/yD+FCfTRudHgFnFNHQvLrcZRpAesMPwOTPwCR49qLQVBRPfY3PjbTC8DwGaREPLV3AH+tPl+xrkWIcxd5A1Stsrfm4gnZUZpaaaFHnT7+UFtQHscultOHxHCOq/pwrDkcc1Py7nA63Vrtljh4OzPiNvuUGU5LSjTwjpisjh+KzZG2ZBFnEOXsC6/JSyunUL+vqvmtnkS6osXy5Bxql9i/V8tKul10ljzg9aFapPXSmJVE497vT8 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Aug 2017 00:42:56 -0000 Date: 9 Aug 2017 20:42:56 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: art@ietf.org, "Dave Crocker" In-Reply-To: <20170809234436.8FE6481E236C@rock.dv.isc.org> References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> <20170809234436.8FE6481E236C@rock.dv.isc.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 00:43:00 -0000 On Thu, 10 Aug 2017, Mark Andrews wrote: >> That would rather defeat the purpose here, since the goal is to identify >> and ideally prevent name collisions. Or are you saying that names for TXT >> and for SRV or URI are separate namespaces? > > Unless you have non-overlapping syntax rules they can't be seperate > namespaces. As long as they both have a single prefix underscore > they are both in the same namespace. That's what I thought, too. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Aug 9 18:15:14 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D011324E9 for ; Wed, 9 Aug 2017 18:15:13 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 zgjmmxn-ncQT for ; Wed, 9 Aug 2017 18:15:11 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5871324E6 for ; Wed, 9 Aug 2017 18:15:11 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v7A1FeJj005304 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 9 Aug 2017 18:15:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1502327741; bh=xlboeroLbonZqd+ZvYX0tRFXNdyx4heg/as295wpiKU=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=QILH+EGkNso/GjaOqFrtiTjPm+kgZPS1XMPkszq/GPYmt6/nIUorPMfJ1vKRaCjHQ yaxkmoOgE6uop3hlyb7/WyUwpnSeb7ZiQHTbNu5bmfkXPFaBhqmqRJyGAJkgnclLNf r1PIIlbIzwviauxf5Vwt9/7Zqf14GkHpO6Pxkmhg= To: Adam Roach References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> Cc: art@ietf.org Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <04c36ea8-dbf4-1e01-4982-dd07863a18b1@dcrocker.net> Date: Wed, 9 Aug 2017 18:15:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 01:15:13 -0000 On 8/9/2017 4:25 PM, Adam Roach wrote: > I would recommend documenting and registering the underscore leaf nodes > used by TXT records as a completely separate concern and in a different > IANA table Adam, (Leaving for later, all other comments about the note, other than to say thanks for reading the draft, thinking about it, and commenting...) Your above seems to be calling for two registries that assign out of the same namespace. (Being specified in the same document doesn't matter if there are two tables.) I'm hoping I've seriously misunderstood, since the entire goal of my simplification proposal is to avoid exactly that. Please to set me right. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 9 19:38:13 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2567D131D1E for ; Wed, 9 Aug 2017 19:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 RHVHfyOIAm3U for ; Wed, 9 Aug 2017 19:38:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964E9131CBF for ; Wed, 9 Aug 2017 19:38:10 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7A2c76F055317 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 9 Aug 2017 21:38:08 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: dcrocker@bbiw.net Cc: art@ietf.org References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> <04c36ea8-dbf4-1e01-4982-dd07863a18b1@dcrocker.net> From: Adam Roach Message-ID: <066763ab-1121-0c57-5a66-48349c4cc101@nostrum.com> Date: Wed, 9 Aug 2017 21:38:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <04c36ea8-dbf4-1e01-4982-dd07863a18b1@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 02:38:12 -0000 On 8/9/17 8:15 PM, Dave Crocker wrote: > On 8/9/2017 4:25 PM, Adam Roach wrote: >> I would recommend documenting and registering the underscore leaf >> nodes used by TXT records as a completely separate concern and in a >> different IANA table > > > Adam, > > (Leaving for later, all other comments about the note, other than to > say thanks for reading the draft, thinking about it, and commenting...) > > Your above seems to be calling for two registries that assign out of > the same namespace. (Being specified in the same document doesn't > matter if there are two tables.) > > I'm hoping I've seriously misunderstood, since the entire goal of my > simplification proposal is to avoid exactly that. > > Please to set me right. So, I'll reiterate explicitly what I've only implied to this point: I'm not a DNS expert; I've simply dealt with protocols that use DNS, and I've managed DNS zones. What I do know is that I can ask for an RR of type FOO for something.example.com and get a response with an answer, and I can ask for an RR of type BAR for something.example.com, and get a response with no answers. I've internalized this as FOO and BAR being different things -- different scopes, effectively -- but (based on your and John Levine's and Mark Andrew's responses) clearly have an incorrect mental model of what's considered "namespaces," at least as compared to people who deal with DNS in more detail. So ignore the aspect of my proposal that suggested two tables. I think the remainder is sound, which probably just resolves to cleaning up the table so that it contains only seven entries and removing discussion of NAPTR RRs. /a From nobody Wed Aug 9 19:50:08 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1E132395 for ; Wed, 9 Aug 2017 19:50:06 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbiw.net 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 uOxyBe2p1iky for ; Wed, 9 Aug 2017 19:50:04 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1C0127735 for ; Wed, 9 Aug 2017 19:50:04 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v7A2oXMk009914 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 9 Aug 2017 19:50:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1502333434; bh=lOlw6gyC3l+mE4k4xOvAdonXQaJALRgi75fmii402d8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cGbpoDARdyzINMWF0cDc9LHQ3yQncGlIQiQeF4Ke1maxhe+b/ANmb3blM8NRFe93V 3HHwfPzT6rbnuXIRHzt3bMlMgWLPkPAfjjTC1UHcaOHaBjFesKGPQg3dAxQBHRX9TJ AGFtqRVXNYhKoWVuAocgbrF3OWvefVwl3ChA4w70= To: Adam Roach Cc: art@ietf.org References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> <04c36ea8-dbf4-1e01-4982-dd07863a18b1@dcrocker.net> <066763ab-1121-0c57-5a66-48349c4cc101@nostrum.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <6b5f8522-4390-9cc5-a246-bd13cdf96296@bbiw.net> Date: Wed, 9 Aug 2017 19:49:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <066763ab-1121-0c57-5a66-48349c4cc101@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 02:50:06 -0000 On 8/9/2017 7:38 PM, Adam Roach wrote: > What I do know is that I can ask for an RR of type FOO for > something.example.com and get a response with an answer, and I can ask > for an RR of type BAR for something.example.com, and get a response with > no answers. I've internalized this as FOO and BAR being different things > -- different scopes, effectively -- but (based on your and John Levine's > and Mark Andrew's responses) clearly have an incorrect mental model of > what's considered "namespaces," at least as compared to people who deal > with DNS in more detail. Ahh, interesting. This might point to a need for some additional explanatory (and maybe even denotational) text in the draft. (I work from the theory that confusion in one serious reader is likely an indicator that others will suffer the same fate.) So: Scope is meant as a static property, not one dependent on the nature of the query. It is an artifact of the DNS name. Hence, some.example.com defines the scope, independent of any RR under it. And in case it's relevant to add this: The namespace of the proposed registry covers all node names that begin with an underscore and are the 'highest' occurrence of an underscore name. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Aug 9 19:52:24 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EE132529 for ; Wed, 9 Aug 2017 19:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 0XkYFTYPV_B7 for ; Wed, 9 Aug 2017 19:52:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB3C127735 for ; Wed, 9 Aug 2017 19:52:20 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7A2qG4k057731 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 9 Aug 2017 21:52:17 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: John R Levine Cc: Dave Crocker , art@ietf.org References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> From: Adam Roach Message-ID: <0ce197ca-64ee-bbcf-0c42-779996742113@nostrum.com> Date: Wed, 9 Aug 2017 21:52:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 02:52:22 -0000 On 8/9/17 6:36 PM, John R Levine wrote: > See rfc3588 which has some _sctp names for NAPTR records. I presume you're referring to the example in Appendix B? I can see how it might look like that on first glance, but a careful parsing of what's there shows that the only reason it looks like that is because there's been some formatting damage. The literal text that's there is: ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "AAA+D2S" "" _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com This is accompanied with an explanation that there are two NAPTR records present (one for AAA+D2S and one for AAA+D2T). I suppose you're reading the second line of this text to say "the host _diameter._sctp.example.com has an NAPTR record for 'AAA+D2T', with an empty regexp and a replacement of '_aaa._tcp.example.com" Aside from that being kind of nonsense, I'll note that the *first* record (if this "_diameter._sctp.example.com" string is part of the second record) has no replacement value -- which clearly doesn't work. The only way this makes sense is if you read the first record as: IN NAPTR 50 50 "s" "AAA+D2S" "" _diameter._sctp.example.com ...and the second record as: IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com ...at which point it becomes clear that the underscores are only in the "replacement" field, and not used as input for NAPTR. I'll file an erratum. /a From nobody Wed Aug 9 20:10:54 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3E132537 for ; Wed, 9 Aug 2017 20:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 wBqkIMYwEE6Y for ; Wed, 9 Aug 2017 20:10:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E5E132529 for ; Wed, 9 Aug 2017 20:10:52 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7A3AmCV060932 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 9 Aug 2017 22:10:49 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local From: Adam Roach To: John R Levine Cc: art@ietf.org, Dave Crocker References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> <0ce197ca-64ee-bbcf-0c42-779996742113@nostrum.com> Message-ID: Date: Wed, 9 Aug 2017 22:10:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0ce197ca-64ee-bbcf-0c42-779996742113@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 03:10:53 -0000 On 8/9/17 9:52 PM, Adam Roach wrote: > I'll file an erratum. Actually, I was about to until I noticed that this RFC is obsolete, and the replacement RFC has fixed the formatting issue. Never mind :) /a From nobody Wed Aug 9 20:15:06 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DFD132533 for ; Wed, 9 Aug 2017 20:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1Uhh8hXQq9m5 for ; Wed, 9 Aug 2017 20:15:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A9A132529 for ; Wed, 9 Aug 2017 20:15:02 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 54DEF24AE13; Thu, 10 Aug 2017 03:13:32 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D5117160042; Thu, 10 Aug 2017 03:13:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C0DFF1600A3; Thu, 10 Aug 2017 03:13:37 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mDLtzitE9V1H; Thu, 10 Aug 2017 03:13:37 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3E6F4160042; Thu, 10 Aug 2017 03:13:37 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DDC5081EE5DB; Thu, 10 Aug 2017 13:13:34 +1000 (AEST) To: Adam Roach Cc: John R Levine , art@ietf.org, Dave Crocker From: Mark Andrews References: <20170803003526.2349.qmail@ary.lan> <8cbaba50-a7d8-94b1-8cd0-fa8310e0b17d@bbiw.net> <47fcd0be-e4b6-2efc-266a-2eaef6243346@nostrum.com> <0ce197ca-64ee-bbcf-0c42-779996742113@nostrum.com> In-reply-to: Your message of "Wed, 09 Aug 2017 21:52:10 -0500." <0ce197ca-64ee-bbcf-0c42-779996742113@nostrum.com> Date: Thu, 10 Aug 2017 13:13:34 +1000 Message-Id: <20170810031334.DDC5081EE5DB@rock.dv.isc.org> Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 03:15:05 -0000 In message <0ce197ca-64ee-bbcf-0c42-779996742113@nostrum.com>, Adam Roach write s: > On 8/9/17 6:36 PM, John R Levine wrote: > > See rfc3588 which has some _sctp names for NAPTR records. > > > I presume you're referring to the example in Appendix B? I can see how > it might look like that on first glance, but a careful parsing of what's > there shows that the only reason it looks like that is because there's > been some formatting damage. The literal text that's there is: > > ;; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "AAA+D2S" "" > _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T" > "" _aaa._tcp.example.com > > This is accompanied with an explanation that there are two NAPTR records > present (one for AAA+D2S and one for AAA+D2T). I suppose you're reading > the second line of this text to say "the host > _diameter._sctp.example.com has an NAPTR record for 'AAA+D2T', with an > empty regexp and a replacement of '_aaa._tcp.example.com" > > Aside from that being kind of nonsense, I'll note that the *first* > record (if this "_diameter._sctp.example.com" string is part of the > second record) has no replacement value -- which clearly doesn't work. > > The only way this makes sense is if you read the first record as: > > IN NAPTR 50 50 "s" "AAA+D2S" "" _diameter._sctp.example.com > > ...and the second record as: > > IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com > > ...at which point it becomes clear that the underscores are only in the > "replacement" field, and not used as input for NAPTR. > > I'll file an erratum. > > /a While you are reporting the NAPTR records the formatting the SRV records is also poorly presented. Line breaks and indenting is critical. ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com should be ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com Personally I would have had the owner names there as well but I didn't write this document. > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 10 04:49:48 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0913250B; Thu, 10 Aug 2017 04:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UwlJNwcX-X8G; Thu, 10 Aug 2017 04:49:45 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEAB132695; Thu, 10 Aug 2017 04:49:45 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 76so11627422ith.0; Thu, 10 Aug 2017 04:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=p5yc7Y60d/fws9tzOncYqRHxVR1gr05h2SywuIkPkfE=; b=bPGRRjpfBJgjbf+zi0H5uZa/7XgaareL7PsgG17J8zIHG9VUvn9sC+xru4DyCFwZf4 7xopclTzNLtRswNz1DMXvTRBDXGJyjkiIstPnjupML19yeU/z/gCg6i9crPnEhe6Pv8V ZwiVtZEFnloRMxCe0nN5QXufljL3cqKXsYHhDp9ZwiaIr8X0HjumYchxA2eHYx/i9JnV G4whADNCfK7kBcOB9aSL6k6ki8+SX0PJeC2WiFSlH7Go2W7PegkO1MWMbsu4LYy7BHSP G3GMxhWmIH4U+IjUP9x9LBCGPuntzZEl42QPa3XQT8e8YB63wXbvvjntCqSZASqXDATh 2OVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p5yc7Y60d/fws9tzOncYqRHxVR1gr05h2SywuIkPkfE=; b=b11g0hGxl3VJ62PU22VHstVhAKip1qDUfDhz/PwvMBEO1dOaOKDwDV/VEjqtsbtNAK 1FApHlCWTOdeiQ1n72/R3kew1UfNxw2EXiVvRrxV9NKGD67mC5DSzQmyEogFensq10jR C6ECTGyN+9mfEdRHwZ0bJmkZ2e1J+zzLBVEjjGTnQeR3uRRZXVXJciYiEWvkEu69PKVe ria9n9m33XfVR1/Yf2CnrtlRqoqYCjggJ/PFpciqbae/ahYLyB/FL1x2IPORPSzR48xi zkMB5DJ713lejjQP29cIS3LI82x1WS+Azifk0vqfLDpqRJ62ny/gONcsV+UYceBDxP0w SRtg== X-Gm-Message-State: AIVw113WvM/e+iv7uKUiOSFBenE4ANW8dvXvNZUiZGI0Peq4kxQryAZS 6ztTAu/mIPLzktKk X-Received: by 10.36.213.131 with SMTP id a125mr2930118itg.74.1502365784421; Thu, 10 Aug 2017 04:49:44 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com (184-14-212-55.dr03.chtn.wv.frontiernet.net. [184.14.212.55]) by smtp.googlemail.com with ESMTPSA id l191sm3169543itl.13.2017.08.10.04.49.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 04:49:43 -0700 (PDT) To: dcrocker@bbiw.net, art@ietf.org Cc: "dnsop-chairs@ietf.org" References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> From: Tim Wicinski Message-ID: Date: Thu, 10 Aug 2017 07:49:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <426c7855-76f7-accf-52e0-45480c778ca4@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] draft-ietf-dnsop-attrleaf X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 11:49:47 -0000 On 8/2/17 1:18 PM, Dave Crocker wrote: > > Howdy. > > (Posting this on ART, since that's got the active thread on attrleaf, > for the moment.) > > Thanks for the thoughtful comments on the draft. > > I've been mulling over the challenges of this registration topic for > more than a decade, constantly being hoisted on the petard of > > I've come to the conclusion that "accommodating" the established > registration practices is a fundamentally wrong path. The only way to > solve a problem of multiple registration authorities is to create a > single registration authority. > > That is, the right path is to create a simple and obvious registration > model, and, separately, go back and fix the problematic documents. > > Therefore I propose to: > > 1. Have this document define the simple, sole, authoritative > mechanism for registering "top-level" (global scope) underscore names. > > 2. Create a separate document that specifies modifications to the > SRV and URI documents, rationalizing the use of underscore names, > through the mechanism defined in -attrleaf-. Dave As the DNSOP Chair who has been pestering you regularly to keep working on this pragmatic approach to the problem, I would agree. (as well the comments from others) tim From nobody Wed Aug 16 21:01:36 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D80E1323B3 for ; Wed, 16 Aug 2017 21:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com 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 JhJt_5-tNbKF for ; Wed, 16 Aug 2017 21:01:25 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C853132638 for ; Wed, 16 Aug 2017 21:01:25 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 77so26245695itj.1 for ; Wed, 16 Aug 2017 21:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:to:cc:from:subject:message-id:date:user-agent:mime-version; bh=HJReBivBbxREQARSPTT6bK88QxDstOa+HuXiVBWagG4=; b=bBsNSp1giHxSgdhrTq1Ahq0YI2UKwRsNbuh8zNBeBoLrMSlaePYawiaThF3V89jIvl yW6ZMTiJ0phgmWzv/MBVKSljSHfJX/Px/QAcRgIhpzpBvYteTWteUC2QYLSzHGt6Etbh IJuDni2jSR9XOhIJ8jjMJt7ad6shq0iYgi/Hc2dVDZXGGdV+vk1tiEL1SO0/D4WrEMCo uDLN4Q9UgX+Ut3quCf+tcRW8awj3nzyz5o1VYYfcYjvFD9xcz3XVvKg/kxArnEWxWd0N Rm43pWydZHUYdp+GSPMWyUk1vok2toYyPfmUI9XoG170AZXwSjVoEp7KDehxICSSAOsh CX4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:cc:from:subject:message-id:date :user-agent:mime-version; bh=HJReBivBbxREQARSPTT6bK88QxDstOa+HuXiVBWagG4=; b=lAFw7ZP+wYu7MetWd/bHboXeyGA7ziDWakCnslFfkEYGjz5p1hGQyy8t+0k5LmKFzR 8cAdAECAApFrKCieAAogwZm4MnOVEy7jajRYK1yIccOwHBvkOTKBwBeOO9zeDmT/fGs6 3VmRumBEfoCuiK8uNjT4XDaC316YqqW9yWhFvbpxND39xJzyv5gCIqthwOBwjNSSYm+s s4BV5ExYsjS7hnLPom2KMblF/lI4amHjS9xgVPHm9qKvCuxsjvlE+/ACwOhRh7KH0kOs W1pSaoqWbtF/BwWD70ZVrbGjfafa63UrC5WWlgeNStisQdWOMVRLSgCvuwOFQaTDRvp2 SpQg== X-Gm-Message-State: AHYfb5iWYJ53y0b71b4xNT63VbpmkmCGKvDMOYQQF5S/i6SC/6OGFwhq 1owK7gqPw2/PsJdq X-Received: by 10.36.74.213 with SMTP id k204mr618679itb.53.1502942484607; Wed, 16 Aug 2017 21:01:24 -0700 (PDT) Received: from [192.168.29.239] (c-73-217-32-196.hsd1.co.comcast.net. [73.217.32.196]) by smtp.gmail.com with ESMTPSA id w207sm1243107itc.34.2017.08.16.21.01.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 21:01:24 -0700 (PDT) Sender: Matthew Miller To: ART Discussion Cc: Bradley Meck From: "Matthew A. Miller" Message-ID: <44b032b4-5bc0-30f8-e264-6afae7ba7053@outer-planes.net> Date: Wed, 16 Aug 2017 22:01:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="13e30cgb6FUIlH4Lfbi2SR9EUuUFfmDLq" Archived-At: Subject: [art] Working on ECMAScript Media Types Updates X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 04:01:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --13e30cgb6FUIlH4Lfbi2SR9EUuUFfmDLq Content-Type: multipart/mixed; boundary="IMeMpBhNLHq5n3GtCfmjs3KfpO11osDNo"; protected-headers="v1" From: "Matthew A. Miller" To: ART Discussion Cc: Bradley Meck Message-ID: <44b032b4-5bc0-30f8-e264-6afae7ba7053@outer-planes.net> Subject: Working on ECMAScript Media Types Updates --IMeMpBhNLHq5n3GtCfmjs3KfpO11osDNo Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello all, This is to let you all know we're working on an update to RFC 4329 to have the ECMAScript/JavaScript media types match up with current reality. The initial revision is adding another file extension (.mjs) and fixing up some other bits and bobs. The document is < https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs >. Issues can be filed on the GitHub repository at < https://github.com/bmeck/I-D/issues >. We ask that discussion about the draft occur on < json@ietf.org > for now= =2E Thanks, --=20 - m&m Matthew A. Miller --IMeMpBhNLHq5n3GtCfmjs3KfpO11osDNo-- --13e30cgb6FUIlH4Lfbi2SR9EUuUFfmDLq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZlRUTAAoJEOz0ck4QngW7FjwIAIjmKuT+0Q0dMM+0xbMuGYL7 HYSJyq1gyNJNqrel3h/qLFLpNR3KMjPpZV9B1p0ClxgqMEDCmRZnH9LKC9EamWiK /eYxgpQ4dJz0G3Fb06PRuKBlSSC2veAvf9Em+0gm08zHUYefxYMtY6ZVsrIUC/Qc yOG9GIqGwzLMqVjgV5aq9xIC9B8fh+nDyGXxfdZ+zGd8xrmvfTiFvwV5wBwx6Eul oigdjdoYx1UZ2tOfACwN1TL3x/rEcTo0zc9JjfFzO0j0czmPN6VntwTnf+WJvp9O 6vesSb1If3XMFwbuUAtbtfEqGQhwq3oWidkInhqXxB9q9GHKZbrhZEFx4axaKbk= =f9XU -----END PGP SIGNATURE----- --13e30cgb6FUIlH4Lfbi2SR9EUuUFfmDLq-- From nobody Sun Aug 27 09:19:58 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5631132328; Sun, 27 Aug 2017 09:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=arcanedomain.com 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 7qxFBHp-ancB; Sun, 27 Aug 2017 09:19:55 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0E6132937; Sun, 27 Aug 2017 09:19:55 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 7F39D5BE066; Sun, 27 Aug 2017 09:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=pBQ8KrWc2ojEU5PxHVVS3crnsf8=; b=IFCtJvRN5S3 ifFM6+dhnuDm1BYwhGQFbx1YhQtaB2F9F4OkgotFcH6Oc0Bqb7G0uwFTM6WEhcFM 1gGxMdveEfT1a+PAa6CIM361QTwZoXAlBlQ7cRJSXOLfDoXCLz1nNCujCnsHUnsC ZyhMX+TWV6MeT2SyNUleIMKpwtt7rtKk= Received: from [192.168.1.101] (216-15-112-214.s4564.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com [216.15.112.214]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 046995BE064; Sun, 27 Aug 2017 09:19:53 -0700 (PDT) To: David Booth Cc: "art@ietf.org" , "uri-review@ietf.org" , "dispatch@ietf.org" References: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net> From: Noah Mendelsohn Message-ID: <700104d3-4be3-56d9-31c4-8252315a2c2e@arcanedomain.com> Date: Sun, 27 Aug 2017 12:19:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [art] [Uri-review] [dispatch] Internet-Draft: Using URIs With Multiple Transport Stacks X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2017 16:19:57 -0000 On 8/3/2017 6:21 PM, David Booth wrote: > It sounds to me like the history that you just explained in email would be > a perfect addition to those draft documents, as an editor note, so that > people who find them can more easily understand their context. Maybe. What I wrote in the email is just my recollection of what happened more than ten years ago; I'm not 100% sure other TAG members would have seen it the same way at the time or would recall it the same way now. Perhaps it would be better to record a briefer note that there was some history of difficulty in reaching consensus on the connection between URI schemes and protocols, perhaps with a link to my email as background reading? In any case, I have no strong feelings about what should be done now. Noah From nobody Wed Aug 30 14:32:09 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909C5132980 for ; Wed, 30 Aug 2017 14:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=IpQIDpZb; dkim=pass (1024-bit key) header.d=chromium.org header.b=IKFDqTKz 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 OOrsHfJXCSID for ; Wed, 30 Aug 2017 14:32:05 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8AC1321F1 for ; Wed, 30 Aug 2017 14:32:05 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u26so18193619wma.0 for ; Wed, 30 Aug 2017 14:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=bXZyhn653mYfRB9IYFOE9I8psfljvby10kddN7Wzaqk=; b=IpQIDpZb/gy7STCEe8cMomrylM0yKScub85zYsKXI299vp/uQGkZ9JqiM2KvqOUV0e 6ETCvZX4X9Y9RaVZWXfV+4JKBWrP5dzwORoMbc4nHWEqtBO4jaCQUx0y3/Y4bNHYcLFR eeMj2XSGdFDl0lRxHuwD6kB+k+c1Pu4V8bt8VeuUduWwIFgsOutz7rmdu9vXCXIQkPtW nagMpobtoKazCxZhSZC6DYx1Te0Z6NRqL0ApOrDn2PQ5zNV+CQo43HmYF10u3KGRSGBs NikYqs5hHKcCTl2f6W5DD6OBQVDEuK8/lZliO852y17A6jYM6Bjv4oA0vkuES1DJrCSC +7kg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to; bh=bXZyhn653mYfRB9IYFOE9I8psfljvby10kddN7Wzaqk=; b=IKFDqTKz4HenC6efCQjMZ5Xs26unhzT3Pc1NGV64E8TqofF7HM2MbAyngMV4/fo8uP /KFY4aqZo/2bZgm7FrFQn4Rb//k5AFg5LQyUeIPFOYZwAUgj9FYqV8O/rCSSwygfFTY7 +5Kvjyc7FoKuNBxiHjPjNKPtvsK0drhcA2kIg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=bXZyhn653mYfRB9IYFOE9I8psfljvby10kddN7Wzaqk=; b=aQghVdBLmGbIYgRJYPDXBBecxlkEn+pBWEPl2mqk8DnzOScc+Z73ySmouoGHaQQ22s jCT/ggbv/g8wTE5Y9DKhmzQ0U0XeVmC9pOQvJvQximko0vItTkKzWvobOUEUW3tQ6LT2 TUJBX3SFy/8wh4aWOso1FW7jH9NAmnJNPNkOUwDclX+ZRMbsfy3I2+XRof61FIgTMdEZ 2O6cn6lN5/GsR3QQ0GMKPTxZUOjIVbrNueavvN2ou4NM9vzehg22gnpoqscyuRHNprg3 jEcRI6kFMYYeEi/7ixYMOCSxSbVQQoShph1fbTDtq73fI+qbFV/9ROruHtupDHAWG5Js IpRg== X-Gm-Message-State: AHYfb5g6fG8WRZJSNVLp6SyjKY0s+TeNxCiz22sb7cMIiAbPSUPvIDL6 YcQcm3sApdri/rMbRLFCy7G11dZYgMgk1kaU8A== X-Google-Smtp-Source: ADKCNb7c9EVT632e+KANRUCAa283MK2N2GwbyMd/M1DsiYVGOBU4YslWAyUJqMj4gW9p387T3EblryGqccHgS9A26mY= X-Received: by 10.28.206.7 with SMTP id e7mr2388241wmg.91.1504128723140; Wed, 30 Aug 2017 14:32:03 -0700 (PDT) MIME-Version: 1.0 Sender: jyasskin@google.com Received: by 10.28.27.72 with HTTP; Wed, 30 Aug 2017 14:31:42 -0700 (PDT) From: Jeffrey Yasskin Date: Wed, 30 Aug 2017 14:31:42 -0700 X-Google-Sender-Auth: RRvifr1MYyyU1kdjEB2sjnfy-Kw Message-ID: To: art@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [art] Web Packaging use cases X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 21:32:08 -0000 As discussed in the IETF99 DISPATCH session (https://datatracker.ietf.org/doc/minutes-99-dispatch/), I wrote up a description of the use cases that we're hoping to solve with a way to sign and bundle websites: https://tools.ietf.org/id/draft-yasskin-webpackage-use-cases-00.xml. What do folks here think? Do you have other use cases you'd like us to pursue? Do you think we should drop some of the use cases I've listed? Have I missed any requirements implied by these use cases? Are any of the requirements I've listed actually unnecessary? Thanks, Jeffrey