From internet-drafts@ietf.org Tue Oct 2 03:03:36 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E0221F89C3; Tue, 2 Oct 2012 03:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHk4n1kFK9ze; Tue, 2 Oct 2012 03:03:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FDA21F8666; Tue, 2 Oct 2012 03:03:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121002100335.28769.57905.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 03:03:35 -0700 Cc: salud@ietf.org Subject: [salud] I-D Action: draft-ietf-salud-alert-info-urns-07.txt X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:03:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sip ALerting for User Devices Working Gro= up of the IETF. Title : Alert-Info URNs for the Session Initiation Protocol (SIP) Author(s) : Laura Liess Roland Jesske Alan Johnston Dale R. Worley Paul Kyzivat Filename : draft-ietf-salud-alert-info-urns-07.txt Pages : 39 Date : 2012-10-02 Abstract: The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-salud-alert-info-urns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-salud-alert-info-urns-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-salud-alert-info-urns-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From laura.liess.dt@googlemail.com Tue Oct 2 03:53:21 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC10321F8A8D for ; Tue, 2 Oct 2012 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfcNZ1KpAttO for ; Tue, 2 Oct 2012 03:53:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E794521F8A8C for ; Tue, 2 Oct 2012 03:53:20 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so7286360vbb.31 for ; Tue, 02 Oct 2012 03:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=etnRccXnq92wYCvyQpUf3BeEe594pmGVWsx8iTzw9qo=; b=T9K5IqHVYvAAxKJDBeUXFqnFQhFNX3bVGoL1SPnSEtK+pMyb4di8Grb3zbm2px8Hbu MOVpsFDCAVgE4+sU5u87KwQMve2vke80g6oVlE1PXummExEB7q1xBkDLwvY85H0EVCIW uYYFEpXaC44PjyWk3JPOrogdTRmR+9mdfNzejUG24dftwWYsUC4nEq1n5YeGm4PpfH7c 71ePC+9LZ7T5u1W+qDO4bJntwvfQ2Ossk5nk2KOJp5oU2wl1k7aBNw44nYSglnE9EreG XfSo30rpUS8aVF5bwDaFWgqwTVxR7dao6WzbNM8Kpb0YwR6Ci3Klcg/F06OE6olobRuL /9ZQ== MIME-Version: 1.0 Received: by 10.52.27.171 with SMTP id u11mr8263257vdg.31.1349175200222; Tue, 02 Oct 2012 03:53:20 -0700 (PDT) Received: by 10.58.132.171 with HTTP; Tue, 2 Oct 2012 03:53:20 -0700 (PDT) Date: Tue, 2 Oct 2012 12:53:20 +0200 Message-ID: From: Laura Liess To: salud@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [salud] Changes for the new version draft-ietf-salud-alert-info-urns-07 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 10:53:22 -0000 Hi, I submited a new version of the draft, mainly because the old version expires soon. The main change is in Section 4, addressing Alfred's comment http://www.ietf.org/mail-archive/web/salud/current/msg00236.html. There are also minor editorial comments. Alfred's comments concerning s are not adressed in this version because this issue is still open. The authors will come up with proposal(s) soon. Thank you Laura ---------- Forwarded message ---------- From: Date: 2012/10/2 Subject: [salud] I-D Action: draft-ietf-salud-alert-info-urns-07.txt To: i-d-announce@ietf.org Cc: salud@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip ALerting for User Devices Working Group of the IETF. Title : Alert-Info URNs for the Session Initiation Protocol (SIP) Author(s) : Laura Liess Roland Jesske Alan Johnston Dale R. Worley Paul Kyzivat Filename : draft-ietf-salud-alert-info-urns-07.txt Pages : 39 Date : 2012-10-02 Abstract: The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-salud-alert-info-urns There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-salud-alert-info-urns-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-salud-alert-info-urns-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud From worley@shell01.TheWorld.com Tue Oct 2 07:59:08 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8A921F852A for ; Tue, 2 Oct 2012 07:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9c3NDGdoeuF for ; Tue, 2 Oct 2012 07:59:07 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 785A321F8528 for ; Tue, 2 Oct 2012 07:59:07 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q92EwC55020406 for ; Tue, 2 Oct 2012 10:58:14 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q92EwCof3844491 for ; Tue, 2 Oct 2012 10:58:12 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q92EwB2q3855585; Tue, 2 Oct 2012 10:58:11 -0400 (EDT) Date: Tue, 2 Oct 2012 10:58:11 -0400 (EDT) Message-Id: <201210021458.q92EwB2q3855585@shell01.TheWorld.com> From: Dale R Worley To: salud@ietf.org Subject: [salud] Test 3 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:59:08 -0000 Test 3 Testing to see that I can post to Salud from this account. Dale From worley@shell01.TheWorld.com Tue Oct 2 08:10:22 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D477F21F84A0 for ; Tue, 2 Oct 2012 08:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXmuvS89Loos for ; Tue, 2 Oct 2012 08:10:22 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 00ED321F847D for ; Tue, 2 Oct 2012 08:10:21 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q92FAAeB003247 for ; Tue, 2 Oct 2012 11:10:12 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q92FAArj3853986 for ; Tue, 2 Oct 2012 11:10:10 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q92FA9kY3854152; Tue, 2 Oct 2012 11:10:09 -0400 (EDT) Date: Tue, 2 Oct 2012 11:10:09 -0400 (EDT) Message-Id: <201210021510.q92FA9kY3854152@shell01.TheWorld.com> From: Dale R Worley To: salud@ietf.org Subject: [salud] Expert opinions on the Salud URN namespace X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:10:22 -0000 [as an individual] This is a summary of feedback I received from experts regarding the Salud URN scheme at IETF-84. People I talked to regarding Salud URNs at IETF-84: Andrew Newton, urnbis co-chair (Alfred Hoenes is the other co-chair) Barry Leiba, applications area AD, who supervises the urnbis WG Mark Nottingham, liaison between IETF and W3C regarding URI issues John Klensin, who has been around the IETF for years The first point that was made clear to me is that Alfred Hoenes' criticisms are quite mainstream; there is a strong principle that URNs should have meanings that are fixed over the long term, and that this will be enforced by the IESG. One suggestion that was raised by the experts is that we might recast the URNs as a new scheme of URIs, changing them from "resource names" to "resource identifiers". The requirements on "identifiers" are far less strict, although creating a new schema of them is considered a larger action. Unfortunately, other experts pointed out that a new URI scheme is unlikely to be approved either. The main reason is that our URNs do not identify a specific object in the sense that people desire for "resources". In particular, there is a sense that a URI identifies a "resource" only if there are multiple actions that can be done to that resource, but the only thing that can be done with Salud URNs is to render them as an alerting signal. Salud URNs can not be used by a process to obtain further information via any sort of resolution process (unlike, say, HTTP and SIP URIs). All of this suggests that the current design approach of encoding all of the alerting information into a URN namespace will not be approved by the IESG. I can list a number of alternatives that have been suggested. (In most cases, I can't remember who suggested which alternative, so I can't give people proper credit.) * Alfred H. suggested the possibility of qualifying private names with a date/time, to provide a unique mapping from the private name to the responsible organization. (I fear that this might not pass IESG vetting, though, because there still is no registration or resolution process for private names.) * Move the alerting specification into an entirely new header whose value is a string, rather than a series of URNs. * Move the alerting specifications into one or more header parameters of the Alert-Info header, whose values are strings. * Leave the standardized alerting URNs as they are, but move the private name subcomponents into a header parameter on the URN. And change any URNs for "private subtrees" into a fixed URN with a header parameter carrying the private components. The last three approaches would make it possible to move all the standardized URNs into the urn:ietf:params subtree, although I am not sure whether we would want to do so. There are certainly additional approaches worth looking at. Dale From pkyzivat@alum.mit.edu Tue Oct 2 08:49:07 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C5C21F84FD for ; Tue, 2 Oct 2012 08:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgvFfEN8ysdf for ; Tue, 2 Oct 2012 08:49:07 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8E521F84DD for ; Tue, 2 Oct 2012 08:49:07 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 6CYN1k0021YDfWL5BFpByl; Tue, 02 Oct 2012 15:49:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 6FjV1k01F3ZTu2S3gFjWx0; Tue, 02 Oct 2012 15:43:30 +0000 Message-ID: <506B0BC4.4050705@alum.mit.edu> Date: Tue, 02 Oct 2012 11:44:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: salud@ietf.org References: <201210021510.q92FA9kY3854152@shell01.TheWorld.com> In-Reply-To: <201210021510.q92FA9kY3854152@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Expert opinions on the Salud URN namespace X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 15:49:08 -0000 On 10/2/12 11:10 AM, Dale R Worley wrote: > Unfortunately, other experts pointed out that a new URI scheme is > unlikely to be approved either. The main reason is that our URNs do > not identify a specific object in the sense that people desire for > "resources". In particular, there is a sense that a URI identifies a > "resource" only if there are multiple actions that can be done to that > resource, but the only thing that can be done with Salud URNs is to > render them as an alerting signal. Salud URNs can not be used by a > process to obtain further information via any sort of resolution > process (unlike, say, HTTP and SIP URIs). I am confused by this. The examples you list of things that can be resolved are not URNs. URI - identifier URL - locator URN - name Contrast with the service URN. What can you do with that? It names a service. You can give it to somebody that knows where to find such a service. Contrast to ISBN URN. It names a book. Not a particular instance of a book, just a class of books that are all in terms of content and form. What can you do with it? Use it as a key to look up stuff about the book. So what can you do with an alert urn? You can identify an alert you would like to have rendered by someone you are calling. You can identify an alert you would like to have rendered by someone who is calling you. You can identify an alert as part of specifying a policy for handling calls. You can use it as a key to look up (in IANA) the description of the semantics of the alert. So I don't understand why this cannot be a URN. Thanks, Paul From laura.liess.dt@googlemail.com Tue Oct 2 23:19:58 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF35621F86B1 for ; Tue, 2 Oct 2012 23:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeTBhwsa5C6b for ; Tue, 2 Oct 2012 23:19:57 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A379221F86B0 for ; Tue, 2 Oct 2012 23:19:57 -0700 (PDT) Received: by iado25 with SMTP id o25so1137143iad.31 for ; Tue, 02 Oct 2012 23:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXoXWOrwECXj8iXyu3kaPsXhmxpoZnjqdz0Too+H7J4=; b=0qgO2k9rsGqQYUz6z0rKKiCTLONTxM8NsVqC70O3UE9OEyWS4bxjFsGpt/n1H8jr/7 0vQSd1fCHsD2rwE3KDT5nEk7z7BC280Ii0gHEuA4rglJ0CfSsiXYtllxBXo+HFqC9tAX 3bV1LiPBwXhQiE4OzwnqlvY4qNegYZrPVeLgQCUNuK/z3Vk4pIHza4De6I05Oejv3K3v w8VbL2hMEPmdhnQP+Rwaw+3Ltq8oFzLaYo4/AoJByIpGM/ibyuLN+DbroMfUl1ZvW/bm MccmbVZCa6BSa7rBpN9vxbvnw0qBLBQW8+MJgc2ygyorqg1ZnZXpwa5Yb3p/uba58iG9 oy4g== MIME-Version: 1.0 Received: by 10.50.10.131 with SMTP id i3mr948801igb.10.1349245194204; Tue, 02 Oct 2012 23:19:54 -0700 (PDT) Received: by 10.231.9.204 with HTTP; Tue, 2 Oct 2012 23:19:54 -0700 (PDT) In-Reply-To: <201210021510.q92FA9kY3854152@shell01.TheWorld.com> References: <201210021510.q92FA9kY3854152@shell01.TheWorld.com> Date: Wed, 3 Oct 2012 08:19:54 +0200 Message-ID: From: Laura Liess To: Dale R Worley , "Dale R. Worley" Content-Type: text/plain; charset=ISO-8859-1 Cc: salud@ietf.org Subject: Re: [salud] Expert opinions on the Salud URN namespace X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 06:19:58 -0000 Dale, Thank you for doing this work. An additional proposal: My understanding is that their main concern is not so much the new URN NID itself ( Alfred's high level concern) but the part, which seems now also to me to be in contradiction with the URN Definition in RFC 2141: "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers..." I came across http://tools.ietf.org/html/rfc4198 "A Uniform Resource Name (URN) Namespace for Federated Content". My proposal is to to spliting the draft in: - a standard-track draft which defines standard Alert-Info URNs: going ahead with the original draft but without private names, if the urnbis people agree to it and - a second draft, maybe informational,which defines "federated Alert-Info URNs" based on RFC 4198, of the form urn:fdc:example.com:2002:alert:private-alert-identifier where has the same ABNF-syntax as in the first draft but the namespace is managed by an organization. We already have an algorithm on how to handle combinations of URNs, so we can combine standard and private Alert-Info URNs. Examples: - Instead of Alert-Info: urn:alert:service:com.example.2012:foo:bar (or Alert-Info:urn:alert:service:foo@example.com.2012:bar as discussed on the ML yesterday) we could have Alert-Info:urn:fdc:example.com.2012:alert:service:foo:bar - Instead of Alert-Info:urn:alert:service:recall:transfer:com.example.2012:foo we could have Alert-Info:urn:alert:service:recall:transfer, urn:fdc:example.com.2012:alert:service:recall:transfer:foo The examples are quick shots, maybe wrong, but mayybe we can use RFC 4198 or at least their model. Thanks a lot Laura 2012/10/2 Dale R Worley : > [as an individual] > > This is a summary of feedback I received from experts regarding the > Salud URN scheme at IETF-84. > > People I talked to regarding Salud URNs at IETF-84: > > Andrew Newton, urnbis co-chair (Alfred Hoenes is the other co-chair) > Barry Leiba, applications area AD, who supervises the urnbis WG > Mark Nottingham, liaison between IETF and W3C regarding URI issues > John Klensin, who has been around the IETF for years > > The first point that was made clear to me is that Alfred Hoenes' > criticisms are quite mainstream; there is a strong principle that URNs > should have meanings that are fixed over the long term, and that this > will be enforced by the IESG. > > One suggestion that was raised by the experts is that we might recast > the URNs as a new scheme of URIs, changing them from "resource names" > to "resource identifiers". The requirements on "identifiers" are far > less strict, although creating a new schema of them is considered a > larger action. > > Unfortunately, other experts pointed out that a new URI scheme is > unlikely to be approved either. The main reason is that our URNs do > not identify a specific object in the sense that people desire for > "resources". In particular, there is a sense that a URI identifies a > "resource" only if there are multiple actions that can be done to that > resource, but the only thing that can be done with Salud URNs is to > render them as an alerting signal. Salud URNs can not be used by a > process to obtain further information via any sort of resolution > process (unlike, say, HTTP and SIP URIs). > > All of this suggests that the current design approach of encoding all > of the alerting information into a URN namespace will not be approved > by the IESG. > > I can list a number of alternatives that have been suggested. (In > most cases, I can't remember who suggested which alternative, so I > can't give people proper credit.) > > * Alfred H. suggested the possibility of qualifying private names with > a date/time, to provide a unique mapping from the private name to > the > responsible organization. (I fear that this might not pass IESG > vetting, though, because there still is no registration or > resolution > process for private names.) > > * Move the alerting specification into an entirely new header whose > value is a string, rather than a series of URNs. > > * Move the alerting specifications into one or more header parameters > of the Alert-Info header, whose values are strings. > > * Leave the standardized alerting URNs as they are, but move the > private name subcomponents into a header parameter on the URN. And > change any URNs for "private subtrees" into a fixed URN with a > header parameter carrying the private components. > > The last three approaches would make it possible to move all the > standardized URNs into the urn:ietf:params subtree, although I am not > sure whether we would want to do so. > > There are certainly additional approaches worth looking at. > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From laura.liess.dt@googlemail.com Wed Oct 3 00:18:09 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF22721F86AF for ; Wed, 3 Oct 2012 00:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKYnGq1gE+gN for ; Wed, 3 Oct 2012 00:18:08 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C91021F86AB for ; Wed, 3 Oct 2012 00:18:07 -0700 (PDT) Received: by iec9 with SMTP id 9so19136871iec.31 for ; Wed, 03 Oct 2012 00:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8NePuCrkmckivo72L92etenIls+gKi7w67aRGodxL94=; b=xtZuHP6rME1g2FQ8Z1LDl7V4YlOFWSPTWGokyzWgQxj0gbCfiYpKYF8ddz6S5YqvtN KgmBqSdQU1jCNFUnJcvyPKAmtPbb+hkwv0DjMl+axEwZogp9ShSlCxcnR0Cb2jBgqzDE RL2N9TSQOdr6N4VkaQvd10ryE/HoDj8pnRFs9bzVNTsvoJLDwFQOB5XhLCnxr6Qul4xk +QyBVchjAMx9vSgeu1qy0M6IFXwbkI0AgGNdig/uN/Yu6n8HQHam/OWd/S5Qm7Si0DFW M7naYx6RSKJkvO/EN9QzSuooNdqzhsCI0BPxZ3Dv1dhNJoGKm95sElDEG7gnixtU3nBC jJOA== MIME-Version: 1.0 Received: by 10.50.10.131 with SMTP id i3mr1047404igb.10.1349248686643; Wed, 03 Oct 2012 00:18:06 -0700 (PDT) Received: by 10.231.9.204 with HTTP; Wed, 3 Oct 2012 00:18:06 -0700 (PDT) In-Reply-To: <201210021510.q92FA9kY3854152@shell01.TheWorld.com> References: <201210021510.q92FA9kY3854152@shell01.TheWorld.com> Date: Wed, 3 Oct 2012 09:18:06 +0200 Message-ID: From: Laura Liess To: Dale R Worley , "Dale R. Worley" Content-Type: text/plain; charset=ISO-8859-1 Cc: salud@ietf.org Subject: Re: [salud] Expert opinions on the Salud URN namespace X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 07:18:09 -0000 Dale, My main concern with some of the approaches, e.g. swiching to URIs or moving all the standardized URNs into the urn:ietf:params subtree is the backward compatibility issue. At least urn:alert:service:call-waiting has been added to the 3GPP IMS specification some years ago and is now up and running in many systems, mainly customer end devices. Software in customers end devices is difficult or impossible to change, because people block software updates for their end devices. Otherwise any approach which is compatibile with urn:alert:service:call-waiting works for me. Thank you Laura 2012/10/2 Dale R Worley : > [as an individual] > > This is a summary of feedback I received from experts regarding the > Salud URN scheme at IETF-84. > > People I talked to regarding Salud URNs at IETF-84: > > Andrew Newton, urnbis co-chair (Alfred Hoenes is the other co-chair) > Barry Leiba, applications area AD, who supervises the urnbis WG > Mark Nottingham, liaison between IETF and W3C regarding URI issues > John Klensin, who has been around the IETF for years > > The first point that was made clear to me is that Alfred Hoenes' > criticisms are quite mainstream; there is a strong principle that URNs > should have meanings that are fixed over the long term, and that this > will be enforced by the IESG. > > One suggestion that was raised by the experts is that we might recast > the URNs as a new scheme of URIs, changing them from "resource names" > to "resource identifiers". The requirements on "identifiers" are far > less strict, although creating a new schema of them is considered a > larger action. > > Unfortunately, other experts pointed out that a new URI scheme is > unlikely to be approved either. The main reason is that our URNs do > not identify a specific object in the sense that people desire for > "resources". In particular, there is a sense that a URI identifies a > "resource" only if there are multiple actions that can be done to that > resource, but the only thing that can be done with Salud URNs is to > render them as an alerting signal. Salud URNs can not be used by a > process to obtain further information via any sort of resolution > process (unlike, say, HTTP and SIP URIs). > > All of this suggests that the current design approach of encoding all > of the alerting information into a URN namespace will not be approved > by the IESG. > > I can list a number of alternatives that have been suggested. (In > most cases, I can't remember who suggested which alternative, so I > can't give people proper credit.) > > * Alfred H. suggested the possibility of qualifying private names with > a date/time, to provide a unique mapping from the private name to > the > responsible organization. (I fear that this might not pass IESG > vetting, though, because there still is no registration or > resolution > process for private names.) > > * Move the alerting specification into an entirely new header whose > value is a string, rather than a series of URNs. > > * Move the alerting specifications into one or more header parameters > of the Alert-Info header, whose values are strings. > > * Leave the standardized alerting URNs as they are, but move the > private name subcomponents into a header parameter on the URN. And > change any URNs for "private subtrees" into a fixed URN with a > header parameter carrying the private components. > > The last three approaches would make it possible to move all the > standardized URNs into the urn:ietf:params subtree, although I am not > sure whether we would want to do so. > > There are certainly additional approaches worth looking at. > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From worley@shell01.TheWorld.com Wed Oct 3 08:42:07 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B43621F84B8 for ; Wed, 3 Oct 2012 08:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp79LLgwimLR for ; Wed, 3 Oct 2012 08:42:06 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7800221F84AE for ; Wed, 3 Oct 2012 08:42:06 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q93FeWCC023493 for ; Wed, 3 Oct 2012 11:40:34 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q93FaKHa3913210 for ; Wed, 3 Oct 2012 11:36:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q93FaKPf3914449; Wed, 3 Oct 2012 11:36:20 -0400 (EDT) Date: Wed, 3 Oct 2012 11:36:20 -0400 (EDT) Message-Id: <201210031536.q93FaKPf3914449@shell01.TheWorld.com> From: Dale R Worley To: salud@ietf.org In-reply-to: <506B0BC4.4050705@alum.mit.edu> (pkyzivat@alum.mit.edu) Subject: Re: [salud] Expert opinions on the Salud URN namespace X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:42:07 -0000 > From: Paul Kyzivat > > So I don't understand why this cannot be a URN. Well, the argument isn't that clear to me, either. Certainly the urn:ietf:params subtree of URNs do not denote *things* and there is no sort of resolution that can be done with them. But the general implication from what I heard is that creating a new URI scheme for alerts is unlikely to be approved -- this complaint that a "resource" is not identified came up only in the context of a new URI scheme. Dale From worley@shell01.TheWorld.com Wed Oct 3 10:48:14 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A79621F8568 for ; Wed, 3 Oct 2012 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj67M1DNp9Td for ; Wed, 3 Oct 2012 10:48:13 -0700 (PDT) Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 87CBA21F866C for ; Wed, 3 Oct 2012 10:48:12 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q93GLN6A019803 for ; Wed, 3 Oct 2012 12:21:25 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q93GFdo23898015 for ; Wed, 3 Oct 2012 12:15:39 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q93GFdE83885697; Wed, 3 Oct 2012 12:15:39 -0400 (EDT) Date: Wed, 3 Oct 2012 12:15:39 -0400 (EDT) Message-Id: <201210031615.q93GFdE83885697@shell01.TheWorld.com> From: Dale R Worley To: salud@ietf.org In-reply-to: (laura.liess.dt@googlemail.com) Subject: Re: [salud] Expert opinions on the Salud URN namespace X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:48:14 -0000 > From: Laura Liess > > My main concern with some of the approaches [...] > is the backward compatibility issue. At least > urn:alert:service:call-waiting has been added to the 3GPP IMS > specification some years ago and is now up and running in many > systems, mainly customer end devices. [...] And urn:alert:service:normal appears in draft-ietf-bliss-shared-appearances. I would prefer that we can keep something very close to the current design. But it seems to me that moving the "private name" information out of the URNs would be backward compatible. Dale From laura.liess.dt@googlemail.com Thu Oct 4 05:15:01 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C997321F8691 for ; Thu, 4 Oct 2012 05:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dXvxRR1dx4c for ; Thu, 4 Oct 2012 05:15:01 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 195EF21F860D for ; Thu, 4 Oct 2012 05:15:00 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so966307iec.31 for ; Thu, 04 Oct 2012 05:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zpfqb4YdHhSWN28X2rtPz/a8ELpipCQE2MMdVBTYtpI=; b=txw2neARwllbKzAAoUMwNo7WOBzIVP6RuPMVXRh5HTLGifzocHf47hZrVfj0FAzvr6 kHC/v38fK6p0PTUATtkn3SZoTyrSgljIOPqcO3PRCEH0DRVEXpSagsmMiOB1/DptUTM4 6jsl3/s1VkYIsDPKFX6CGq52GBPp+q7eC38HDgbBGofmVfkUcaAayL/a53NzDKOmpbm+ 17o0qy8lsxloGxqIl4OVyo5kTwbNYbxj7hB/9XmQrlP+3ojjOdroAevnkyQfihsVdtXl VYvHIGVBLo2UsertPnLuV/ILZym3pA4d01EsNYMtvhIttM4EPyDPydUHEOi1UxwVCRW3 OiSQ== MIME-Version: 1.0 Received: by 10.50.160.228 with SMTP id xn4mr16336319igb.1.1349352900360; Thu, 04 Oct 2012 05:15:00 -0700 (PDT) Received: by 10.231.9.204 with HTTP; Thu, 4 Oct 2012 05:15:00 -0700 (PDT) In-Reply-To: <201210031615.q93GFdE83885697@shell01.TheWorld.com> References: <201210031615.q93GFdE83885697@shell01.TheWorld.com> Date: Thu, 4 Oct 2012 14:15:00 +0200 Message-ID: From: Laura Liess To: Dale R Worley Content-Type: text/plain; charset=ISO-8859-1 Cc: salud@ietf.org Subject: Re: [salud] Expert opinions on the Salud URN namespace X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 12:15:02 -0000 2012/10/3 Dale R Worley : > > And urn:alert:service:normal appears in > draft-ietf-bliss-shared-appearances. This is correct. I just lost sight of it. > > I would prefer that we can keep something very close to the current > design. But it seems to me that moving the "private name" information > out of the URNs would be backward compatible. I am not aware about any implementation or even specification based on the "private name" mechanism. Laura > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From worley@shell01.TheWorld.com Thu Oct 4 09:28:04 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E384811E80DF for ; Thu, 4 Oct 2012 09:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=-1.895, BAYES_05=-1.11, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKfLNnonFplJ for ; Thu, 4 Oct 2012 09:28:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23C11E80D9 for ; Thu, 4 Oct 2012 09:28:03 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q94GQTVH003421 for ; Thu, 4 Oct 2012 12:26:31 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q94GOfWh3977687 for ; Thu, 4 Oct 2012 12:24:41 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q94GOfHZ3974120; Thu, 4 Oct 2012 12:24:41 -0400 (EDT) Date: Thu, 4 Oct 2012 12:24:41 -0400 (EDT) Message-Id: <201210041624.q94GOfHZ3974120@shell01.TheWorld.com> From: Dale R Worley To: salud@ietf.org Subject: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:28:05 -0000 Here are my thoughts and responses to the messages of the last month: (1) Following Paul regarding the ordering of domain names, since we've dropped the idea of removing individual labels from domain names, it seems clearer to use FQDNs rather than reversed FQDNs. (2) Based on what other people have said, here is another proposal for how to disambiguate FQDNs, suggested by the "fdc" (RFC 4198) namespace: (Thanks to Laura for the reference.) urn:alert:service:call-waiting:example.com~12:special The FQDN is (always) followed by a qualifier, which is a "~" followed by a date in the format YY[MM[DD]]. The entity that defines the following standard-name components is the entity that owned the specified domain name on the specified date. (at 12:00:00 UTC, where MM and DD default to 01, and the century is always "20") - No external information is needed to apply the defaults to the qualifier. An entity needs no other information than its ownership history of the domain name to select a valid qualifier for its use. - There is a rigorous rule for determining what entity is responsible for which components of the URN. We have copied the rule (essentially) from RFC 4198, and I think that Alfred suggested a similar possibility. So it should be possible to get this approved by urnbis and the IESG. - Since there is an objective rule for determining ownership, we can probably avoid the complexity of requiring the users of private-names to register the private-names or the URNs built using them. - In the ordinary case, when the entity has owned a domain name for more than a year, only 3 characters need to be added to the FQDN. This is longer than a simple sequence number, but it is unclear how to allocate sequence numbers. - We can allow for a day-by-day delegation of URNs if needed, by using the MM and DD fields, but that will probably only be done for experimental purposes. We define private-names with the MM/DD fields to be equivalent to the MM/DD fields with the default values, to avoid problems with "two 'different' URNs that mean the 'same' thing". - This syntax avoids splitting the standard part from the private part in any ring-indication, which makes it easier to describe how the interpretation algorithm operates. - I chose "~" (tilde) as the separator character because it is the only URI generic syntax "unreserved" character available. See RFC 3986 section 2.3: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" ALPHA, DIGIT, "-", and "." appear in FQDNs; "_" is forbidden from FQDNs because it can be confused with "-". That leaves "~". I was originally going to use "/", which is prettier, but "/" has syntactic meaning in URIs. - Fixing the century part as "20" gives this syntax an 87-year lifetime, but it should be sufficient for practical use. (3) I like Laura's idea of adjusting the BNF to distinguish which parts of URNs are standard and which are private, even when the parts have the same syntax. (4) In regard to using private names as alert-categories, I think we want to allow that, because in some cases, an implementer will want to invent an entirely new alert-category. (5) I like Laura's idea that each private-name (FQDN) must be followed by at least one standard-name (label), because the FQDN alone does not specify anything in particular. Actually, if we allow private-names to be the final element in a URN, I expect implementers do so. For example, I expect "telephone.com" to create (A) urn:alert:service:call-waiting:telephone.com to mean their own special form of call-waiting signal. And then a year later, they will want to have a second private call-waiting signal, without having properly allowed for extensibility. If we require them to create (B) urn:alert:service:call-waiting:telephone.com:special they are less likely to make this mistake, as (C) urn:alert:service:call-waiting:telephone.com:special2 is the obvious second version. If "telephone.com" was careful, they could have used sub-domain names to provide subdivision of their private-name space, in this manner: (D) urn:alert:service:call-waiting:telephone.com.special (E) urn:alert:service:call-waiting:telephone.com.special2 I am not sure that there is any benefit to be obtained from specifically supporting this technique, as (B) and (D) have the same length. (6) I'm not fond of using "foo@example.com" because it isn't pretty. But maybe I could be convinced. (7) I agree with Paul's idea that multiple FQDNs might appear in a URN. In some cases, I would expect one organization to "extend" the private names of another organization sometimes. And this sort of extension doesn't require any extra processing in implementations. Dale From pkyzivat@alum.mit.edu Thu Oct 4 12:33:47 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E085E1F0423 for ; Thu, 4 Oct 2012 12:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.751 X-Spam-Level: X-Spam-Status: No, score=0.751 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MANGLED_TOOL=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbqOL1+aHqqi for ; Thu, 4 Oct 2012 12:33:47 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D7E341F0424 for ; Thu, 4 Oct 2012 12:33:46 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id 75de1k03116LCl0537Zq3J; Thu, 04 Oct 2012 19:33:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 77UP1k00e3ZTu2S3S7UQHM; Thu, 04 Oct 2012 19:28:24 +0000 Message-ID: <506DE36C.8020305@alum.mit.edu> Date: Thu, 04 Oct 2012 15:28:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: salud@ietf.org References: <201210041624.q94GOfHZ3974120@shell01.TheWorld.com> In-Reply-To: <201210041624.q94GOfHZ3974120@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:33:48 -0000 Minor comments inline. On 10/4/12 12:24 PM, Dale R Worley wrote: > Here are my thoughts and responses to the messages of the last month: > > (1) Following Paul regarding the ordering of domain names, since we've > dropped the idea of removing individual labels from domain names, it > seems clearer to use FQDNs rather than reversed FQDNs. > > (2) Based on what other people have said, here is another proposal for > how to disambiguate FQDNs, suggested by the "fdc" (RFC 4198) > namespace: (Thanks to Laura for the reference.) > > urn:alert:service:call-waiting:example.com~12:special If this can be approved then it isn't too bad. > The FQDN is (always) followed by a qualifier, which is a "~" followed > by a date in the format YY[MM[DD]]. The entity that defines the > following standard-name components is the entity that owned the > specified domain name on the specified date. (at 12:00:00 UTC, where > MM and DD default to 01, and the century is always "20") perhaps it could be defined to allow the century to be optional with default of 20, rather than implied 20. That would require some change to the above syntax to be unambiguous. E.g. CC = DIGIT DIGIT YY = CC MM = CC DD = CC DATE = [CC] YY ["-" MM ["-" DD] ] or DATE = YY [ MM [ DD ]] / CC YY MM DD > - No external information is needed to apply the defaults to the > qualifier. An entity needs no other information than its ownership > history of the domain name to select a valid qualifier for its use. > > - There is a rigorous rule for determining what entity is responsible > for which components of the URN. We have copied the rule > (essentially) from RFC 4198, and I think that Alfred suggested a > similar possibility. So it should be possible to get this approved > by urnbis and the IESG. > > - Since there is an objective rule for determining ownership, we can > probably avoid the complexity of requiring the users of > private-names to register the private-names or the URNs built using > them. > > - In the ordinary case, when the entity has owned a domain name for > more than a year, only 3 characters need to be added to the FQDN. > This is longer than a simple sequence number, but it is unclear how > to allocate sequence numbers. > - We can allow for a day-by-day delegation of URNs if needed, by using > the MM and DD fields, but that will probably only be done for > experimental purposes. We define private-names with the MM/DD > fields to be equivalent to the MM/DD fields with the default values, > to avoid problems with "two 'different' URNs that mean the 'same' > thing". > > - This syntax avoids splitting the standard part from the private part > in any ring-indication, which makes it easier to describe how the > interpretation algorithm operates. > > - I chose "~" (tilde) as the separator character because it is the > only URI generic syntax "unreserved" character available. See RFC > 3986 section 2.3: > > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > ALPHA, DIGIT, "-", and "." appear in FQDNs; "_" is forbidden from > FQDNs because it can be confused with "-". That leaves "~". > > I was originally going to use "/", which is prettier, but "/" has > syntactic meaning in URIs. This works for me. > - Fixing the century part as "20" gives this syntax an 87-year > lifetime, but it should be sufficient for practical use. I wonder if we could make the ~nn optional for an FQDN when the owner is the *first* owner of that FQDN. (But is it even possible to reliably learn if you are the first owner?) Or maybe make it optional if you have been the owner continuously since before 2012. > (3) I like Laura's idea of adjusting the BNF to distinguish which > parts of URNs are standard and which are private, even when the parts > have the same syntax. > > (4) In regard to using private names as alert-categories, I think we > want > to allow that, because in some cases, an implementer will want to > invent an entirely new alert-category. > > (5) I like Laura's idea that each private-name (FQDN) must be followed > by at least one standard-name (label), because the FQDN alone does not > specify anything in particular. > > Actually, if we allow private-names to be the final element in a URN, > I expect implementers do so. For example, I expect "telephone.com" to > create > > (A) urn:alert:service:call-waiting:telephone.com > > to mean their own special form of call-waiting signal. And then a > year later, they will want to have a second private call-waiting > signal, without having properly allowed for extensibility. If we > require them to create > > (B) urn:alert:service:call-waiting:telephone.com:special > > they are less likely to make this mistake, as > > (C) urn:alert:service:call-waiting:telephone.com:special2 > > is the obvious second version. > > If "telephone.com" was careful, they could have used sub-domain names > to provide subdivision of their private-name space, in this manner: > > (D) urn:alert:service:call-waiting:telephone.com.special > (E) urn:alert:service:call-waiting:telephone.com.special2 With FQDNs, that would be special.telephone.com & special2.telephone.com > I am not sure that there is any benefit to be obtained from > specifically supporting this technique, as (B) and (D) have the same > length. > > (6) I'm not fond of using "foo@example.com" because it isn't pretty. > But maybe I could be convinced. Depends on your measure of "pretty". :-) I agree it could be a bit confusing in changing the order in which you read things. What I liked about it is that it is a familiar construction for names within a domain. Another thing I liked about it is that it looks like a single entity, and so its intuitive that it dropped as an entity if not understood. So IMO it seems to work more naturally for the rule that each domain name must be accompanied by at least one label. With that syntax we *could* make the "label@" part be optional. (Effectively a label of "".) With or without it becomes a single element that is interpreted or else dropped if unknown. > (7) I agree with Paul's idea that multiple FQDNs might appear in a > URN. In some cases, I would expect one organization to "extend" the > private names of another organization sometimes. And this sort of > extension doesn't require any extra processing in implementations. Exactly. I don't foresee this being used often. But I saw no reason to exclude it. Thanks, Paul From worley@shell01.TheWorld.com Fri Oct 5 10:34:04 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F7D21F865C for ; Fri, 5 Oct 2012 10:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw6kYcRcno3E for ; Fri, 5 Oct 2012 10:34:03 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 05EEA21F864A for ; Fri, 5 Oct 2012 10:34:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q95HWek2015751 for ; Fri, 5 Oct 2012 13:32:42 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q95HWejf4025422 for ; Fri, 5 Oct 2012 13:32:40 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q95HWePi4032978; Fri, 5 Oct 2012 13:32:40 -0400 (EDT) Date: Fri, 5 Oct 2012 13:32:40 -0400 (EDT) Message-Id: <201210051732.q95HWePi4032978@shell01.TheWorld.com> From: Dale R Worley To: salud@ietf.org In-reply-to: <506DE36C.8020305@alum.mit.edu> (pkyzivat@alum.mit.edu) Subject: Re: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:34:04 -0000 > From: Paul Kyzivat > > I wonder if we could make the ~nn optional for an FQDN when the > owner is the *first* owner of that FQDN. (But is it even possible to > reliably learn if you are the first owner?) > > Or maybe make it optional if you have been the owner continuously > since before 2012. This isn't elegant, but: We could make the default year be 2012, so if there is no qualifier at all, the specified time is 12:00 UTC, 1 Jan 2012. In practice, all of the existing equipment manufacturers would never need to use a qualifier. > > If "telephone.com" was careful, they could have used sub-domain > > names to provide subdivision of their private-name space, in this > > manner: > > > > (D) urn:alert:service:call-waiting:telephone.com.special > > (E) urn:alert:service:call-waiting:telephone.com.special2 > > With FQDNs, that would be special.telephone.com & > special2.telephone.com Oops, yes, I got the order wrong. It made more visual sense when we used reversed FQDNs. Dale From pkyzivat@alum.mit.edu Fri Oct 5 11:21:54 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167BB21F87EC for ; Fri, 5 Oct 2012 11:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpYXa6UyeA4K for ; Fri, 5 Oct 2012 11:21:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2FF21F87EA for ; Fri, 5 Oct 2012 11:21:53 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7SNi1k0091uE5Es53WMxep; Fri, 05 Oct 2012 18:21:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 7WH91k00n3ZTu2S3cWH9bd; Fri, 05 Oct 2012 18:17:09 +0000 Message-ID: <506F2414.8080107@alum.mit.edu> Date: Fri, 05 Oct 2012 14:16:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: salud@ietf.org References: <201210051732.q95HWePi4032978@shell01.TheWorld.com> In-Reply-To: <201210051732.q95HWePi4032978@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:21:54 -0000 On 10/5/12 1:32 PM, Dale R Worley wrote: >> From: Paul Kyzivat >> >> I wonder if we could make the ~nn optional for an FQDN when the >> owner is the *first* owner of that FQDN. (But is it even possible to >> reliably learn if you are the first owner?) >> >> Or maybe make it optional if you have been the owner continuously >> since before 2012. > This isn't elegant, but: We could make the default year be 2012, so > if there is no qualifier at all, the specified time is 12:00 UTC, 1 > Jan 2012. In practice, all of the existing equipment manufacturers > would never need to use a qualifier. Ugh! "First owner" would work more broadly. We might spin it that the default year is 1970 (or 2000 if you prefer), and at the same time say that the first owner of a domain is considered to have owned it retroactively back to the default year. I suspect that all of the companies you have in mind are original and continuous owners of their domain - directly or via acquisitions and mergers. Thanks, Paul >>> If "telephone.com" was careful, they could have used sub-domain >>> names to provide subdivision of their private-name space, in this >>> manner: >>> >>> (D) urn:alert:service:call-waiting:telephone.com.special >>> (E) urn:alert:service:call-waiting:telephone.com.special2 >> >> With FQDNs, that would be special.telephone.com & >> special2.telephone.com > > Oops, yes, I got the order wrong. It made more visual sense when we > used reversed FQDNs. > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From worley@shell01.TheWorld.com Mon Oct 8 11:27:11 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E09921F87E1 for ; Mon, 8 Oct 2012 11:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z45vbkPqrvr0 for ; Mon, 8 Oct 2012 11:27:10 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7003821F87C5 for ; Mon, 8 Oct 2012 11:27:08 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q98IQKGP004371; Mon, 8 Oct 2012 14:26:22 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q98IQJDA4228780; Mon, 8 Oct 2012 14:26:20 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q98IQJFQ4222355; Mon, 8 Oct 2012 14:26:19 -0400 (EDT) Date: Mon, 8 Oct 2012 14:26:19 -0400 (EDT) Message-Id: <201210081826.q98IQJFQ4222355@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <506F2414.8080107@alum.mit.edu> (pkyzivat@alum.mit.edu) Cc: salud@ietf.org Subject: Re: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:27:11 -0000 > From: Paul Kyzivat > > > This isn't elegant, but: We could make the default year be 2012, > > so > > if there is no qualifier at all, the specified time is 12:00 UTC, > > 1 > > Jan 2012. In practice, all of the existing equipment > > manufacturers > > would never need to use a qualifier. > > Ugh! > > "First owner" would work more broadly. > We might spin it that the default year is 1970 (or 2000 if you > prefer), > and at the same time say that the first owner of a domain is > considered > to have owned it retroactively back to the default year. I suspect > that > all of the companies you have in mind are original and continuous > owners > of their domain - directly or via acquisitions and mergers. Can one learn from the registar(s) that one is the first owner of a domain name? Dale From pkyzivat@alum.mit.edu Mon Oct 8 11:59:28 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540C421F87BE for ; Mon, 8 Oct 2012 11:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.543 X-Spam-Level: X-Spam-Status: No, score=0.543 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sz5fvEFIrTE for ; Mon, 8 Oct 2012 11:59:27 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7DF21F87B2 for ; Mon, 8 Oct 2012 11:59:27 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8e0K1k00N1ap0As53izXyu; Mon, 08 Oct 2012 18:59:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 8iv11k00G3ZTu2S3iiv1ol; Mon, 08 Oct 2012 18:55:01 +0000 Message-ID: <50732162.60507@alum.mit.edu> Date: Mon, 08 Oct 2012 14:54:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Dale R. Worley" References: <201210081826.q98IQJFQ4222355@shell01.TheWorld.com> In-Reply-To: <201210081826.q98IQJFQ4222355@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: salud@ietf.org Subject: Re: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:59:28 -0000 On 10/8/12 2:26 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >>> This isn't elegant, but: We could make the default year be 2012, >>> so >>> if there is no qualifier at all, the specified time is 12:00 UTC, >>> 1 >>> Jan 2012. In practice, all of the existing equipment >>> manufacturers >>> would never need to use a qualifier. >> >> Ugh! >> >> "First owner" would work more broadly. >> We might spin it that the default year is 1970 (or 2000 if you >> prefer), >> and at the same time say that the first owner of a domain is >> considered >> to have owned it retroactively back to the default year. I suspect >> that >> all of the companies you have in mind are original and continuous >> owners >> of their domain - directly or via acquisitions and mergers. > > Can one learn from the registar(s) that one is the first owner of a > domain name? I just did a little googling, and it seems that domaintools.com has whois history back to 1995 or so. But you have to pay to check it. I don't know how complete it is. But that seems to suggest that it is *possible* to do this. If we wanted to go this way then I guess it would be the responsibility of someone using a domain without a date to verify that they are the original owner. (wink wink) Thanks, Paul From worley@shell01.TheWorld.com Thu Oct 11 12:18:05 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678501F0C59 for ; Thu, 11 Oct 2012 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6onMujWzuJhv for ; Thu, 11 Oct 2012 12:18:03 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8391F0C5F for ; Thu, 11 Oct 2012 12:18:02 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9BJHc07017264; Thu, 11 Oct 2012 15:17:40 -0400 Received: from shell01.TheWorld.com (localhost [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9BJHcUk4410737; Thu, 11 Oct 2012 15:17:38 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9BJHbNY4411524; Thu, 11 Oct 2012 15:17:37 -0400 (EDT) Date: Thu, 11 Oct 2012 15:17:37 -0400 (EDT) Message-Id: <201210111917.q9BJHbNY4411524@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <50732162.60507@alum.mit.edu> (pkyzivat@alum.mit.edu) Cc: salud@ietf.org Subject: Re: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 19:18:05 -0000 > From: Paul Kyzivat > > I just did a little googling, and it seems that domaintools.com has > whois history back to 1995 or so. But you have to pay to check it. > I don't know how complete it is. > > But that seems to suggest that it is *possible* to do this. > If we wanted to go this way then I guess it would be the > responsibility > of someone using a domain without a date to verify that they are the > original owner. (wink wink) I can see several variations might work. I think the principles we need to keep in mind are: - Each syntactic variation needs to have a stable enough meaning to satisfy the URN people. - We need to clearly define which syntactic variations are *abbreviations* of others (and thus are considered equivalent) and which are not. E.g., are "example.com" and "example.com~2000" equivalent or do they just happen to refer to the same organization? - The syntax should provide URN components that are not much longer than the FQDN in almost all of the common cases. - The syntax should be attractive to the eye. - The syntax should correspond to the conceptual structure of the URNs. However, interestingly enough, the colon (":") character generally does not have a special syntactic role in URIs. (See RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax".) In some positions, a colon's presence is important, but in URNs like "urn:ietf:params:xml:ns:copycontrol", the generic syntax ABNF only divides the URN into "urn" and "ietf:params:xml:ns:copycontrol". Dale From pkyzivat@alum.mit.edu Thu Oct 11 13:40:30 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63B51F0C3E for ; Thu, 11 Oct 2012 13:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLy4uEfE6Mve for ; Thu, 11 Oct 2012 13:40:27 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 75D031F0423 for ; Thu, 11 Oct 2012 13:40:27 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id 9mWm1k00B1ei1Bg51wgV3E; Thu, 11 Oct 2012 20:40:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 9wbR1k01S3ZTu2S3kwbRbG; Thu, 11 Oct 2012 20:35:26 +0000 Message-ID: <50772D8A.2030902@alum.mit.edu> Date: Thu, 11 Oct 2012 16:35:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Dale R. Worley" References: <201210111917.q9BJHbNY4411524@shell01.TheWorld.com> In-Reply-To: <201210111917.q9BJHbNY4411524@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: salud@ietf.org Subject: Re: [salud] Thoughts and responses X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 20:40:30 -0000 On 10/11/12 3:17 PM, Dale R. Worley wrote: >> From: Paul Kyzivat >> >> I just did a little googling, and it seems that domaintools.com has >> whois history back to 1995 or so. But you have to pay to check it. >> I don't know how complete it is. >> >> But that seems to suggest that it is *possible* to do this. >> If we wanted to go this way then I guess it would be the >> responsibility >> of someone using a domain without a date to verify that they are the >> original owner. (wink wink) > > I can see several variations might work. I think the principles we > need to keep in mind are: > > - Each syntactic variation needs to have a stable enough meaning to > satisfy the URN people. > > - We need to clearly define which syntactic variations are > *abbreviations* of others (and thus are considered equivalent) and > which are not. E.g., are "example.com" and "example.com~2000" > equivalent or do they just happen to refer to the same organization? The forms that remove default digits from the date can satisfy this rule. So for those a shorter date can be turned into a longer one. And then the comparison rules can always use the long ones. But I don't think the omission of a date for a domain you are the first owner of fits that rule. But IMO that is ok. Similarly, if I own it today, and I still own it tomorrow then I could construct names using either date. They won't compare equal, and I don't think we can/should define rules so that they do. > - The syntax should provide URN components that are not much longer > than the FQDN in almost all of the common cases. I'm trying to get there with the "first owner" approach. I think that will fit most users. > - The syntax should be attractive to the eye. > > - The syntax should correspond to the conceptual structure of the > URNs. Having the domain, with date if needed, being a single element, rather than multiple elements, helps with this. > However, interestingly enough, the colon (":") character generally > does not have a special syntactic role in URIs. (See RFC 2396, > "Uniform Resource Identifiers (URI): Generic Syntax".) In some > positions, a colon's presence is important, but in URNs like > "urn:ietf:params:xml:ns:copycontrol", the generic syntax ABNF only > divides the URN into "urn" and "ietf:params:xml:ns:copycontrol". Thanks, Paul