From dworley@avaya.com Wed Feb 8 08:01:49 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 CFFD221F8714 for ; Wed, 8 Feb 2012 08:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeXgYUFAKBjd for ; Wed, 8 Feb 2012 08:01:49 -0800 (PST) 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 2A95821F86BD for ; Wed, 8 Feb 2012 08:01:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOebMk+HCzI1/2dsb2JhbABDr3CBB4FyAQEBAQMSKD8QAgEIDQQEAQEfEDIbAQEFAwEBBA4FCBqmRJQRi0oKCREFAjECAQUFBggDgxOBEw8KAoJbYwSIRpJhjQE X-IronPort-AV: E=Sophos;i="4.73,384,1325480400"; d="scan'208";a="230833315" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Feb 2012 11:01:47 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Feb 2012 10:47:38 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 8 Feb 2012 11:01:47 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Wed, 8 Feb 2012 11:00:59 -0500 Thread-Topic: Confirm that your group is not meeting at IETF83 Thread-Index: AczlzzpgOMVpEoApTe6HxBuGDt3iCAAq58Rl Message-ID: References: <4F317C2B.9080308@nostrum.com> In-Reply-To: <4F317C2B.9080308@nostrum.com> 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] FW: Confirm that your group is not meeting at IETF83 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, 08 Feb 2012 16:01:50 -0000 Salud will not be meeting at IETF 83. Dale ________________________________________ From: Robert Sparks [rjsparks@nostrum.com] Sent: Tuesday, February 07, 2012 2:31 PM To: bliss-chairs@tools.ietf.org; mediactrl-chairs@tools.ietf.org; salud-cha= irs@tools.ietf.org; sipclf-chairs@tools.ietf.org; speechsc-chairs@tools.iet= f.org; Gonzalo Camarillo Subject: Confirm that your group is not meeting at IETF83 The deadline for requesting a meeting session at IETF83 has passed without hearing one way or the other about your groups (see the To: lines). I believe it was the intent for each of these groups to not meet. If that's not the case, let me know. If it is the case, please send a note to your wg list letting people know for sure (and next time, please use the session request tool to let the secretariat know you will not be meeting). RjS From dworley@avaya.com Wed Feb 8 12:08:43 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 DBFAD21E802F for ; Wed, 8 Feb 2012 12:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.35 X-Spam-Level: X-Spam-Status: No, score=-104.35 tagged_above=-999 required=5 tests=[AWL=1.249, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qrGF0CGWNzD for ; Wed, 8 Feb 2012 12:08:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4555321E8020 for ; Wed, 8 Feb 2012 12:08:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA3VMk/GmAcF/2dsb2JhbABDngeRA4EHgXkSKFEBFSlCJwQbGodjmTmEF5tii0oKCREFAjECAQUFBoMegROCdmMEiEaSYY0B X-IronPort-AV: E=Sophos;i="4.73,385,1325480400"; d="scan'208";a="290320938" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Feb 2012 15:08:40 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Feb 2012 15:02:42 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 8 Feb 2012 15:08:39 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Wed, 8 Feb 2012 15:07:18 -0500 Thread-Topic: -05: Mostly editorial issues Thread-Index: AQHM5p1xOBLymmwdakyYazBiz8CYng== 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] -05: Mostly editorial issues 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, 08 Feb 2012 20:08:44 -0000 [as individual] I'm finally starting to read Laura's new -05 draft, and clearly we are getting close to finished. This message mentions a number of minor points. Overall I don't know how URN namespaces are properly organized. It seems to me that section 4 (the namespace registration template), section 5 (the defined values of alert-info URNs), and section 11.2 (the IANA registration are very tightly connected. Would it make more sense to combine them, or at least group them together? (Is there a good model to emulate?) Section 1.1 As a result, Alert-Info currently only works when the same vendor provides >>>proxy<<< and UA, as only the= n is the same "fake" proprietary URI convention used. I think the marked word should be changed to "PBX", as the previous sentences discuss "PBX", and in most situations a proxy would not modify the Alert-Info header. Section 1.3 The marker "[E182]" is used for ITU E.182. I think it would look better if we used "[E.182]". Section 3.2.1 As call-waiting information may be subject to the callee's privacy concerns, the exposure of this information shall be done only if explicitly required by the >>>user<<<. I think the marked word should be "callee", as there are two users, and the callee is the user that is intended here. Section 3.2.4 This feature is used when a user has utilized a server to implement an automatic callback service. It would be informative to add a footnote here: [I-D.ietf-bliss-call-completion] Worley, D., Huelsemann, M, Jesske, R., and D. Alexeitsev, "Call Completion for Session Initiation Protocol (SIP)", draft-ietf-bliss-call-completion-14 (work in progress), November 2011. Section 4 This rule is given: Labels are case-insensitive, but MUST be specified in all lower-case. That suggests that these two grammar rules should be modified to remove the upper-case letters: alert-URN =3D "URN:alert:" alert-identifier ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z become: alert-URN =3D "urn:alert:" alert-identifier ALPHA =3D %x61-7A ; a-z But the latter depends on whether we are presenting a grammar to *generate* Alert-Info URNs or a grammar to *parse* them. The Alert- Info URN does not prescribe a particular resolution mechanism, but it is assumed that a number of different entities could operate and offer such mechanisms. I think that it would be better to warn the reader that we expect the rules in section 7 to apply: The Alert-Info URN does not prescribe a particular resolution mechanism, but any resolution SHOULD (MUST?) comply with the rules in section 7. I'm not sure I understand this paragraph: Identifier uniqueness considerations: An Alert-Info URN identifies a logical service or tone, specified in the alert-indication registration (see Section 11). Resolution of the registered URN will return a particular instance of the alert identifier. Alert identifier URNs MUST be unique for each unique indication; this is guaranteed through the registration of each alert indication within this namespace, described in Section 11. Process of identifier assignment: The process of identifier assignment is described in Section 11. I think that the above should mention the "private" extensions: Process of identifier assignment: The process of identifier assignment is described in Section 11, which includes the extension rules for independent organizations described in section 6.2. Section 6.1 Adding new categories and adding alert-indication values other than via the "private" mechanism described >>>above<<< is standards action. I think that the marked word should be "below". Better would probably be "in section 6.2". This example is given: For example, some company SomeCompany.example.org could use urn:alert:service:call-waiting:SomeCompany.example.org, which is the SomeCompany's private version for call-waiting or it may have several distinct private versions of call-waiting, e.g. urn:alert:service:call-waiting:abc.SomeCompany.example.org and urn:alert:service:call-waiting:def.SomeCompany.example.org (which are siblings in the tree under urn:alert:service:call-waiting). Also it can subdivide its private version of call-waiting in urn:alert:service:call-waiting:SomeCompany.example.org:abc and urn:alert:service:call-waiting:SomeCompany.example.org:def (which are siblings in the tree under service:call- waiting:SomeCompany.example.org). It has two problems: "SomeCompany" is not in lower case (as demanded by section 4), and the value is given as the FQDN rather than the reversed FQDN. The correct example would be For example, some company SomeCompany.example.org could use urn:alert:service:call-waiting:org.example.somecompany, which is the SomeCompany's private version for call-waiting or it may have several distinct private versions of call-waiting, e.g. urn:alert:service:call-waiting:abc.org.example.somecompany and urn:alert:service:call-waiting:def.org.example.somecompany (which are siblings in the tree under urn:alert:service:call-waiting). Also it can subdivide its private version of call-waiting in urn:alert:service:call-waiting:org.example.somecompany:abc and urn:alert:service:call-waiting:org.example.somecompany:def (which are siblings in the tree under service:call- waiting:org.example.somecompany). Dale From pkyzivat@alum.mit.edu Wed Feb 8 18:44: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 6103911E80B7 for ; Wed, 8 Feb 2012 18:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, GB_I_LETTER=-2] 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 BlL9AvgquCPC for ; Wed, 8 Feb 2012 18:44:08 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5396621F8569 for ; Wed, 8 Feb 2012 18:44:08 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id Xea81i0051YDfWL54ek8wl; Thu, 09 Feb 2012 02:44:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id Xek81i01K07duvL3gek8HY; Thu, 09 Feb 2012 02:44:08 +0000 Message-ID: <4F3332F6.1090204@alum.mit.edu> Date: Wed, 08 Feb 2012 21:44:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: salud@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] -05: Mostly editorial issues 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, 09 Feb 2012 02:44:09 -0000 On 2/8/12 3:07 PM, Worley, Dale R (Dale) wrote: > Section 4 > > This rule is given: > > Labels are case-insensitive, but MUST be specified in > all lower-case. > > That suggests that these two grammar rules should be modified to > remove the upper-case letters: > > alert-URN = "URN:alert:" alert-identifier > > ALPHA = %x41-5A / %x61-7A ; A-Z / a-z > > become: > > alert-URN = "urn:alert:" alert-identifier > > ALPHA = %x61-7A ; a-z > > But the latter depends on whether we are presenting a grammar to > *generate* Alert-Info URNs or a grammar to *parse* them. Its really unclear what the intent is. If the labels MUST be specified in lower-case then they aren't really case insensitive. IMO this is a perfect place for use of SHOULD rather than MUST. Or, perhaps it would be better to say that the representation in Alert-Info SHOULD be identical (in case) to the representation of the URN in its registration. (But comparison MUST be made case-insensitively, and there MUST NOT be multiple registrations of URNs that differ only in case.) Thanks, Paul From dworley@avaya.com Thu Feb 9 12:35:23 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 59F8B11E8085 for ; Thu, 9 Feb 2012 12:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUcsCbcsFpfy for ; Thu, 9 Feb 2012 12:35:22 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5F24911E8072 for ; Thu, 9 Feb 2012 12:35:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFctNE+HCzI1/2dsb2JhbABDDq9OgQeBcgEBAQECARIoRAsCAQgNAQchEDIlAQEEARIIGodanSacH4wNFQkGCw8KBBoCBgQEAwGDGUlcglpjBIhIkmSML1U X-IronPort-AV: E=Sophos;i="4.73,392,1325480400"; d="scan'208";a="290540247" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Feb 2012 15:35:20 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Feb 2012 15:21:08 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 9 Feb 2012 15:35:19 -0500 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , "salud@ietf.org" Date: Thu, 9 Feb 2012 15:34:02 -0500 Thread-Topic: [salud] -05: Mostly editorial issues Thread-Index: Aczm1LXcRgxu/xFzR5WXjCWtfZKzDAAlXLs2 Message-ID: References: , <4F3332F6.1090204@alum.mit.edu> In-Reply-To: <4F3332F6.1090204@alum.mit.edu> 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: Re: [salud] -05: Mostly editorial issues 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, 09 Feb 2012 20:35:23 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > Its really unclear what the intent is. If the labels MUST be specified > in lower-case then they aren't really case insensitive. >=20 > IMO this is a perfect place for use of SHOULD rather than MUST. >=20 > Or, perhaps it would be better to say that the representation in > Alert-Info SHOULD be identical (in case) to the representation of the > URN in its registration. (But comparison MUST be made > case-insensitively, and there MUST NOT be multiple registrations of URNs > that differ only in case.) There are other situations where one is required to accept either case but required to generate only one case. Unfortunately, I can't remember the example right now. Dale From dworley@avaya.com Thu Feb 9 13:42: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 0BA7621E8019 for ; Thu, 9 Feb 2012 13:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.915 X-Spam-Level: X-Spam-Status: No, score=-103.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, GB_I_LETTER=-2, 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 jCpxhzzlIQ32 for ; Thu, 9 Feb 2012 13:42:36 -0800 (PST) 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 E583F21E8058 for ; Thu, 9 Feb 2012 13:42:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMs8NE+HCzI1/2dsb2JhbABDniuRMYEHgXkSKFEBFSlCJwQbGqBihBecGYtYAQMDBAQIBwsJAwMCBQQBBAIJBgsPCgQaAgYEgyFJgzZjBIhIkmSNBA X-IronPort-AV: E=Sophos;i="4.73,392,1325480400"; d="scan'208";a="231130190" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Feb 2012 16:42:33 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Feb 2012 16:28:13 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 9 Feb 2012 16:42:24 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Thu, 9 Feb 2012 16:41:55 -0500 Thread-Topic: -05: Resolution rules Thread-Index: AQHM53O1/BDPUf6QUk6atun4j1YVSg== 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] -05: Resolution rules 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, 09 Feb 2012 21:42:37 -0000 I think these are some improvements we could make to the "resolution rules" in section 7, and related parts of the text. 4. Namespace Registration Template alert-URN =3D "URN:alert:" alert-identifier alert-identifier=3D alert-category ":" alert-indication alert-category =3D name alert-indication=3D name *(":" name) name =3D let-dig [ *let-dig-hyp let-dig ] let-dig-hyp =3D let-dig / "-" let-dig =3D ALPHA / DIGIT ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z DIGIT =3D %x30-39 ; 0-9 It turns out that this syntax doesn't allow for private-names at all! So I think we need to add/modify: name =3D standard-name / private-name standard-name =3D label private-name =3D label "." label *[ "." label ] label =3D let-dig [ *let-dig-hyp let-dig ] (I think that "label" is the term used in DNS for sequence-of-letters-digits-and-hyphens.) Here I require private-name to contain at least one ".", so private-names are never the same as standard-names. Because we don't now define "", add: Throughout this document, "" is used as a syntactic variable for any string conformant to the "private-name" ABNF above. Some changes to section 7, where I have made notes: 7. Combinations of Alert-Info URNs and Priority Rules This section describes combination rules for the case when all the Alert-Info header fields only contain Alert-Info URNs. Combinations of URNs and URIs in the Alert-Info header fields of the same SIP- message are not defined in this specification. In many cases, more than one URNs will be needed to fully define a particular tone. This is done by including multiple Alert-Info URNs, in one or more Alert-Info header fields in a request or a response. For example, an internal, priority call could be indicated by Alert- Info: , . A priority call waiting tone could be indicated by Alert-Info: , . The sender of the Alert-Info header may include an arbitrary list of Alert-Info URNs, even if they are redundant or contradictory. An earlier URN has priority over any later contradictory URN. This allows any element to modify a list of URNs to require a feature value (by adding a URN at the beginning of the list) or to suggest a feature value (by adding a URN at the end of the list). The receiving UA attempts to match the received Alert-Info URNs combination with the signal(s) it is able to render. The implementation is free to ignore any or all parts of the received Alert-Info URNs. The exact way in which a UA renders a received combination of Alert-Info URNs is left as an implementation issue. However, the implementation MUST comply to following rules: a. Each alert-info URN has precedence over all URNs that follow it, and its interpretation is subordinate to all URNs that precede it. b. If the UA cannot implement the effect of a URN (because it does not recognize the URN or the URN's effect is precluded by preceding URNs), the UA removes the final name of the URN repeatedly until either (1) the resulting URN is recognized and can be given effect by some signal (without reducing the degree of expression of any preceding URN), or (2) the resulting URN is reduced to having no names. In case (2), that URN in the series cannot be given effect, so it is ignored. I think it was Paul who mentioned that we may want to remove from a URN not the final name, but the final label from a private-name. That is, changing the final private-name from a subdomain to its super-domain. That makes paragraph b a bit more complex. I've reformatted it to use indentation to clarify the situation: b. If the UA cannot implement the effect of a URN (because it does not recognize the URN or the URN's effect is precluded by preceding URNs), the UA repeatedly removes either (1) the final name of the URN, or (2) if the final name is a private-name with three or more labels, the final label, until either=20 (i) the resulting URN is recognized and can be given effect by some signal (without reducing the degree of expression of any preceding URN), or (ii) the resulting URN is reduced to having no alert-indication. In case (ii), that URN in the series cannot be given effect, so it is ignored. c. In case that after processing all the received URNs, the UA can generate more than one signal that are equally effective at expressing the URNs (under the preceding rules), one of those signals is selected. When selecting from the set of equally effective signals, any particular signal is preferred over all signals that are more specific (in regard to the defined meaning of the signal to the user) than that particular signal. (E.g., if each signal expresses a set of alert-indications (values) for a set of alert-categories (per the BNF), then a first signal is more specific than a second signal if the second signal's alert- indications are (partial or complete) initial portions of the first signal's corresponding alert-indications.) I've always disliked the latter part of paragraph c. (I can say that because I wrote it.) I think this is an improvement: When selecting from the set of equally effective signals, no signal should be chosen if a less-specific signal is also in the set. (Specificity is to be judged based on the defined meanings of the signals to the user.) (E.g., if each signal is considered to express certain alert-indications of certain alert-categories, one signal is less-specific than a second signal if the first signal's alert-indications are a subset or are prefixes of the second signal's alert-indications.) And I want to allow the UA to use information from elsewhere in the message, as long as it doesn't contradict the Alert-Info: However, a more-specific signal may be chosen if the choice is based on information derived from the containing SIP message. E.g., a signal implying urn:alert-info:priority:high may be chosen if the SIP message contains the header "Priority: urgent". And after the rules, let us add remind the reader that the set of signals may depend on the status of UA, as well as user preferences and local policy: In all situations, the set of signals that can be rendered and their significances may change based on user preferences and local policy. In adidition, they may change based on the status of the UA. E.g., if a call is active on the UA, all audible signals may become unavailable, or audible signals may be available only if urn:alert-info:priority:high is specified. I'd like to turn this paragraph into its own section: There are cases when the device can render audio and visual (e.g. video or text) at the same time. This kind of rendering can be considered as one signal which has a set of sensory components instead of a set of different signals. E. g., if the device generates audio signals and visual signals at the same time, each "signal" is a combination of one audio and one visual component. There is some benefit to treating separately audio and visual signals, since the total number that need to be defined can be a lot less. It is an implementation choice to use one option or another. like this: 7.1. Multi-mode signals There are cases when the device can render two signal modes (e.g., audio and visual, or video or text) at the same time. Formally, the device must be considered as making its choice from the set of all combined signals that it can render, and that choice must conform to the above rules. However, it can be proven that if the device makes its rendering choice for each of the two modes independently, with each choice separately conforming to the above rules, its combined choice conforms to the above rules, when it is regarded as a choice from among all possible combinations. In such a situation, it may simplify implementation to make each choice separately. It is an implementation decision whether to chose from among combined signals, or to combine choices made from each signal mode. Dale From laura.liess.dt@googlemail.com Fri Feb 10 01:45: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 9894821F8757 for ; Fri, 10 Feb 2012 01:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 kGA55ZMOpYiq for ; Fri, 10 Feb 2012 01:45:03 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2912E21F873E for ; Fri, 10 Feb 2012 01:45:02 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so1938811wgb.13 for ; Fri, 10 Feb 2012 01:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AdBFbkl8jKKmcfg9kDEERjX/Es7NLWOG1IwcwCqZUhg=; b=Fsw/rmV/bGoQQ0qi5DWjx8EmMDenK3EJaNMhylgB6iwXcJhi+wObRHik+7gI3Rw+p2 +aV4wNpTX7757Zxzk9mEPwDZNKIX48/bayrfUyk/2LhLCGMsIF3v/GQNv8a0ldZ0lM+P cYW77WhY4y55oJmiig1CqfRisqYBwLKxzn0xA= MIME-Version: 1.0 Received: by 10.180.7.231 with SMTP id m7mr2565176wia.3.1328867102191; Fri, 10 Feb 2012 01:45:02 -0800 (PST) Received: by 10.227.23.197 with HTTP; Fri, 10 Feb 2012 01:45:02 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Feb 2012 10:45:02 +0100 Message-ID: From: Laura Liess To: "Worley, Dale R (Dale)" , Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] -05: Mostly editorial issues 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, 10 Feb 2012 09:45:04 -0000 Dale, Please see inline. > > Overall > > I don't know how URN namespaces are properly organized. =C2=A0It seems to > me that section 4 (the namespace registration template), section 5 > (the defined values of alert-info URNs), and section 11.2 (the IANA > registration are very tightly connected. =C2=A0Would it make more sense t= o > combine them, or at least group them together? (Is there a good model to = emulate?) [LL] I think a good model is the RFC 5031, where the sections "Registration Template" and " IANA Considerations" are together. I think it would make sense to shift section11 after section 5. =C2=A0> > Section 1.1 > > =C2=A0 As a result, Alert-Info currently > =C2=A0 only works when the same vendor provides >>>proxy<<< and UA, as on= ly then > =C2=A0 is the same "fake" proprietary URI convention used. > > I think the marked word should be changed to "PBX", as the previous > sentences discuss "PBX", and in most situations a proxy would not > modify the Alert-Info header. [LL] Agree. > > Section 1.3 > > The marker "[E182]" is used for ITU E.182. =C2=A0I think it would look > better if we used "[E.182]". [LL] In the previous versions up to 02, we had [E.182]. I had to change it in version 03 because one of the submission tools (xml2rfc or idnits) changed and did not accept the dot any more. > > Section 3.2.1 > > =C2=A0 As call-waiting information may be subject to the callee's > =C2=A0 privacy concerns, the exposure of this information shall be done o= nly > =C2=A0 if explicitly required by the >>>user<<<. > > I think the marked word should be "callee", as there are two users, > and the callee is the user that is intended here. [LL] Agree. > > Section 3.2.4 > > =C2=A0 This feature is used when a user has utilized a server to implemen= t > =C2=A0 an automatic callback service. > > It would be informative to add a footnote here: > > =C2=A0 [I-D.ietf-bliss-call-completion] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Worley, D., Huelsemann, M= , Jesske, R., and D. Alexeitsev, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Call Completion for Sess= ion Initiation Protocol (SIP)", > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bliss-call-com= pletion-14 (work in progress), > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0November 2011. [LL] I am not realy familiar with the call completion draft, but it seems to me that there is no reference in the draft about a possible ussage of an Alert-Info URN. Also Section 3 describes existing use cases and implementations today. I think a reference to the draft would eventually be confusing. > Section 4 > > This rule is given: > > =C2=A0 =C2=A0 =C2=A0Labels are case-insensitive, but MUST be specified in > =C2=A0 =C2=A0 =C2=A0all lower-case. > > That suggests that these two grammar rules should be modified to > remove the upper-case letters: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-URN =C2=A0 =C2=A0 =C2=A0 =3D "URN:alert:= " alert-identifier > > =C2=A0 =C2=A0 =C2=A0 =C2=A0ALPHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %= x41-5A / %x61-7A =C2=A0 ; A-Z / a-z > > become: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-URN =C2=A0 =C2=A0 =C2=A0 =3D "urn:alert:= " alert-identifier > > =C2=A0 =C2=A0 =C2=A0 =C2=A0ALPHA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %= x61-7A =C2=A0 ; a-z > > But the latter depends on whether we are presenting a grammar to > *generate* Alert-Info URNs or a grammar to *parse* them. [LL] Would it be OK to: 1) Take Paul's first proposal and use SHOULD rather than MUST and 2) Use "urn:alert:" alert-identifier instead of "URN:alert:" alert-identifier ? > > =C2=A0 =C2=A0 =C2=A0The Alert- > =C2=A0 =C2=A0 =C2=A0Info URN does not prescribe a particular resolution m= echanism, but > =C2=A0 =C2=A0 =C2=A0it is assumed that a number of different entities cou= ld operate > =C2=A0 =C2=A0 =C2=A0and offer such mechanisms. > > I think that it would be better to warn the reader that we expect the > rules in section 7 to apply: > > =C2=A0 =C2=A0 =C2=A0The Alert-Info URN does not prescribe a particular re= solution > =C2=A0 =C2=A0 =C2=A0mechanism, but any resolution SHOULD (MUST?) comply w= ith the > =C2=A0 =C2=A0 =C2=A0rules in section 7. [LL] Yes. The current text is old and must be changed. I think MUST is correct because we use MUST in section 7. > > I'm not sure I understand this paragraph: > > =C2=A0 Identifier uniqueness considerations: =C2=A0An Alert-Info URN iden= tifies a > =C2=A0 =C2=A0 =C2=A0logical service or tone, specified in the alert-indic= ation > =C2=A0 =C2=A0 =C2=A0registration (see Section 11). =C2=A0Resolution of th= e registered URN > =C2=A0 =C2=A0 =C2=A0will return a particular instance of the alert identi= fier. =C2=A0Alert > =C2=A0 =C2=A0 =C2=A0identifier URNs MUST be unique for each unique indica= tion; this is > =C2=A0 =C2=A0 =C2=A0guaranteed through the registration of each alert ind= ication > =C2=A0 =C2=A0 =C2=A0within this namespace, described in Section 11. > > =C2=A0 Process of identifier assignment: =C2=A0The process of identifier > =C2=A0 =C2=A0 =C2=A0assignment is described in Section 11. > > I think that the above should mention the "private" extensions: > > =C2=A0 Process of identifier assignment: =C2=A0The process of identifier > =C2=A0 =C2=A0 =C2=A0assignment is described in Section 11, which includes= the > =C2=A0 =C2=A0 =C2=A0extension rules for independent organizations describ= ed in section > =C2=A0 =C2=A0 =C2=A06.2. [LL] Agree. > > Section 6.1 > > =C2=A0 Adding new categories and adding alert-indication > =C2=A0 values other than via the "private" mechanism described >>>above<<= < is > =C2=A0 standards action. > > I think that the marked word should be "below". =C2=A0Better would probab= ly > be "in section 6.2". [LL] Agree. > > This example is given: > > =C2=A0 For example, some company SomeCompany.example.org could use > =C2=A0 urn:alert:service:call-waiting:SomeCompany.example.org, which is t= he > =C2=A0 SomeCompany's private version for call-waiting or it may have seve= ral > =C2=A0 distinct private versions of call-waiting, e.g. > =C2=A0 urn:alert:service:call-waiting:abc.SomeCompany.example.org and > =C2=A0 urn:alert:service:call-waiting:def.SomeCompany.example.org (which = are > =C2=A0 siblings in the tree under urn:alert:service:call-waiting). =C2=A0= Also it > =C2=A0 can subdivide its private version of call-waiting in > =C2=A0 urn:alert:service:call-waiting:SomeCompany.example.org:abc and > =C2=A0 urn:alert:service:call-waiting:SomeCompany.example.org:def (which = are > =C2=A0 siblings in the tree under service:call- > =C2=A0 waiting:SomeCompany.example.org). > > It has two problems: =C2=A0"SomeCompany" is not in lower case (as demande= d > by section 4), and the value is given as the FQDN rather than the > reversed FQDN. =C2=A0The correct example would be > > =C2=A0 For example, some company SomeCompany.example.org could use > =C2=A0 urn:alert:service:call-waiting:org.example.somecompany, which is t= he > =C2=A0 SomeCompany's private version for call-waiting or it may have seve= ral > =C2=A0 distinct private versions of call-waiting, e.g. > =C2=A0 urn:alert:service:call-waiting:abc.org.example.somecompany and > =C2=A0 urn:alert:service:call-waiting:def.org.example.somecompany (which = are > =C2=A0 siblings in the tree under urn:alert:service:call-waiting). =C2=A0= Also it > =C2=A0 can subdivide its private version of call-waiting in > =C2=A0 urn:alert:service:call-waiting:org.example.somecompany:abc and > =C2=A0 urn:alert:service:call-waiting:org.example.somecompany:def (which = are > =C2=A0 siblings in the tree under service:call- > =C2=A0 waiting:org.example.somecompany). [LL] Agree. > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From pkyzivat@alum.mit.edu Fri Feb 10 11:12:13 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 8F31A21F87B5 for ; Fri, 10 Feb 2012 11:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZXmeZ2Zodgq for ; Fri, 10 Feb 2012 11:12:13 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9F3C21F876F for ; Fri, 10 Feb 2012 11:12:12 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id YKBK1i0090SCNGk5AKCDPN; Fri, 10 Feb 2012 19:12:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id YKCD1i00507duvL3VKCDM9; Fri, 10 Feb 2012 19:12:13 +0000 Message-ID: <4F356C0B.8010209@alum.mit.edu> Date: Fri, 10 Feb 2012 14:12:11 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , <4F3332F6.1090204@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "salud@ietf.org" Subject: Re: [salud] -05: Mostly editorial issues 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, 10 Feb 2012 19:12:13 -0000 On 2/9/12 3:34 PM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> Its really unclear what the intent is. If the labels MUST be specified >> in lower-case then they aren't really case insensitive. >> >> IMO this is a perfect place for use of SHOULD rather than MUST. >> >> Or, perhaps it would be better to say that the representation in >> Alert-Info SHOULD be identical (in case) to the representation of the >> URN in its registration. (But comparison MUST be made >> case-insensitively, and there MUST NOT be multiple registrations of URNs >> that differ only in case.) > > There are other situations where one is required to accept either case > but required to generate only one case. Unfortunately, I can't > remember the example right now. > > Dale What is the point here? (Of mandating what must be generated.) Is it to simplify implementations? (It doesn't.) IMO the most important thing is to ensure that two differently cased spellings of the same name aren't being used with the expectation that they are distinct. For those that are registered with iana, that can be achieved by requiring that each registration be unique in a case-insensitive way from all others. For the private ones, that aren't registered with IANA, you already brought up the problem of dns names that are customarily represented in mixed case. We already know that dns names are required to be case insensitive, so we won't have a conflict between Example.com and example.com. I find it very unnatural to require the same name to be represented all in lower case in the URN. Thanks, Paul From laura.liess.dt@googlemail.com Mon Feb 20 08:09: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 2B30B21F8557 for ; Mon, 20 Feb 2012 08:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 mqj1efOBR0D8 for ; Mon, 20 Feb 2012 08:08:58 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A286F21F8507 for ; Mon, 20 Feb 2012 08:08:57 -0800 (PST) Received: by wibhm9 with SMTP id hm9so3796551wib.31 for ; Mon, 20 Feb 2012 08:08:56 -0800 (PST) Received-SPF: pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.92.165 as permitted sender) client-ip=10.180.92.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.92.165 as permitted sender) smtp.mail=laura.liess.dt@googlemail.com; dkim=pass header.i=laura.liess.dt@googlemail.com Received: from mr.google.com ([10.180.92.165]) by 10.180.92.165 with SMTP id cn5mr19684660wib.2.1329754136902 (num_hops = 1); Mon, 20 Feb 2012 08:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Cly9hSPIxE5SHsX7qDKBXHl9mp9QjaXcDX2FgPmdu7Q=; b=GF4zAB/7SYziKpgVEa2xUtlWo1Tp/N7jRRvBBlAP4HdWaEv5RjfpPUdBY9RBjnoZ04 B+91Q1D/foOygiXpfEth38919dArOgZFZcnJNJrLf9wMMGurkNSiBtTBwN+ODuGJStRR un+sV4VE064eOpuhxq5FTqESo9sLdCU6SaZYg= MIME-Version: 1.0 Received: by 10.180.92.165 with SMTP id cn5mr16387620wib.2.1329754136866; Mon, 20 Feb 2012 08:08:56 -0800 (PST) Received: by 10.227.112.206 with HTTP; Mon, 20 Feb 2012 08:08:56 -0800 (PST) In-Reply-To: References: Date: Mon, 20 Feb 2012 17:08:56 +0100 Message-ID: From: Laura Liess To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] -05: Mostly editorial issues 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, 20 Feb 2012 16:09:05 -0000 Dale, Concerning your proposal to add a reference to the call completion draft: I thought again about it and discussed the issue with Martin. I agree with the reference. Thanks Laura > > >> >> Section 3.2.4 >> >> =C2=A0 This feature is used when a user has utilized a server to impleme= nt >> =C2=A0 an automatic callback service. >> >> It would be informative to add a footnote here: >> >> =C2=A0 [I-D.ietf-bliss-call-completion] >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Worley, D., Huelsemann, = M, Jesske, R., and D. Alexeitsev, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Call Completion for Ses= sion Initiation Protocol (SIP)", >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bliss-call-co= mpletion-14 (work in progress), >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0November 2011. > > [LL] =C2=A0I am not realy familiar with the call completion draft, but it > seems to me that there is no reference in the draft about a possible > ussage of an Alert-Info URN. Also Section 3 describes existing use > cases and implementations today. I think a reference to the draft > would eventually be confusing. > > From dworley@avaya.com Mon Feb 20 12:52:20 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 0CCEC21F867C for ; Mon, 20 Feb 2012 12:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2g97y3ruU-p for ; Mon, 20 Feb 2012 12:52:19 -0800 (PST) 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 138AB21F867A for ; Mon, 20 Feb 2012 12:52:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABGyQk/GmAcF/2dsb2JhbABEDrFvgQeBcwEBAQECARIoPwULAgEIDQEHIRAyJQEBBA4FCBqHXp1bnBiMLgYCBgMFDQYCDwMDAoNfAikDDYJbYwSITpJojDdV X-IronPort-AV: E=Sophos;i="4.73,452,1325480400"; d="scan'208";a="232986853" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Feb 2012 15:51:59 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Feb 2012 15:45:21 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 20 Feb 2012 15:51:58 -0500 From: "Worley, Dale R (Dale)" To: Paul Kyzivat Date: Mon, 20 Feb 2012 15:51:58 -0500 Thread-Topic: [salud] -05: Mostly editorial issues Thread-Index: AczoJ+aIwDLKB/ceTFOhyHGSgCt53gH6M9Ys Message-ID: References: , <4F3332F6.1090204@alum.mit.edu> , <4F356C0B.8010209@alum.mit.edu> In-Reply-To: <4F356C0B.8010209@alum.mit.edu> 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 Cc: "salud@ietf.org" Subject: Re: [salud] -05: Mostly editorial issues 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, 20 Feb 2012 20:52:20 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > For the private ones, that aren't registered with IANA, you already > brought up the problem of dns names that are customarily represented in > mixed case. We already know that dns names are required to be case > insensitive, so we won't have a conflict between Example.com and > example.com. I find it very unnatural to require the same name to be > represented all in lower case in the URN. I don't remember bringing it up, but you're right that it complicates things. In theory it's no more complex. But in practice, people will not universally downcase DNS names. So how should we adjust the rules? We want case-insensitive comparison. Should we say "Comparisons are case-insensitive. Transmitted URNs SHOULD be in lower case. Registered URNs MUST be lower case."? Dale From dworley@avaya.com Mon Feb 20 13:44: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 D6EDE21F851C for ; Mon, 20 Feb 2012 13:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyacgFanr7Hv for ; Mon, 20 Feb 2012 13:44:11 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id D7D3221F8517 for ; Mon, 20 Feb 2012 13:44:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMS9Qk/GmAcF/2dsb2JhbABEsgGBB4F6EihRARUpQicEGxqmVoQXlCmJPYJCCREEEQYCBgMFDQYCFQKDXwIQAweCemMEiE6SaI0MgTU X-IronPort-AV: E=Sophos;i="4.73,453,1325480400"; d="scan'208";a="331379789" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Feb 2012 16:44:09 -0500 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; 20 Feb 2012 16:37:31 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 20 Feb 2012 16:44:09 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Mon, 20 Feb 2012 16:42:57 -0500 Thread-Topic: Improving the wording of section 8 Thread-Index: AQHM8BjG4ygKZ9CFFkqENKaW3upDgw== 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] Improving the wording of section 8 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, 20 Feb 2012 21:44:12 -0000 Here are some changes that I think would improve how section 8 reads. The changes are marked with >>> and <<<. 8. Non-normative Algorithm for Handling Combinations of URNs >>>The following text is a non-normative example of an algorithm for handling combinations of URNs that complies with the requirements in section 7. Thus, it demonstrates that requirements in section 7 are consistent and implementable. (Of course, a device may use any other algorithm which complies with section 7.)<<< ... The algorithm proceeds by considering each URN in the received Alert-Info header from left to right, while revising a set of signals. The set of signals starts as the entire set of signals available to the device. Each URN excludes some signals from the set, and *sorts* the signals that remain in the set according to how well they represent the URN. >>>(The details of these operations are described below.)<<< The first URN is the "major sort", and has the most influence on the position of a signal in the set. ... ... At the end of the algorithm, a final, "most minor" sort is done, which orders the signals which have been tied under all the sorts driven by the URNs. >>>This final sort places the least specific signals (within their groups) *first*. (If one signal's position in each category tree is ancestral or the same as a second signal's position in that tree, the first signal is "less specific" than the second signal. Other cases are left to the implementation to decide.)<<< ... Here is how a single sort step proceeds, examining a single URN to modify the set of signals (by excluding some signals and further sorting the signals that remain): >>>[a number of minor changes] o The URN specifies a specific node in a specific category tree. o All signals in the set that are positioned at that node, or at an ancestor node of the URN, are kept. All other signals are removed from the set. o Within any group of signals that are tied under the previous sorts, place first those which are at the node of the URN, place second those which are at the parent node of the URN, etc., and place last those which are at the root node of the feature tree. <<< I believe that this paragraph can be deleted, if we discuss this point as section 7.1: In cases when the device can render audio and visual (e.g. video or text) signals at the same time, the algorithms as we have been discussing them would work correctly if we consider that the input set of signals is a set of *pairs*, each pair containing an audio component and a visual component, and the input set of pairs contains all possible pairs of audio and visual components. Dale From pkyzivat@alum.mit.edu Mon Feb 20 14:04:39 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 616E321F85D7 for ; Mon, 20 Feb 2012 14:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWznciWpW1VL for ; Mon, 20 Feb 2012 14:04:38 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id A9C9F21F85D5 for ; Mon, 20 Feb 2012 14:04:38 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id cN1n1i0051GhbT85FN4f21; Mon, 20 Feb 2012 22:04:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id cN4e1i01607duvL3TN4ffs; Mon, 20 Feb 2012 22:04:39 +0000 Message-ID: <4F42C374.1000105@alum.mit.edu> Date: Mon, 20 Feb 2012 17:04:36 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: , <4F3332F6.1090204@alum.mit.edu> , <4F356C0B.8010209@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "salud@ietf.org" Subject: Re: [salud] -05: Mostly editorial issues 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, 20 Feb 2012 22:04:39 -0000 On 2/20/12 3:51 PM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> For the private ones, that aren't registered with IANA, you already >> brought up the problem of dns names that are customarily represented in >> mixed case. We already know that dns names are required to be case >> insensitive, so we won't have a conflict between Example.com and >> example.com. I find it very unnatural to require the same name to be >> represented all in lower case in the URN. > > I don't remember bringing it up, but you're right that it complicates > things. In theory it's no more complex. But in practice, people will > not universally downcase DNS names. > > So how should we adjust the rules? We want case-insensitive > comparison. Should we say "Comparisons are case-insensitive. > Transmitted URNs SHOULD be in lower case. Registered URNs MUST be > lower case."? IMO: Comparisons MUST be case-insensitive. Registered URNs SHOULD be transmitted as registered. A new name MUST NOT be registered if it is equal by case-insensitive comparison to an already registered name. Thanks, Paul From laura.liess.dt@googlemail.com Wed Feb 22 06:09:44 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 732AF21F8501 for ; Wed, 22 Feb 2012 06:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SByem-FxXR7r for ; Wed, 22 Feb 2012 06:09:39 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1DA921F8510 for ; Wed, 22 Feb 2012 06:09:27 -0800 (PST) Received: by werg1 with SMTP id g1so58368wer.31 for ; Wed, 22 Feb 2012 06:09:27 -0800 (PST) Received-SPF: pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.107.99 as permitted sender) client-ip=10.180.107.99; Authentication-Results: mr.google.com; spf=pass (google.com: domain of laura.liess.dt@googlemail.com designates 10.180.107.99 as permitted sender) smtp.mail=laura.liess.dt@googlemail.com; dkim=pass header.i=laura.liess.dt@googlemail.com Received: from mr.google.com ([10.180.107.99]) by 10.180.107.99 with SMTP id hb3mr36143942wib.5.1329919767007 (num_hops = 1); Wed, 22 Feb 2012 06:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BQ7kjNaQoNrlPmDueiZ5YJNwW19wpo5eePqXM41PtC4=; b=kGs1Eew5DuPymMRW8zwLnvtPG3VP+Jr4h/Tk1E81lCLgWXYvC7U7MIg9EQGA2GWnoR 33Wi4p/S04dWon4PlGPT+Ll73TVX0Nd7Ot9SyqqRV3sRcpLDqRI6FY+MNiFCX96K6fk4 s7WJ9X1GRUThZxWDTeXLW7nWYYE6EgGOqDlQ4= MIME-Version: 1.0 Received: by 10.180.107.99 with SMTP id hb3mr29881323wib.5.1329919766901; Wed, 22 Feb 2012 06:09:26 -0800 (PST) Received: by 10.227.112.206 with HTTP; Wed, 22 Feb 2012 06:09:26 -0800 (PST) In-Reply-To: <4F42C374.1000105@alum.mit.edu> References: <4F3332F6.1090204@alum.mit.edu> <4F356C0B.8010209@alum.mit.edu> <4F42C374.1000105@alum.mit.edu> Date: Wed, 22 Feb 2012 15:09:26 +0100 Message-ID: From: Laura Liess To: Paul Kyzivat , "Worley, Dale R (Dale)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] -05: Mostly editorial issues 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, 22 Feb 2012 14:09:44 -0000 Hi, After this discussion I would change the do following text changes on page = 13: =3D=3D=3D-Begin of changes =3D=3D=3D Change #1: Old text: "The alert-indications are hierarchical identifiers, consisting of one label or a sequence of labels separated by colons. The set of allowable characters is the same as that for domain names [RFC1123]. Labels are case-insensitive, but MUST be specified in all lower-case." New text: "The alert-indications are hierarchical identifiers. The set of allowable characters is the same as that for domain names [RFC1123]. Labels are case-insensitive. Comparisons MUST be case-insensitive. Registered URNs SHOULD be transmitted as registered. A new name MUST NOT be registered if it is equal by case-insensitive comparison to an already registered name. " Change #2: Old text: " alert-URN =3D "URN:alert:" alert-identifier alert-identifier=3D alert-category ":" alert-indication alert-category =3D name alert-indication=3D name *(":" name) name =3D let-dig [ *let-dig-hyp let-dig ] let-dig-hyp =3D let-dig / "-" let-dig =3D ALPHA / DIGIT ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z DIGIT =3D %x30-39 ; 0-9 " New text: " alert-URN =3D "URN:alert:" alert-identifier alert-identifier=3D alert-category ":" alert-indication alert-category =3D name alert-indication=3D name *(":" name) name =3D standard-name / private-name standard-name =3D label private-name =3D label "." label *[ "." label ] label =3D let-dig [ *let-dig-hyp let-dig ] let-dig-hyp =3D let-dig / "-" let-dig =3D ALPHA / DIGIT ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z DIGIT =3D %x30-39 ; 0-9 Throughout this document, "" is used as a syntactic variable for any string conformant to the "private-name" ABNF above. " =3D=3D=3DEnd of changes=3D=3D=3D Is the new text correct or did I miss something? Thank you Laura 2012/2/20 Paul Kyzivat : > On 2/20/12 3:51 PM, Worley, Dale R (Dale) wrote: >>> >>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >>> >>> For the private ones, that aren't registered with IANA, you already >>> brought up the problem of dns names that are customarily represented in >>> mixed case. We already know that dns names are required to be case >>> insensitive, so we won't have a conflict between Example.com and >>> example.com. I find it very unnatural to require the same name to be >>> represented all in lower case in the URN. >> >> >> I don't remember bringing it up, but you're right that it complicates >> things. =C2=A0In theory it's no more complex. =C2=A0But in practice, peo= ple will >> not universally downcase DNS names. >> >> So how should we adjust the rules? =C2=A0We want case-insensitive >> comparison. =C2=A0Should we say "Comparisons are case-insensitive. >> Transmitted URNs SHOULD be in lower case. =C2=A0Registered URNs MUST be >> lower case."? > > > IMO: > > Comparisons MUST be case-insensitive. > > Registered URNs SHOULD be transmitted as registered. > > A new name MUST NOT be registered if it is equal by case-insensitive > comparison to an already registered name. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks, > =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From dworley@avaya.com Tue Feb 28 12:43: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 7201621F86D0 for ; Tue, 28 Feb 2012 12:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVYLZAQDuKJW for ; Tue, 28 Feb 2012 12:43:22 -0800 (PST) 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 DA54D21F86C7 for ; Tue, 28 Feb 2012 12:43:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANE7TU+HCzI1/2dsb2JhbABDs1SBB4F+EihRARUpQicEGxqHZphghBecG40uAgYDAwIKAg0JAwkZAwMBAgKFDQODNWMEiE+ScI0O X-IronPort-AV: E=Sophos;i="4.73,497,1325480400"; d="scan'208";a="234606676" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Feb 2012 15:43:21 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Feb 2012 15:28:30 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 28 Feb 2012 15:43:20 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Tue, 28 Feb 2012 15:41:55 -0500 Thread-Topic: Test -- please ignore Thread-Index: AQHM9llw8fry0VLyB0+YX8V9Cq6kRQ== 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] Test -- please ignore 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, 28 Feb 2012 20:43:22 -0000 This is a test, please ignore it. IETF Working Groups (WGs) are the >>>primary<<< mechanism for development o= f IETF specifications and guidelines, many of which are intended to be stan= dards or recommendations. Working Groups are typically created to address a >>>specific problem or to= produce one or more specific deliverables<<< (a guideline, standards speci= fication, etc.). Working Groups are generally expected to be short-lived i= n nature. Upon completion of its goals and achievement of its objectives, = the Working Group is terminated. Each Working Group has a charter. WG char= ters state the scope of work for group, and lay out goals and milestones th= at show how this work will be completed. From dworley@avaya.com Wed Feb 29 14:56:45 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 B431221E8035 for ; Wed, 29 Feb 2012 14:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMpOYhChPKW5 for ; Wed, 29 Feb 2012 14:56:45 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66D21F8798 for ; Wed, 29 Feb 2012 14:56:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN6sTk/GmAcF/2dsb2JhbABEDrNXgQeBegEBAQEDAQEBDyg0CxACAQgNBAQBAQEeECcLHQgBAQQBDQUIGodnC50xnDCJF4N2IAIGAwMCCgINCQMJGQuFDQMtBgEBFwIEGoJJYwSIT5JxjDlV X-IronPort-AV: E=Sophos;i="4.73,506,1325480400"; d="scan'208";a="294131291" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Feb 2012 17:56:39 -0500 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; 29 Feb 2012 17:49:30 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 29 Feb 2012 17:56:38 -0500 From: "Worley, Dale R (Dale)" To: Laura Liess , Paul Kyzivat Date: Wed, 29 Feb 2012 17:53:22 -0500 Thread-Topic: [salud] -05: Mostly editorial issues Thread-Index: Aczxa5d27E89dnHXRtygExQ6WHrg1QFyVg+V Message-ID: References: <4F3332F6.1090204@alum.mit.edu> <4F356C0B.8010209@alum.mit.edu> <4F42C374.1000105@alum.mit.edu>, In-Reply-To: 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 Cc: "salud@ietf.org" Subject: Re: [salud] -05: Mostly editorial issues 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, 29 Feb 2012 22:56:45 -0000 I agree with all of this, except I would change alert-URN =3D "URN:alert:" alert-identifier to=20 alert-URN =3D "urn:alert:" alert-identifier because it seems to be the universal convention to use "urn" to start URNs. (Laura has already discussed this on 10 Feb.) (I think this is the end of the case issues.) Dale ________________________________________ From: Laura Liess [laura.liess.dt@googlemail.com] Sent: Wednesday, February 22, 2012 9:09 AM To: Paul Kyzivat; Worley, Dale R (Dale) Cc: salud@ietf.org Subject: Re: [salud] -05: Mostly editorial issues Hi, After this discussion I would change the do following text changes on page = 13: =3D=3D=3D-Begin of changes =3D=3D=3D Change #1: Old text: "The alert-indications are hierarchical identifiers, consisting of one label or a sequence of labels separated by colons. The set of allowable characters is the same as that for domain names [RFC1123]. Labels are case-insensitive, but MUST be specified in all lower-case." New text: "The alert-indications are hierarchical identifiers. The set of allowable characters is the same as that for domain names [RFC1123]. Labels are case-insensitive. Comparisons MUST be case-insensitive. Registered URNs SHOULD be transmitted as registered. A new name MUST NOT be registered if it is equal by case-insensitive comparison to an already registered name. " Change #2: Old text: " alert-URN =3D "URN:alert:" alert-identifier alert-identifier=3D alert-category ":" alert-indication alert-category =3D name alert-indication=3D name *(":" name) name =3D let-dig [ *let-dig-hyp let-dig ] let-dig-hyp =3D let-dig / "-" let-dig =3D ALPHA / DIGIT ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z DIGIT =3D %x30-39 ; 0-9 " New text: " alert-URN =3D "URN:alert:" alert-identifier alert-identifier=3D alert-category ":" alert-indication alert-category =3D name alert-indication=3D name *(":" name) name =3D standard-name / private-name standard-name =3D label private-name =3D label "." label *[ "." label ] label =3D let-dig [ *let-dig-hyp let-dig ] let-dig-hyp =3D let-dig / "-" let-dig =3D ALPHA / DIGIT ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z DIGIT =3D %x30-39 ; 0-9 Throughout this document, "" is used as a syntactic variable for any string conformant to the "private-name" ABNF above. " =3D=3D=3DEnd of changes=3D=3D=3D Is the new text correct or did I miss something? Thank you Laura 2012/2/20 Paul Kyzivat : > On 2/20/12 3:51 PM, Worley, Dale R (Dale) wrote: >>> >>> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >>> >>> For the private ones, that aren't registered with IANA, you already >>> brought up the problem of dns names that are customarily represented in >>> mixed case. We already know that dns names are required to be case >>> insensitive, so we won't have a conflict between Example.com and >>> example.com. I find it very unnatural to require the same name to be >>> represented all in lower case in the URN. >> >> >> I don't remember bringing it up, but you're right that it complicates >> things. In theory it's no more complex. But in practice, people will >> not universally downcase DNS names. >> >> So how should we adjust the rules? We want case-insensitive >> comparison. Should we say "Comparisons are case-insensitive. >> Transmitted URNs SHOULD be in lower case. Registered URNs MUST be >> lower case."? > > > IMO: > > Comparisons MUST be case-insensitive. > > Registered URNs SHOULD be transmitted as registered. > > A new name MUST NOT be registered if it is equal by case-insensitive > comparison to an already registered name. > > Thanks, > Paul > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud