From laura.liess.dt@googlemail.com Thu Mar 1 02:41:50 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 6039A21F8714 for ; Thu, 1 Mar 2012 02:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 W5pbKVSchB2m for ; Thu, 1 Mar 2012 02:41:47 -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 8F61721F86C9 for ; Thu, 1 Mar 2012 02:41:46 -0800 (PST) Received: by werb10 with SMTP id b10so342597wer.31 for ; Thu, 01 Mar 2012 02:41:45 -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 hb3mr9295538wib.5.1330598505606 (num_hops = 1); Thu, 01 Mar 2012 02:41:45 -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=FlA3v3Swr2RXGCRhxBQsz5fNTj/0UiyggnJRMwPF3Jo=; b=Yv1g8eKZBap/VXCuBGqwY2qwwL4Jc54H4Ot/qVx9RjVQMz+9auvsDs3jJ1h4VxPZRl TeTg3VRYYKONxqH3Ge+1MbTCKbztRIZi1C2m3wWVl+wqOj9D9a/S6KI00gIYX8digkTv rRvrF77SVkyJF9r1YndWayhiE3fQgZGoCD5J0= MIME-Version: 1.0 Received: by 10.180.107.99 with SMTP id hb3mr7450404wib.5.1330598505542; Thu, 01 Mar 2012 02:41:45 -0800 (PST) Received: by 10.227.112.206 with HTTP; Thu, 1 Mar 2012 02:41:45 -0800 (PST) In-Reply-To: References: <4F3332F6.1090204@alum.mit.edu> <4F356C0B.8010209@alum.mit.edu> <4F42C374.1000105@alum.mit.edu> Date: Thu, 1 Mar 2012 11:41:45 +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: Thu, 01 Mar 2012 10:41:50 -0000 Dale, Thank you. That's fine for me. Laura 2012/2/29 Worley, Dale R (Dale) : > I agree with all of this, except I would change > > =C2=A0 =C2=A0 =C2=A0alert-URN =C2=A0 =C2=A0 =C2=A0 =3D "URN:alert:" alert= -identifier > > to > > =C2=A0 =C2=A0 =C2=A0alert-URN =C2=A0 =C2=A0 =C2=A0 =3D "urn:alert:" alert= -identifier > > because it seems to be the universal convention to use > "urn" to start URNs. =C2=A0(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 pag= e 13: > > =3D=3D=3D-Begin of changes =3D=3D=3D > Change #1: > Old text: > "The alert-indications are hierarchical identifiers, consisting of > =C2=A0 =C2=A0 =C2=A0one label or a sequence of labels separated by colons= . =C2=A0The set of > =C2=A0 =C2=A0 =C2=A0allowable characters is the same as that for domain n= ames > =C2=A0 =C2=A0 =C2=A0[RFC1123]. =C2=A0Labels are case-insensitive, but MUS= T be specified in > =C2=A0 =C2=A0 =C2=A0all lower-case." > > New text: > "The alert-indications are hierarchical identifiers. The set of > =C2=A0 =C2=A0 =C2=A0allowable characters is the same as that for domain n= ames > =C2=A0 =C2=A0 =C2=A0[RFC1123]. =C2=A0Labels are case-insensitive. Compari= sons 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: > =C2=A0 =C2=A0 =C2=A0 " alert-URN =C2=A0 =C2=A0 =C2=A0 =3D "URN:alert:" al= ert-identifier > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-identifier=3D alert-category ":" alert-i= ndication > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-category =C2=A0=3D name > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-indication=3D name *(":" name) > =C2=A0 =C2=A0 =C2=A0 =C2=A0name =3D let-dig [ *let-dig-hyp let-dig ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0let-dig-hyp =C2=A0 =C2=A0 =3D let-dig / "-" > =C2=A0 =C2=A0 =C2=A0 =C2=A0let-dig =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D ALPHA = / DIGIT > =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 > =C2=A0 =C2=A0 =C2=A0 =C2=A0DIGIT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %= x30-39 ; 0-9 " > > New text: > =C2=A0 =C2=A0 =C2=A0" alert-URN =C2=A0 =C2=A0 =C2=A0 =3D "URN:alert:" ale= rt-identifier > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-identifier=3D alert-category ":" alert-i= ndication > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-category =C2=A0=3D name > =C2=A0 =C2=A0 =C2=A0 =C2=A0alert-indication=3D name *(":" name) > =C2=A0 =C2=A0 =C2=A0 =C2=A0name =3D standard-name / private-name > =C2=A0 =C2=A0 =C2=A0 =C2=A0standard-name =3D label > =C2=A0 =C2=A0 =C2=A0 =C2=A0private-name =3D label "." label *[ "." label = ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0label =3D let-dig [ *let-dig-hyp let-dig ] > =C2=A0 =C2=A0 =C2=A0 =C2=A0let-dig-hyp =C2=A0 =C2=A0 =3D let-dig / "-" > =C2=A0 =C2=A0 =C2=A0 =C2=A0let-dig =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D ALPHA = / DIGIT > =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 > =C2=A0 =C2=A0 =C2=A0 =C2=A0DIGIT =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D %= x30-39 ; 0-9 > > Throughout this document, "" is used as a syntactic > =C2=A0 variable for any string conformant to the "private-name" ABNF > =C2=A0 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 i= n >>>> 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, pe= ople 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 laura.liess.dt@googlemail.com Fri Mar 9 08:06:53 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 C22AC21F8716 for ; Fri, 9 Mar 2012 08:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 QGpOvo5BUmoz for ; Fri, 9 Mar 2012 08:06:53 -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 C1F7F21F8710 for ; Fri, 9 Mar 2012 08:06:46 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1241846wgb.13 for ; Fri, 09 Mar 2012 08:06:46 -0800 (PST) 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=DS76nGoBqBr0PH3AWSL4Zg2cGHi1AN/Wff1upVFTvsw=; b=VXuTFRbBwa2exiWglIUp9jlR7krb7jNuUffXnyMy3d/lYh9/fW5NjT8cqiUu1HkPpY TVnlk8QfZg3yoZeX4FfsyHERL04yUzSL9Xgy3VOgx9K1xByxS3hiBxN4psxuws+XSt43 PhjiCQA2U9eeO41wpxTSTelZVEXLALGqin+4QHRTl/pqBzCdHn9dNfmosyGq6KD2Rj9j njpy6K70GCB9JDeW/YTZGGZp2ShdwM2udoqm7IsJy8RHDBzSnmrtat/tcGzZbYFlXKVW 5VM62Qeuz7XnKe3m2/gIJDIcs1xGU95VTqBkIk7MVmz5CbyhfdWc7Sc5OqYqnoAklPHM wZRw== MIME-Version: 1.0 Received: by 10.180.80.35 with SMTP id o3mr6152373wix.5.1331309206033; Fri, 09 Mar 2012 08:06:46 -0800 (PST) Received: by 10.227.112.206 with HTTP; Fri, 9 Mar 2012 08:06:45 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Mar 2012 17:06:45 +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: Fri, 09 Mar 2012 16:06:53 -0000 Dale, I found out that I miss to answer following of yours comments in http://www.ietf.org/mail-archive/web/salud/current/msg00207.html : 2012/2/8 Worley, Dale R (Dale) : > [as individual] > > I'm finally starting to read Laura's new -05 draft, and clearly we are > getting close to finished. =C2=A0This message mentions a number of minor > points. ......... >Section 4 ..... > > 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. > [LL] This draft text is very old (written before I took over the draft editorship). I think it is based on the corresponding paragraph in the RFC 5031. However, text doesn=E2=80=99t really fit the current version of t= he draft. I would modify it as follows: >> An Alert-Info URN identifies a logical rendering at the caller=E2=80=99s= or callee=E2=80=99s end device. A logical rendering identified by an Ale= rt-Info URN is persistent and unique; this is guaranteed through the IANA = registration of each alert-category and alert-identifiers as described in = Section 11.<< I am fully open for better ideas or wording for this text. Thanks a lot Laura From dworley@avaya.com Thu Mar 15 14:47:52 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 D9C0F21E802C for ; Thu, 15 Mar 2012 14:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 zRiGlmrjk94g for ; Thu, 15 Mar 2012 14:47:52 -0700 (PDT) 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 9DD7921E801E for ; Thu, 15 Mar 2012 14:47:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPZhYk/GmAcF/2dsb2JhbABDpD2RbYEHggkBAgEDEihRARUIIUInBBMIGodoC5lLhBucEYo8hWhjBJtvihmDAoE4 X-IronPort-AV: E=Sophos;i="4.73,593,1325480400"; d="scan'208";a="297387250" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Mar 2012 17:47:49 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Mar 2012 17:39:49 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 15 Mar 2012 17:47:48 -0400 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Thu, 15 Mar 2012 17:47:29 -0400 Thread-Topic: Sections 9 and 10 Thread-Index: AQHNAvVC23uVlEwUFEO7EIXZX/HW+w== 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] Sections 9 and 10 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, 15 Mar 2012 21:47:53 -0000 I'm looking at sections 9 and 10, "User Agent Behavior" and "Proxy Behavior". I think that the statements about "disturbing interference" need to be limited to requirements on the receiver of the Alert-Info, because there is no way that the sender can be sure what might cause the receiver to produce a disturbing rendering. So I think we can improve the wording in the following way: 9. User Agent Behaviour [-05 text:] A SIP UA MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response excepting 100 response when it needs to provide additional information about the call or about the provided service. A SIP UA SHOULD NOT add a mixture of Alert-Info URNs and URIs to the Alert-Info header field that may cause disturbing rendering interference at the recipient's User Agent (UA). [suggested replacement:] A SIP UA MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to (wishes to?) provide additional information about the call or about the provided service. [-05 text:] Upon receiving a SIP INVITE request or a SIP provisional response with an Alert-Info header field that contains a combination of Alert- Info URNs, the User Agent (UA) attempts to match the received Alert- Info URNs combination with a signal it can render. The mandatory rules and an non-normative algorythm example are described in Section 7 and Section 8. The User Agent (UA) ignores the Alert-Info URNs for which no match is found and proceeds with the normal operation. [suggested replacement:] Upon receiving a SIP INVITE request or a SIP provisional response with an Alert-Info header field that contains a combination of Alert- Info URNs, the User Agent (UA) attempts to match the received Alert- Info URNs combination with a signal it can render. The process the UA uses MUST conform to the rules described in Section 7. (A non-normative algorithm example for the process is described in Section 8.) [discussion:] I've omitted the sentence "... ignores the Alert-Info URNs form which no match ...", because that is already stated in rule (b) in Section 7. [-05 text:] The User Agent (UA) is responsible for the non disturbing rendering if multiple indications and network resources are to be rendered simultaneously. [suggested replacement:] The User Agent (UA) is responsible for producing a reasonable rendering regardless of the combination of URIs (of any schemes) in the Alert-Info header field. [discussion:] This places the burden on the receiver not to produce a disturbing rendering regardless of the Alert-Info header values. 10. Proxy Behaviour [-05 text:] A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response excepting 100 response when it needs to provide additional information about the call or about the provided service. A SIP Proxy SHOULD NOT add a mixture of Alert-Info URNs and URIs to the Alert-Info header field that may cause disturbing rendering interference at the recipient's User Agent (UA). [suggested replacement:] A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to (wishes to?) provide additional information about the call or about the provided service. [discussion:] Similarly, I don't think there is a way that a proxy can tell what might cause a problem for a UA. So we have to allow the proxy to do anything. [-05 text:] Following example shows both the network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service transported by the Alert-Info header field in a 180 Ringing provisional response. [-05 text:] Alert-Info: , [suggested replacement:] SIP/2.0 180 Ringing Alert-Info: , To: Bob ;tag=3Da6c85cf From: Alice ;tag=3D1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Via: SIP/2.0/UDP server10.biloxi.example.com;branch=3Dz9hG4bK4b43c2ff8.1 Content-Length: 0 [discussion:] I stole an examle 180 Ringing response from RFC 3261 and inserted the Alert-Info example into it so that the reader can see a complete SIP response with Alert-Info. Some might consider "moo.wav" as a "disturbing" rendering of a ringback tone! ;-) Dale From dworley@avaya.com Fri Mar 16 13:58:16 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 BAB3C21F8623 for ; Fri, 16 Mar 2012 13:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 3VxjB0PeEAS5 for ; Fri, 16 Mar 2012 13:58:16 -0700 (PDT) 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 F08FD21F8622 for ; Fri, 16 Mar 2012 13:58:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACKoY0/GmAcF/2dsb2JhbABCtjqBB4IQEihRARUpQicEGxqHaJkghBuMDJAjkBpjBJt0ihmDAg X-IronPort-AV: E=Sophos;i="4.73,599,1325480400"; d="scan'208";a="297569006" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Mar 2012 16:58:14 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Mar 2012 16:50:11 -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; Fri, 16 Mar 2012 16:58:13 -0400 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Fri, 16 Mar 2012 16:57:40 -0400 Thread-Topic: Section 12 Thread-Index: AQHNA7eAKkpV55yJJkWToLzT69C9XQ== 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] Section 12 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, 16 Mar 2012 20:58:16 -0000 12. Internationalization Considerations The alert-identifier labels are protocol elements [RFC6365] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 11. I think we can add: The URNs "urn:alert:locale:country:" select renderings that are conventional in the specified country. Dale From laura.liess.dt@googlemail.com Mon Mar 19 02:35: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 532FA21F860B for ; Mon, 19 Mar 2012 02:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, 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 i1ODzQ9sdNuw for ; Mon, 19 Mar 2012 02:35:35 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E02B221F8606 for ; Mon, 19 Mar 2012 02:35:34 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2739588wib.13 for ; Mon, 19 Mar 2012 02:35:33 -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=SewS0prmUa1oZCv60kteW78QQKbfiUXrR3ujj3eDUCY=; b=n4n94WuHigmCO+3ixV51lyRP1speFHi5C6X2JniFaAZLBzQ2MT96b+7wMdFWDVdaUK UO1jQsZyamXBeXwzNHmxTAKj2wkvdCry7XywvqHiDTZXvEyzWGnk9okRomkB3bpPHAPj uAtug4M+1PEEfQF5WvtYDvhHOBTe+gObMX230b9KztOhlYoSmR7v0fOQ3f6AaKU3GKb2 +TzLOMb6W5kn5WdqlAI/cwHhgAgpEOa62NSH5FI9G/LaS7OD4b4DDhAThOZUYSd4d8A5 cLTe9MRTPyvSuIPAm5Mhq91fyncD+tSFzPVLd1AW94W3w5b4opuotVf+XPw49u0lCeJ1 qH+g== MIME-Version: 1.0 Received: by 10.180.83.72 with SMTP id o8mr18304860wiy.5.1332149733596; Mon, 19 Mar 2012 02:35:33 -0700 (PDT) Received: by 10.227.112.206 with HTTP; Mon, 19 Mar 2012 02:35:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Mar 2012 10:35:33 +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] Sections 9 and 10 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, 19 Mar 2012 09:35:36 -0000 Dale, I agree with your comments. > [discussion:] > This places the burden on the receiver not to produce a > disturbing rendering regardless of the Alert-Info header > values. It is very reasonable to do this also because there may be more than one entities inserting Alert-Info URNs. Requiring that a proxy in the path adding an Alert-Info URN has to inspect all other URNs in the header in order to avoid disturbing rendering would be a quite high burden for the proxy. Thanks Laura 2012/3/15 Worley, Dale R (Dale) : > I'm looking at sections 9 and 10, "User Agent Behavior" and "Proxy > Behavior". =C2=A0I think that the statements about "disturbing > interference" need to be limited to requirements on the receiver of > the Alert-Info, because there is no way that the sender can be sure > what might cause the receiver to produce a disturbing rendering. =C2=A0So= I > think we can improve the wording in the following way: > > =C2=A0 9. =C2=A0User Agent Behaviour > > =C2=A0 [-05 text:] > =C2=A0 A SIP UA MAY add a URN or multiple URNs to the Alert-Info header > =C2=A0 field in a SIP request or a provisional 1xx response excepting 100 > =C2=A0 response when it needs to provide additional information about the > =C2=A0 call or about the provided service. =C2=A0A SIP UA SHOULD NOT add = a > =C2=A0 mixture of Alert-Info URNs and URIs to the Alert-Info header field > =C2=A0 that may cause disturbing rendering interference at the recipient'= s > =C2=A0 User Agent (UA). > > =C2=A0 =C2=A0 =C2=A0[suggested replacement:] > =C2=A0 =C2=A0 =C2=A0A SIP UA MAY add a URN or multiple URNs to the Alert-= Info header > =C2=A0 =C2=A0 =C2=A0field in a SIP request or a provisional 1xx response = (excepting a 100 > =C2=A0 =C2=A0 =C2=A0response) when it needs to (wishes to?) provide addit= ional > =C2=A0 =C2=A0 =C2=A0information about the call or about the provided serv= ice. > > =C2=A0 [-05 text:] > =C2=A0 Upon receiving a SIP INVITE request or a SIP provisional response > =C2=A0 with an Alert-Info header field that contains a combination of Ale= rt- > =C2=A0 Info URNs, the User Agent (UA) attempts to match the received Aler= t- > =C2=A0 Info URNs combination with a signal it can render. =C2=A0The manda= tory > =C2=A0 rules and an non-normative algorythm example are described in > =C2=A0 Section 7 and Section 8. =C2=A0The User Agent (UA) ignores the Ale= rt-Info > =C2=A0 URNs for which no match is found and proceeds with the normal > =C2=A0 operation. > > =C2=A0 =C2=A0 =C2=A0[suggested replacement:] > =C2=A0 =C2=A0 =C2=A0Upon receiving a SIP INVITE request or a SIP provisio= nal response > =C2=A0 =C2=A0 =C2=A0with an Alert-Info header field that contains a combi= nation of Alert- > =C2=A0 =C2=A0 =C2=A0Info URNs, the User Agent (UA) attempts to match the = received Alert- > =C2=A0 =C2=A0 =C2=A0Info URNs combination with a signal it can render. = =C2=A0The process > =C2=A0 =C2=A0 =C2=A0the UA uses MUST conform to the rules described in Se= ction 7. > =C2=A0 =C2=A0 =C2=A0(A non-normative algorithm example for the process is= described > =C2=A0 =C2=A0 =C2=A0in Section 8.) > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 [discussion:] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I've omitted the sentence "... ignores the Al= ert-Info URNs > =C2=A0 =C2=A0 =C2=A0 =C2=A0 form which no match ...", because that is alr= eady stated in > =C2=A0 =C2=A0 =C2=A0 =C2=A0 rule (b) in Section 7. > > =C2=A0 [-05 text:] > =C2=A0 The User Agent (UA) is responsible for the non disturbing renderin= g > =C2=A0 if multiple indications and network resources are to be rendered > =C2=A0 simultaneously. > > =C2=A0 =C2=A0 =C2=A0[suggested replacement:] > =C2=A0 =C2=A0 =C2=A0The User Agent (UA) is responsible for producing a re= asonable > =C2=A0 =C2=A0 =C2=A0rendering regardless of the combination of URIs (of a= ny schemes) > =C2=A0 =C2=A0 =C2=A0in the Alert-Info header field. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 [discussion:] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This places the burden on the receiver not to= produce a > =C2=A0 =C2=A0 =C2=A0 =C2=A0 disturbing rendering regardless of the Alert-= Info header > =C2=A0 =C2=A0 =C2=A0 =C2=A0 values. > > =C2=A0 10. =C2=A0Proxy Behaviour > > =C2=A0 [-05 text:] > =C2=A0 A SIP proxy MAY add a URN or multiple URNs to the Alert-Info heade= r > =C2=A0 field in a SIP request or a provisional 1xx response excepting 100 > =C2=A0 response when it needs to provide additional information about the > =C2=A0 call or about the provided service. =C2=A0A SIP Proxy SHOULD NOT a= dd a > =C2=A0 mixture of Alert-Info URNs and URIs to the Alert-Info header field > =C2=A0 that may cause disturbing rendering interference at the recipient'= s > =C2=A0 User Agent (UA). > > =C2=A0 =C2=A0 =C2=A0[suggested replacement:] > =C2=A0 =C2=A0 =C2=A0A SIP proxy MAY add a URN or multiple URNs to the Ale= rt-Info header > =C2=A0 =C2=A0 =C2=A0field in a SIP request or a provisional 1xx response = (excepting a 100 > =C2=A0 =C2=A0 =C2=A0response) when it needs to (wishes to?) provide addit= ional > =C2=A0 =C2=A0 =C2=A0information about the call or about the provided serv= ice. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 [discussion:] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Similarly, I don't think there is a way that = a proxy can tell > =C2=A0 =C2=A0 =C2=A0 =C2=A0 what might cause a problem for a UA. =C2=A0So= we have to allow the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy to do anything. > > =C2=A0 [-05 text:] > =C2=A0 Following example shows both the network audio resource referenced= by > =C2=A0 the HTTP URI and the URN indication for the call-waiting service > =C2=A0 transported by the Alert-Info header field in a 180 Ringing > =C2=A0 provisional response. > > =C2=A0 [-05 text:] > =C2=A0 =C2=A0 =C2=A0Alert-Info: , > =C2=A0 =C2=A0 =C2=A0 > > =C2=A0 =C2=A0 =C2=A0[suggested replacement:] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 SIP/2.0 180 Ringing > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alert-Info: , > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Bob ;tag=3Da6= c85cf > =C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Alice ;t= ag=3D1928301774 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Call-ID: a84b4c76e66710 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Contact: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 CSeq: 314159 INVITE > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Via: SIP/2.0/UDP server10.biloxi.example.com;= branch=3Dz9hG4bK4b43c2ff8.1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Content-Length: 0 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 [discussion:] > =C2=A0 =C2=A0 =C2=A0 =C2=A0 I stole an examle 180 Ringing response from R= FC 3261 and > =C2=A0 =C2=A0 =C2=A0 =C2=A0 inserted the Alert-Info example into it so th= at the reader > =C2=A0 =C2=A0 =C2=A0 =C2=A0 can see a complete SIP response with Alert-In= fo. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Some might consider "moo.wav" as a "disturbin= g" rendering of > =C2=A0 =C2=A0 =C2=A0 =C2=A0 a ringback tone! =C2=A0;-) > > Dale > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From laura.liess.dt@googlemail.com Fri Mar 23 06:15:35 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 C22EC21F850F for ; Fri, 23 Mar 2012 06:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 r9vgsmmX7PkP for ; Fri, 23 Mar 2012 06:15:31 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 401BC21F8464 for ; Fri, 23 Mar 2012 06:15:31 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1457508wgb.13 for ; Fri, 23 Mar 2012 06:15:30 -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 :content-type:content-transfer-encoding; bh=08mfJunrCI+4CK3gmB/PVAK8IZPLXXH4c4SOHS9UdDk=; b=UkFNcylhlkrbM88PH52FxbdI5Ynp1Vg4Dc1pmdtV8tmvsuLgYOAwJ/hz9yf3RQ5VlM nHfK0P8INzwigvqsbvR6KIBQw8oSYLX1vpbsvpQnboL74GEQmBqKE5xurXHo9dlSKJRP 0nKon9tiHhxAoX6HDvamUm3Xxs4eD/9tyvNyfb0xNSvz7OoYqEzQPcBCKWnCXFFDbQGB HVD5HvnMIFERyqZFO42vOnpSmXLKWXbVtdgLqhuaVTN5z2W2iYMSrePtbu1KXgCrLUI5 W4rQhqIyosoRcjfpPiMuA75r66c7k/qLreBk9VFhJVihlDI1Y/9cediUWp4nY7Sj6xye 7wOg== MIME-Version: 1.0 Received: by 10.180.83.72 with SMTP id o8mr6547541wiy.5.1332508530369; Fri, 23 Mar 2012 06:15:30 -0700 (PDT) Received: by 10.227.112.206 with HTTP; Fri, 23 Mar 2012 06:15:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Mar 2012 14:15:30 +0100 Message-ID: From: Laura Liess To: "Worley, Dale R (Dale)" , "salud@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 23 Mar 2012 13:15:35 -0000 Hi, When I submit the version 06 which incorporates the received comments, the idnits tool returns following warning: " Found possible FQDN 'org.example.somecompany' in position 3; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". The warning refers to the change based on the following comment: 2012/2/8 Worley, Dale R (Dale) : > [as individual] > > > 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). > Any opinion on how to handle this issue? Thanks a lot Laura From pkyzivat@alum.mit.edu Sun Mar 25 11:44:27 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 4DDEA21F8442 for ; Sun, 25 Mar 2012 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 PkUI2fWrXjQ3 for ; Sun, 25 Mar 2012 11:44:26 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id BD82A21F8443 for ; Sun, 25 Mar 2012 11:44:26 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta15.emeryville.ca.mail.comcast.net with comcast id pubH1i0011afHeLAFukScr; Sun, 25 Mar 2012 18:44:26 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta17.emeryville.ca.mail.comcast.net with comcast id pukG1i01Z5EhBnE8dukKWE; Sun, 25 Mar 2012 18:44:24 +0000 Message-ID: <4F6F6782.5000903@alum.mit.edu> Date: Sun, 25 Mar 2012 20:44:18 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: salud@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: Sun, 25 Mar 2012 18:44:27 -0000 On 3/23/12 2:15 PM, Laura Liess wrote: > Hi, > > When I submit the version 06 which incorporates the received comments, > the idnits tool returns following warning: > > " Found possible FQDN 'org.example.somecompany' in position 3; this > doesn't match RFC 2606's suggested ".example" or > ".example.(com|org|net)". > > The warning refers to the change based on the following comment: [snip] >> 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. [snip] > Any opinion on how to handle this issue? The nits tool as generated a false positive here. It found a "possible FQDN" but the problem isn't real because it isn't actually an FQDN. The nits tool is not normative. So I think the solution is for the document shepherd to mention in the proto writeup that the nits tool falsely reports this. Thanks, Paul From dworley@avaya.com Mon Mar 26 15:01:50 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 F0C5321E802A for ; Mon, 26 Mar 2012 15:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 uGg-9dqpKIU1 for ; Mon, 26 Mar 2012 15:01:49 -0700 (PDT) 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 8E1D521E8054 for ; Mon, 26 Mar 2012 15:01:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH/lcE/GmAcF/2dsb2JhbABEuD6BB4IJAQEBAQIBEmcQAgEIDQQEAQEvMh0IAQEEDgUIARmHYwULnR+cA4lxdoVFYwSbcYocgwOBQA X-IronPort-AV: E=Sophos;i="4.75,322,1330923600"; d="scan'208";a="298999645" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Mar 2012 18:01:43 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Mar 2012 17:53:06 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 26 Mar 2012 18:01:42 -0400 From: "Worley, Dale R (Dale)" To: Laura Liess Date: Mon, 26 Mar 2012 17:59:52 -0400 Thread-Topic: [salud] -05: Mostly editorial issues Thread-Index: Acz+DqlDVgADo9bDRTmIp9HVI43IJgNjRuDU Message-ID: References: , 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="Windows-1252" 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, 26 Mar 2012 22:01:50 -0000 Looking at both versions of this paragraph, I think that the text dates to before we settled on the "multiple URN approach", and the text is now incorrect. I've tried to rewrite it so that it describes each URN as identifying a "feature" of the rendering. I'm not sure we want to introduce a new word ("feature") in this paragraph, but maybe someone can see a better way to describe it. Here is my draft: >> An Alert-Info URN identifies a semantic or sensory feature of alert rendering at the caller=92s or callee=92s end device. The feature identified by a particular Alert-Info URN is persistent and distinct from the feature identified any other Alert-Info URN through the IANA registration of each Alert-Info URN (that is, each defined combination of alert-category and alert-identifier) as described in Section 11.<< Dale ________________________________________ From: Laura Liess [laura.liess.dt@googlemail.com] Sent: Friday, March 09, 2012 11:06 AM To: Worley, Dale R (Dale) Cc: salud@ietf.org; Paul Kyzivat Subject: Re: [salud] -05: Mostly editorial issues Dale, I found out that I miss to answer following of yours comments in http://www.ietf.org/mail-archive/web/salud/current/msg00207.html : 2012/2/8 Worley, Dale R (Dale) : > [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. ......... >Section 4 ..... > > 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. > [LL] This draft text is very old (written before I took over the draft editorship). I think it is based on the corresponding paragraph in the RFC 5031. However, text doesn=92t really fit the current version of the draft. I would modify it as follows: >> An Alert-Info URN identifies a logical rendering at the caller=92s or ca= llee=92s end device. A logical rendering identified by an Alert-Info URN = is persistent and unique; this is guaranteed through the IANA registration= of each alert-category and alert-identifiers as described in Section 11.<= < I am fully open for better ideas or wording for this text. Thanks a lot Laura From laura.liess.dt@googlemail.com Tue Mar 27 07:09: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 40D8A21E820E for ; Tue, 27 Mar 2012 07:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, 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 t03nkEVTc7H4 for ; Tue, 27 Mar 2012 07:09:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E45D921E81FC for ; Tue, 27 Mar 2012 07:09:10 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4412979wib.13 for ; Tue, 27 Mar 2012 07:09:10 -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=Sl3XvKIFq/xwPvMMch4+R6xdUduk2AAMbFWbG3XcvNc=; b=p8j+GOieWGGHXat0t1aEim+H4Ge6Xp+YleZoNLy8ldJsh1cIjX0oizHP64dVBStJqT cMrEsa6bqv6/1+brWV6XBv92yhbxMGQRExpwaLcTprL1fqN7aJ5aZAzKZLB+iCK3GNHH IemoCYg8ZfviwkMgj+27cXkYyM/2+gx+PQWhnz5LuPSUkVEvMTJng8gP3Fz4il5IxhR+ yT0tiAgD92nMkLLLw3uf/rqYuauJu78oP8tmwpvJau/YpCTTS2TaLu4ecQSqLjTbBXUr Di1aunO6Zp8fXGGavH5j6D/kXq2MWLqy0u/zIL/qBGT76GrAaKvsFA+93Y94GukV5Vkp MiaA== MIME-Version: 1.0 Received: by 10.180.88.169 with SMTP id bh9mr28265792wib.5.1332857349956; Tue, 27 Mar 2012 07:09:09 -0700 (PDT) Received: by 10.227.112.206 with HTTP; Tue, 27 Mar 2012 07:09:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 16:09:09 +0200 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: Tue, 27 Mar 2012 14:09:20 -0000 I am OK with it. Laura 2012/3/26 Worley, Dale R (Dale) : > Looking at both versions of this paragraph, I think that the text > dates to before we settled on the "multiple URN approach", and the > text is now incorrect. > > I've tried to rewrite it so that it describes each URN as identifying a > "feature" of the rendering. =C2=A0I'm not sure we want to introduce a new > word ("feature") in this paragraph, but maybe someone can see > a better way to describe it. =C2=A0Here is my draft: > >>> An Alert-Info URN identifies a semantic or sensory feature of alert > =C2=A0 rendering at the caller=E2=80=99s or callee=E2=80=99s end device. = =C2=A0The feature > =C2=A0 identified by a particular Alert-Info URN is persistent and > =C2=A0 distinct from the feature identified any other Alert-Info URN > =C2=A0 through the IANA registration of each Alert-Info URN (that is, eac= h > =C2=A0 defined combination of alert-category and alert-identifier) as > =C2=A0 described in Section 11.<< > > Dale > > ________________________________________ > From: Laura Liess [laura.liess.dt@googlemail.com] > Sent: Friday, March 09, 2012 11:06 AM > To: Worley, Dale R (Dale) > Cc: salud@ietf.org; Paul Kyzivat > Subject: Re: [salud] -05: Mostly editorial issues > > Dale, > > I found out that I miss to answer following of yours comments in > http://www.ietf.org/mail-archive/web/salud/current/msg00207.html : > > > 2012/2/8 Worley, Dale R (Dale) : >> [as individual] >> >> I'm finally starting to read Laura's new -05 draft, and clearly we are >> getting close to finished. =C2=A0This message mentions a number of minor >> points. > ......... >>Section 4 > ..... >> >> I'm not sure I understand this paragraph: >> >> =C2=A0 Identifier uniqueness considerations: =C2=A0An Alert-Info URN ide= ntifies a >> =C2=A0 =C2=A0 =C2=A0logical service or tone, specified in the alert-indi= cation >> =C2=A0 =C2=A0 =C2=A0registration (see Section 11). =C2=A0Resolution of t= he registered URN >> =C2=A0 =C2=A0 =C2=A0will return a particular instance of the alert ident= ifier. =C2=A0Alert >> =C2=A0 =C2=A0 =C2=A0identifier URNs MUST be unique for each unique indic= ation; this is >> =C2=A0 =C2=A0 =C2=A0guaranteed through the registration of each alert in= dication >> =C2=A0 =C2=A0 =C2=A0within this namespace, described in Section 11. >> > > [LL] This draft text is very old (written before I took over the draft > editorship). I think it is based on the corresponding paragraph in the > RFC 5031. However, text doesn=E2=80=99t really fit the current version of= the > draft. I would modify it as follows: > >>> An Alert-Info URN identifies a logical rendering at the caller=E2=80=99= s or callee=E2=80=99s end device. =C2=A0 A logical rendering identified by = an Alert-Info URN is persistent and unique; this is guaranteed through the = IANA =C2=A0registration of each alert-category and alert-identifiers as =C2= =A0described in Section 11.<< > > I am fully open for better ideas or wording for this text. > > Thanks =C2=A0a lot > Laura