From dworley@avaya.com Mon Jun 4 14:43:57 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 9ECE511E8113 for ; Mon, 4 Jun 2012 14:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaPF1UEuYuJm for ; Mon, 4 Jun 2012 14:43:57 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9F11E8119 for ; Mon, 4 Jun 2012 14:43:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB4qzU+HCzI1/2dsb2JhbABEtCuBB4IfEihRARUpQicEARoah2maMZxbkEFgA5sNigSCfA X-IronPort-AV: E=Sophos;i="4.75,715,1330923600"; d="scan'208";a="12231523" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Jun 2012 17:41:28 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Jun 2012 17:25:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 4 Jun 2012 17:43:55 -0400 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" , "ah@TR-Sys.de" Date: Mon, 4 Jun 2012 17:43:47 -0400 Thread-Topic: Why have a new URN namespace? Thread-Index: AQHNQpsf5zByTR1wpU28PM3SEKgxaA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [salud] Why have a new 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: Mon, 04 Jun 2012 21:43:57 -0000 [as an individual] We could, in a somewhat natural way, incorporate alert URNs into the urn:ietf tree, or any other tree for that matter. I think that would not be a good idea because we need to define some very detailed rules for how alert URNs are interpreted. And although we could simply define that those rules applied to all URNs that start "urn:ietf:foo:bar", that would be rather unnatural. In order to ensure that alert URNs become widely used in the market, we need to allow manufacturers of existing PBXs to map their current alerting schemes into the alert URNs -- without losing any distinctions that their current alerting schemes now make. Thus, we need a well-developed extension mechanism that does not interfere with interoperation between different manufacturer's devices. The syntax of s, the rules for extensions (section 7), and the rules for combinations (section 8) are all driven by the requirements of the extension mechanism. Indeed, it would be difficult to satisfy the extensibility requirements with rules that are much different than the ones that are given in the draft -- many of those rules are *derived* from the extensibility requirements. Thus, the specific rules for alert URNs are intrinsic to the needed semantics of the alert URNs. Because of this, it is clearest and most natural if the alert URNs are in a namespace of their own. Dale From dworley@avaya.com Mon Jun 4 16:52:37 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 7C35321F8792 for ; Mon, 4 Jun 2012 16:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUywQqcMaM8Q for ; Mon, 4 Jun 2012 16:52:37 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E611621F878E for ; Mon, 4 Jun 2012 16:52:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANhJzU/GmAcF/2dsb2JhbABEtCyBB4IfEihRARUpQicEARoah2maRZxgizGFEGADmw2KBIJ8gTs X-IronPort-AV: E=Sophos;i="4.75,716,1330923600"; d="scan'208";a="12257142" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Jun 2012 19:49:07 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jun 2012 17:25:34 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 4 Jun 2012 17:28:18 -0400 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" , "ah@TR-Sys.de" Date: Mon, 4 Jun 2012 17:27:26 -0400 Thread-Topic: Regarding s Thread-Index: AQHNQpjWFXY834WbJE2Ee/+PPAqE9w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [salud] Regarding s 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, 04 Jun 2012 23:52:37 -0000 [as an individual] This message is to explain the ideas behind the choices for the syntax of in draft-ietf-salud-alert-info-urns. Per Alfred's suggestion, Laura has updated the syntax to handle internationalized domain names. Unfortunately, while SIP allows full Unicode, URNs are restricted to ASCII, so internationalized domain names generate s using their punycode form. The primary purpose of s is to provide a means for telecommunication equipment manufacturers (PBX makers) to represent their proprietary schemes for alerting signals. We think it is necessary to provide such a mechanism because PBX makers already have schemes for alerting and will want to support those schemes using the new mechanism, including aspects of their schemes that are not standardized in the new mechanism. If they cannot completely incorporate their schemes into the new mechanism, the will extend the mechanism with various poorly-organized proprietary extensions. The extensions, URNs containing s, are expected to only be useful when the device that inserts the URN (a UA or proxy) and the device that renders it are from the same PBX maker. In all other situations, we expect the renderer to simply ignore the extension URN. The extension URNs are seen as a set of tokens that can be used by the PBX maker with any meaning that they want. We see no reason that the PBX maker should register their extension URNs, as no other PBX maker will want to interpret them. We expect the PBX makers to be large companies that are capable of maintaining ownership of a domain name for a long time. The extension URNs are not needed as stable names of objects that have a long existence. In use, they are interpreted by the renderer within seconds of being sent by another element. Their only "storage" is in the firmware of the SIP elements that generate and render them, which we expect to have a lifetime of at most a few years. If one device sends a URN that is incorrectly interpreted by another device, the cost is low. At worse, the call has an incorrect alerting signal. Because of this, we don't think it is necessary to add a date-qualifier to the domain-name part of s, as the benefit of more stability in s would be small but millions of SIP messages would be lengthened. Dale From laura.liess.dt@googlemail.com Tue Jun 5 09:40:41 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 7B2F921F8764 for ; Tue, 5 Jun 2012 09:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzX1oegzNWVS for ; Tue, 5 Jun 2012 09:40:40 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F20621F8599 for ; Tue, 5 Jun 2012 09:40:40 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4629272ggn.31 for ; Tue, 05 Jun 2012 09:40:40 -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:content-transfer-encoding; bh=UR0/zzCwSFuZ2X5AX9Z0E5MN263ivHgFFPenUaenKzE=; b=FFi3+xwwN2+7lIDwSVhMTXbblgoKcNR2XCpuceu3oOhtY2FLue3Zg4z2PwY/8Y+aM5 u6aA2yRcfXjpAcnwizjSoF2V0RYmsVDWtgNnw+AB/FoeulKl1M4vcP7pSdyXwUhEX5vB UUajCgqT35k1u+vijA+iUrC6c4+QW/EuGTsV47/d6hPElqNhS1ukK+jbOjNczjbaAW6x DVbmA39+Lmo23NhCTgsy2BCQfmOfpvxBhSKwZiSyJFCmDfJMma0rIVR5E8idy9GFGdDi QOeVg/eujkctUP54c8Kw5vwwxV6L/rbWSH5Fo+SNRvGwAVP9qvbL2so+2QlzDa2ve6m1 m3wQ== MIME-Version: 1.0 Received: by 10.42.155.200 with SMTP id v8mr10993602icw.12.1338914439783; Tue, 05 Jun 2012 09:40:39 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Tue, 5 Jun 2012 09:40:39 -0700 (PDT) In-Reply-To: <201205032021.WAA02119@TR-Sys.de> References: <201205032021.WAA02119@TR-Sys.de> Date: Tue, 5 Jun 2012 18:40:39 +0200 Message-ID: From: Laura Liess To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: salud@ietf.org Subject: Re: [salud] draft-ietf-salud-alert-info-urns / high level concerns 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, 05 Jun 2012 16:40:41 -0000 Alfred, I am sorry for the quite late response to your concern, but we had to discuss the issue in detail. As you recommended, we went through the entries of the IANA URN Namespaces table and we think that no already existing URN namespace would matches the requirements. (I upgraded the "Namespace Considerations" Section text accordingly.) Also there are already existing implementations, in life networks with thousands of SIP users. Please find below the proposal for the upgraded "Namespace Considerations" Section text and let me know what you think of it. Thanks a lot Laura >>>>> Namespace Considerations: This specification proposes URN namespace =93alert=94 for global and persistent names for the semantic of signals or renderings. The particular rendering of an =93alert=94 URN depends then of context in which the rendering is done. Also the primary scope is the usage in the SIP Alert-Info header, the new =93alert=94 URN identifiers can be used not only in IETF-protocols, but also for any telecommunication devices or protocols (standardised by different organizations or proprietary) and for use cases which are not connected to telecommunications. E.g. when an intelligent video device at the house door recognises a family member, it passes urn:alert:source:family to the doorbell which renders a special tone, text, video, vibration or some rendering. There do not appear to be other URN namespaces that serve the same need of uniquely identifying the meaning of a rendering. Unlike most other currently registered URN namespaces, the =93alert=94 URN does not identify documents and protocol objects (e.g., [RFC3044], [RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198], ), types of telecommunications equipment [RFC4152], people or organizations [RFC3043], objects [RFC3061], NewsML News Items [RFC3085], public identifiers [RFC3151], Universally Unique Identifiers for devices [RFC4122]. Also the =93alert=94 URN is not specific for an organization (e.g. IETF [RFC2648], OASIS [RFC3121], WEB3D [RFC3541], MPEG [RFC3614], MACE [RFC3613], FIPA [RFC3616], SWIFT [RFC3615], Liberty Alliance [RFC3622], IPTC [RFC3937], ISAN [RFC4246], NZL [RFC4350], OMA [RFC4358], IVIS [RFC4617], Aerospace and Defence Industries Association of Europe [RFC4688], NFC-Forum [RFC4729], ISO-documents [RFC5141], GEANT [RFC4926], SMTPE [RFC5119], CGI [RFC5138], OGC [RFC5165], EBU [RFC5174], 3GPP [RFC5279], DVB Project [RFC5328], NENA [RFC6061], CableLabs [RFC6289], DGIWG [RFC6288], SCHAC [RFC6338], Open Grid Forum [RFC6453]), specific protocols (e.g. XMPP [RFC4854]), services [RFC5031], Electronic Product Codes [RFC5134], objects and places (ucode [RFC6588]). <<<<<<< 2012/5/3 Alfred H=CEnes : > Dale, > at 26 April 2010, you wrote ... >>> From: ah@TR-Sys.de >>> >>> ... >> =A0... >> >>> a) =A0As soon as time avails, I'll take a closer look at the >>> =A0 =A0 (URN-specific parts of the) current I-D and provide feedback. >> >> That would be good. =A0We are in WGLC ending 8 May. > > I'm a bit late, but eventually I've been able now to start studying > draft-ietf-salud-alert-info-urns-06. > > I copy Leslie Daigle (urn-nid IANA Expert). > > Before proceding and going into details, I'd like to raise my primary > high-level concern and ask you to provide additional information. > (As you know, folks say that someone doing so could be an indication > that something's missing in the draft ...) > Please beware that I don't have the time to follow your WG discussions > and the primary focus of my review is the URN namespace registration > that the I-D intends to perform. > > As it stands, the draft would most likely _not_ pass the urn-nid > Expert Review process (which the PROTO writeup template makes clear > needs to be undergone before the draft can be forwarded to the IESG), > because mandatory sections (per RFC 3406) are missing. > In particular, there are no Community Considerations and Namespace > Considerations sections in the I-D. =A0The draft only contains short > topical paragraphs with such headlines in the registration template; > but RFC 3406 does not specify that -- it calls for solid Sections > in the registration document. =A0The present paragraph for Community > Considerations might do the job, but the Namespace Considerations > are simply much too terse. > > Among the questions to be asked and responded to in such section > would have been _which_ alternate namespaces have been considered and > _why_ no other existing namespace would fulfill the needs/requirements. > > For instance, you want to let IANA manage the new URN namespace. > But IANA already manages a specific URN namespace for IETF protocol > parameters -- see RFC 2648 for URN:IETF and RFC 3553 for the > sub-namespace URN:IETF:PARAMS . =A0Thus, it immediately came to my > mind upon reading the initial sections of the I-D that, e.g., > urn:ietf:params:alert =A0might likely be a proper home for the > intended usage. > If the draft contained the aforementioned sections (per RFC 3406), > it would have had to explain there why a new URN Namespace is needed > and the alert information cannot be placed into a sub-namespace of > URN:IETF:PARAMS (or maybe of URN:IETF, or any other potentially > suitable existing namespace). > > Have such alternatives been considered? > > Note that, if you'd switch to using URN:IETF:PARAMS, you would avoid > the urn-nid Expert Review process entirely and would not need the > RFC 3406 template, but only the much more simple template per > RFC 3553, Section 4, which IMHO would be very suitable in this case. > > > If you can show me that such considerations have taken place and > are documented, the arguments need to be put into the draft; > otherwise, I think this topic would need to be brought to your WG. > > Please give me an indication so I can customize my review comments. > > > >> >>> b) =A0Did you consider the ongoing work of URNbis? >> >> No, it started work well after Salud was going. > > Well, maybe looking into the rfc3406bis draft and the related > discussion might have helped to better understand RFC 3406 > requirements for URN Namespace registration documents. =A0 :-( > >> >> Dale [chair of Salud] >> > > Kind regards, > =A0Alfred. > [co-chair of URNbis] > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes =A0 | =A0Alfred Hoenes =A0 Dipl.-Math., Dipl.-Phys= . =A0| > | Gerlinger Strasse 12 =A0 | =A0Phone: (+49)7156/9635-0, Fax: -18 =A0 =A0= =A0 =A0 | > | D-71254 =A0Ditzingen =A0 =A0 | =A0E-Mail: =A0ah@TR-Sys.de =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > +------------------------+--------------------------------------------+ > From laura.liess.dt@googlemail.com Wed Jun 6 01:25:06 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 593C621F851C for ; Wed, 6 Jun 2012 01:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erRmcCzM-9Zv for ; Wed, 6 Jun 2012 01:25:04 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA121F85A2 for ; Wed, 6 Jun 2012 01:25:03 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5243095ggn.31 for ; Wed, 06 Jun 2012 01:25:03 -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:cc:content-type :content-transfer-encoding; bh=4IAd759QQumIJXe5baITfwWu22QqhCj2GGisPLErRoQ=; b=pVO9WvwgIteIfNOyZjPSdrwkgJ2hdcw/Zd1z9IgWJgEr9TqV9yB9E7M+yAC/pQ0zUZ lx9N0pmjg97myNnpkNJeznAp+bmlYE//G8yhlvA2b4SGTrOmeETpLM3zWWe36c49FHYH E2GcTChOZNgRqKXrIyuVHhLOcnSokN3o+sz39gn22zLpvwDIy0E16cc+PGM0g+IXCdiR +7b2k390j/L4Ehs+xlGALFHsLFQo8B4vlem4XeTIAPX8Wj1ZQzivbQLaE6/93iNb/n09 OzVDVnqXgjXwWUeNDXjmdxTUHacToE+178p41f9bEvo3rcwibBXodybBL7OdNEjPJ1rq TaoQ== MIME-Version: 1.0 Received: by 10.50.197.194 with SMTP id iw2mr5737210igc.31.1338971102748; Wed, 06 Jun 2012 01:25:02 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Wed, 6 Jun 2012 01:25:02 -0700 (PDT) Date: Wed, 6 Jun 2012 10:25:02 +0200 Message-ID: From: Laura Liess To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-salud-alert-info-urns@tools.ietf.org, salud@ietf.org Subject: Re: [salud] draft-ietf-salud-alert-info-urns-06 : issues; Concern #1 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, 06 Jun 2012 08:25:06 -0000 Alfred, For Concern #1, I tried to follow your recommendation: > Defer for