From nobody Fri Apr 11 10:33:18 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F89E1A0727 for ; Fri, 11 Apr 2014 10:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZVqRyas8sDx for ; Fri, 11 Apr 2014 10:33:14 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1018E1A070D for ; Fri, 11 Apr 2014 10:33:14 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wn1so6391876obc.2 for ; Fri, 11 Apr 2014 10:33:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=czC+furOSJjZWgcWEAMACq5jhhSevp0M1PBGfkKIIdQ=; b=mj0S14NgukAQC+KcqROEZHEEwMzrb7jMOBMQEf6Ygbb6lrKz5lOIslLyV8zqDO0HQk tM8GOQCTOR0dR999KbzjBle9bHXFGU5109eVNyPhnOe5uduz1E33ezt1X/eN4Ll23hXy Qm1miyO9HRZ7kXp4rP22dNa8IX6RCii5OmL1YVKt1Y7YN17FWg3fFQe5+07yifbFpBSE KUMyYrPA1gWm7y4zeKOyBW0V3hK9ikojrQt0YBlZEN5RCbQhoRrNEuTW6RhttDfsTaVd GxTpiGs6xwVruOFrYRJ4lRjTrnbOBEMkcJhI69FrGnvLWyTEjcgobmgXDR0HR3sll+3W R7QQ== X-Gm-Message-State: ALoCoQneLie6a9PoqQLEzmjsKPv3V5unZEkfLjWuGgWa2uv8dmiw0B4F+dmaVfzIPaIkeTX99P9i MIME-Version: 1.0 X-Received: by 10.182.135.228 with SMTP id pv4mr2559250obb.62.1397237592585; Fri, 11 Apr 2014 10:33:12 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Fri, 11 Apr 2014 10:33:12 -0700 (PDT) Date: Fri, 11 Apr 2014 13:33:12 -0400 Message-ID: From: Richard Barnes To: draft-ietf-salud-alert-info-urns@tools.ietf.org, salud@ietf.org Content-Type: multipart/alternative; boundary=089e0112c5d25fa4f504f6c7ba6c Archived-At: http://mailarchive.ietf.org/arch/msg/salud/hT1dDM_VPHPauFSWj5ktHuXNyNw Subject: [salud] AD review of draft-ietf-salud-alert-info-urns-12 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 17:33:16 -0000 --089e0112c5d25fa4f504f6c7ba6c Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document in preparation for IETF LC. Thanks for a clearly written document! I especially liked the style of the Terminology section. I've requested LC, and a few comments to address along with any LC comments are below. Thanks, --Richard Some of the values in Section 8.2 have internal colons, which seems like you're actually defining two things. But it's not meaningful to remove the final label. Should these use a different separator? In 8.2.6, do you want a language tag instead of a country? It seems like the tables in 9.2.* could be collapsed into one. It's not clear to me why you need all the date machinery in provider IDs. This things are ephemeral -- why not just use the org that has the domain now? Section 13 says that the UA MUST provide a "reasonable rendering". How do I tell if a UA meets that criterion? Might be better to add in Section 11 a requirement of the form, "if a UA cannot process the set of Alert URNs in a message, then it MUST still provide some alert (chosen by local policy). Failure to parse Alert URNs MUST NOT cause a UA not to alert at a all." --089e0112c5d25fa4f504f6c7ba6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document in preparation for IETF= LC. =A0Thanks for a clearly written document! =A0I especially liked the st= yle of the Terminology section. =A0I've requested LC, and a few comment= s to address along with any LC comments are below.=A0

Thanks,
--Richard

So= me of the values in Section 8.2 have internal colons, which seems like you&= #39;re actually defining two things. =A0But it's not meaningful to remo= ve the final label. =A0Should these use a different separator?

In 8.2.6, do you want a language tag instead of a count= ry?

It seems like the tables in 9.2.* could be col= lapsed into one.=A0

It's not clear to me why y= ou need all the date machinery in provider IDs. =A0This things are ephemera= l -- why not just use the org that has the domain now?

Section 13 says that the UA MUST provide a "reason= able rendering". =A0 How do I tell if a UA meets that criterion? =A0Mi= ght be better to add in Section 11 a requirement of the form, "if a UA= cannot process the set of Alert URNs in a message, then it MUST still prov= ide some alert (chosen by local policy). =A0Failure to parse Alert URNs MUS= T NOT cause a UA not to alert at a all."
--089e0112c5d25fa4f504f6c7ba6c-- From nobody Fri Apr 11 12:20:51 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC81A0734 for ; Fri, 11 Apr 2014 12:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN4kiQyXxf53 for ; Fri, 11 Apr 2014 12:20:46 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D01A072A for ; Fri, 11 Apr 2014 12:20:45 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id ohcP1n00817dt5G5AjLkhg; Fri, 11 Apr 2014 19:20:44 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta13.westchester.pa.mail.comcast.net with comcast id ojLh1n0031KKtkw3ZjLh3o; Fri, 11 Apr 2014 19:20:43 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3BJKeY2012896; Fri, 11 Apr 2014 15:20:40 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3BJKelZ012894; Fri, 11 Apr 2014 15:20:40 -0400 Date: Fri, 11 Apr 2014 15:20:40 -0400 Message-Id: <201404111920.s3BJKelZ012894@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Richard Barnes In-reply-to: (rlb@ipv.sx) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397244044; bh=IBtw/Lm99NNvlnG8ckqOPWoLcgDTCeAb0c2CLF6WyOg=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=J+rTdT2UKcQickq8GgDFeJwNg4BF6cc73aLIm6wZHKarIO1jU8WfOWikySHzAVd9n /YXhT9kvrhVkdixqASsayxoC5zI15VyM/kpWstMk/qiQPdNtz6SSiE8P3DS1q8pY9h oHJ+X0jtw3fvliW8Pdb2WEwKxboMGlX2gBNvMFSBfLpL9IOzV5j8JrV6lg9D6LqPMS Er4q9KZmr0nY6/IclwBiBZzB0WdoJqdD8n+V7b8SFCTiY3/GssF5OZUaZkLbqBwpX/ gyuyXttyCP65JU9X1fP61tJh4cpMrD4s3RLZkoo8sgNFO+OEXTQ4ybB/pC0/OoTRBo sEzL621urtfWA== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/5fgztCPY7YhlKIuR2LS7zWg0uW4 Cc: draft-ietf-salud-alert-info-urns@tools.ietf.org, salud@ietf.org Subject: Re: [salud] AD review of draft-ietf-salud-alert-info-urns-12 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 19:20:48 -0000 > From: Richard Barnes > > I have reviewed this document in preparation for IETF LC. Thanks for a > clearly written document! I especially liked the style of the Terminology > section. I've requested LC, and a few comments to address along with any > LC comments are below. [as chair] Many thanks! [as an author] We will review your comments carefully. I'll start off with the one I can give an immediate answer to: > It's not clear to me why you need all the date machinery in provider IDs. > This things are ephemeral -- why not just use the org that has the domain > now? The problem is that these are URNs and so their meanings, once set, have to be fixed for all time. That point was raised vividly by the URN people. Adding the date to a domain name gives it a time-invariant meaning. And though the "visible" use of an alert-info URN is transient, from the caller to the callee, both the caller and the callee keep a list of the alert-info URNs that they understand and the meanings that they attach to them. And this is telephony equipment, which can have a lifetime of over a decade. So you don't want the expiration of some company's domain registration to require that all the phones that know of their private extension URNs to have to be reprogrammed. Dale From nobody Fri Apr 11 12:35:52 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738541A03BD for ; Fri, 11 Apr 2014 12:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcQOFWcZ4FbP for ; Fri, 11 Apr 2014 12:35:45 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id C38B21A02D4 for ; Fri, 11 Apr 2014 12:35:45 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id l6so6729476oag.11 for ; Fri, 11 Apr 2014 12:35:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1QHNT8EI+q2WC0edgDCBEfvRFZfdBHjRuhfppaNIoI8=; b=Z0A0NFcK5cY5dKETCxHCaLAqXgiiyNTapzXIYyjOi05PDkslw62vm6Y0uxZBY2IWTC 6nJw97tcTzNl5mLL1pzKDJJXyT+itYFot3GpkRCMTouy7tAkY0guWK7cZ3dM7jX9MrPh A3Dsuz1KegnbBeEa4Kz0dB2+7NUXdE9bwPc+p/jWyFkf188KrmW+nwQoLkntxpPAFZ68 IxWkPJ03bGIhPBgUj3vJly1bo9aQQshnfxsd801oO8DZsaGyEfcEBj4S9MPf55yJXZVH XAMzlYQSbuletgFNxMPC/C0NKrzf9amUaKwryY1t3/pvZKg0Y8beDZ5mFvpnd/1sGWN5 WxMQ== X-Gm-Message-State: ALoCoQlha3Z1wyTta+k8+mYylByBgC5rbweeQUPfcrSZ3uYhJ3tQwKgzKg6+1c54Bg7ILkJKoU2G MIME-Version: 1.0 X-Received: by 10.60.141.70 with SMTP id rm6mr21059862oeb.27.1397244944378; Fri, 11 Apr 2014 12:35:44 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Fri, 11 Apr 2014 12:35:44 -0700 (PDT) In-Reply-To: <201404111920.s3BJKelZ012894@hobgoblin.ariadne.com> References: <201404111920.s3BJKelZ012894@hobgoblin.ariadne.com> Date: Fri, 11 Apr 2014 15:35:44 -0400 Message-ID: From: Richard Barnes To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b33c8fa9303d104f6c970c6 Archived-At: http://mailarchive.ietf.org/arch/msg/salud/cPihRZpS42H2SCp4cpbnQaQ-IdA Cc: draft-ietf-salud-alert-info-urns@tools.ietf.org, salud@ietf.org Subject: Re: [salud] AD review of draft-ietf-salud-alert-info-urns-12 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 19:35:50 -0000 --047d7b33c8fa9303d104f6c970c6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 11, 2014 at 3:20 PM, Dale R. Worley wrote: > > From: Richard Barnes > > > > I have reviewed this document in preparation for IETF LC. Thanks for a > > clearly written document! I especially liked the style of the > Terminology > > section. I've requested LC, and a few comments to address along with any > > LC comments are below. > > [as chair] > > Many thanks! > > [as an author] > > We will review your comments carefully. > > I'll start off with the one I can give an immediate answer to: > > > It's not clear to me why you need all the date machinery in provider IDs. > > This things are ephemeral -- why not just use the org that has the domain > > now? > > The problem is that these are URNs and so their meanings, once set, > have to be fixed for all time. That point was raised vividly by the > URN people. Adding the date to a domain name gives it a > time-invariant meaning. > > And though the "visible" use of an alert-info URN is transient, from > the caller to the callee, both the caller and the callee keep a list > of the alert-info URNs that they understand and the meanings that they > attach to them. And this is telephony equipment, which can have a > lifetime of over a decade. So you don't want the expiration of some > company's domain registration to require that all the phones that know > of their private extension URNs to have to be reprogrammed. > Fair enough. Just wondering if we could simplify things, but it sounds like not. Thanks! --Richard > > Dale > --047d7b33c8fa9303d104f6c970c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 11, 2014 at 3:20 PM, Dale R. Worley <worley@ariadne.com>= wrote:
> From: Richard Barnes <rlb@ipv.sx>=
>
> I have reviewed this document in preparation for IETF LC. =A0Thanks fo= r a
> clearly written document! =A0I especially liked the style of the Termi= nology
> section. =A0I've requested LC, and a few comments to address along= with any
> LC comments are below.

[as chair]

Many thanks!

[as an author]

We will review your comments carefully.

I'll start off with the one I can give an immediate answer to:

> It's not clear to me why you need all the date machinery in provid= er IDs.
> This things are ephemeral -- why not just use the org that has the dom= ain
> now?

The problem is that these are URNs and so their meanings, once set, have to be fixed for all time. =A0That point was raised vividly by the
URN people. =A0Adding the date to a domain name gives it a
time-invariant meaning.

And though the "visible" use of an alert-info URN is transient, f= rom
the caller to the callee, both the caller and the callee keep a list
of the alert-info URNs that they understand and the meanings that they
attach to them. =A0And this is telephony equipment, which can have a
lifetime of over a decade. =A0So you don't want the expiration of some<= br> company's domain registration to require that all the phones that know<= br> of their private extension URNs to have to be reprogrammed.

Fair enough. =A0Just wondering if we could simplify th= ings, but it sounds like not. =A0Thanks!

--Richard=

=A0

Dale

--047d7b33c8fa9303d104f6c970c6-- From nobody Fri Apr 11 13:12:20 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29F1A03A8 for ; Fri, 11 Apr 2014 13:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fli2VzEIs7xF for ; Fri, 11 Apr 2014 13:12:11 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3E51A0767 for ; Fri, 11 Apr 2014 13:12:02 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta06.westchester.pa.mail.comcast.net with comcast id obtC1n00B0vyq2s56kC0kD; Fri, 11 Apr 2014 20:12:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id okC01n00m3ZTu2S3RkC0j1; Fri, 11 Apr 2014 20:12:00 +0000 Message-ID: <53484C90.9050905@alum.mit.edu> Date: Fri, 11 Apr 2014 16:12:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: salud@ietf.org References: <201404111920.s3BJKelZ012894@hobgoblin.ariadne.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397247120; bh=loz4WbCle1JfuWZvhxKy/u4VrvGD4i5+Nf+qrpWnOHE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZM49NHL3cBNrMkQWMbcTFdXqgwifZWpWwEGETsmEk5KALNmFnrVjzsYPJnlOykXyp 2V20qq78Wz28tIuSgdx6BVlPQ75Uvvdn5UKNhRowau8G1CR41XdDiMHUI1uVIfv078 ynAEnkH98qWRsgtn9Z+el+CVJyCPssOkRDOIgXk3XM6OnM6XhTETdnxd6T91CeC4ru 43B3wJE+3LOAlLSXXopWjo53ZXgzxiNZQaCOJcqgPO6cYdGVD0jzm49+pdbvhIiJ6T YfnAtlUYUtysgFkO1Wfl6kd9oR7NgyPzETZwcBrfz+iEjorppUEKDdOkhy/XiSfm8+ b5gmxhKfL12ZA== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/o1sSo5FxRPhoRzggMy4hjupsHY4 Subject: Re: [salud] AD review of draft-ietf-salud-alert-info-urns-12 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 11 Apr 2014 20:12:13 -0000 Richard, Following up on what Dale said - we originally didn't have any of the date stuff. We were "forced" to add it, for reasons Dale explained, by the URN "police". There was quite a lot of thought and effort put into the details of how the semantics are specified, and on the syntax, to make it as convenient as possible to use. (E.g., what the defaults are.) Thanks, Paul On 4/11/14 3:35 PM, Richard Barnes wrote: > On Fri, Apr 11, 2014 at 3:20 PM, Dale R. Worley > wrote: > > > From: Richard Barnes > > > > I have reviewed this document in preparation for IETF LC. Thanks > for a > > clearly written document! I especially liked the style of the > Terminology > > section. I've requested LC, and a few comments to address along > with any > > LC comments are below. > > [as chair] > > Many thanks! > > [as an author] > > We will review your comments carefully. > > I'll start off with the one I can give an immediate answer to: > > > It's not clear to me why you need all the date machinery in > provider IDs. > > This things are ephemeral -- why not just use the org that has > the domain > > now? > > The problem is that these are URNs and so their meanings, once set, > have to be fixed for all time. That point was raised vividly by the > URN people. Adding the date to a domain name gives it a > time-invariant meaning. > > And though the "visible" use of an alert-info URN is transient, from > the caller to the callee, both the caller and the callee keep a list > of the alert-info URNs that they understand and the meanings that they > attach to them. And this is telephony equipment, which can have a > lifetime of over a decade. So you don't want the expiration of some > company's domain registration to require that all the phones that know > of their private extension URNs to have to be reprogrammed. > > > Fair enough. Just wondering if we could simplify things, but it sounds > like not. Thanks! > > --Richard > > > Dale > > > > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From nobody Fri Apr 11 13:13:04 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E871A030A; Fri, 11 Apr 2014 13:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbwBpqfPwJAD; Fri, 11 Apr 2014 13:12:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A692F1A01E3; Fri, 11 Apr 2014 13:12:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140411201241.16190.24813.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 13:12:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/salud/0J0aU6J12wxdc8n2WuJ-qaZQ3n0 Cc: salud@ietf.org Subject: [salud] Last Call: (URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 11 Apr 2014 20:13:00 -0000 The IESG has received a request from the Sip ALerting for User Devices WG (salud) to consider the following document: - 'URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification. This document normatively updates the RFC 3261, which defines the Session Initiation Protocol (SIP): It changes the usage of the Alert- Info header field defined in the RFC 3261 by additionally allowing its use in all provisional responses to INVITE (except the 100 response). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-salud-alert-info-urns/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-salud-alert-info-urns/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Apr 14 17:46:10 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC97A1A06D4 for ; Mon, 14 Apr 2014 17:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXgknLg0b4lH for ; Mon, 14 Apr 2014 17:45:59 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 99B891A06C3 for ; Mon, 14 Apr 2014 17:45:58 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta06.westchester.pa.mail.comcast.net with comcast id pxZ11n0080bG4ec560lvtS; Tue, 15 Apr 2014 00:45:55 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta03.westchester.pa.mail.comcast.net with comcast id q0ls1n00Z1KKtkw3P0ltZ6; Tue, 15 Apr 2014 00:45:55 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3F0jqJi004643; Mon, 14 Apr 2014 20:45:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3F0jqY8004642; Mon, 14 Apr 2014 20:45:52 -0400 Date: Mon, 14 Apr 2014 20:45:52 -0400 Message-Id: <201404150045.s3F0jqY8004642@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Richard Barnes In-reply-to: (rlb@ipv.sx) References: <201404111920.s3BJKelZ012894@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397522755; bh=8UD8PTHuvQ2Ls3xbY/kP0XRJ/5v0AlOptHfYC/FJwSk=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=GXmwXPG2rDFgI1Oz52ZOpN/ugqTva0589CLnOq+Vs/YmNWGMhIagrIR3TX7L5wjwC Ef+miWacF7MYiExLPHcJ4Ow1NBnUFn9cj5VeMocskBw3UuXK3DUWO0jyP7Bs4a9AKL 3lp0PH95rL6cOZk4NNCNLypbkVk8SjW9BUVacG6LP3sPOz6KX6bzbDmFDtgfBWB+Qq 82QrDc14r8d+nA1Q7v4TE5qUfVrJjKL0rXW3SY4HeQ2+KPKSn3FzYtSFbriA0NBBHJ 1p/El1JxNXal3j+l/IcGspGYzrgmDCGOpXz9TLyVmUOsSL3WFaKtay2TLlYZswLoQq qUNLTU6Bg2Wzw== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/VzDeXXhc7I_fY0EuoWJWfiYT5Go Cc: draft-ietf-salud-alert-info-urns@tools.ietf.org, salud@ietf.org Subject: Re: [salud] AD review of draft-ietf-salud-alert-info-urns-12 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 00:46:04 -0000 > From: Richard Barnes > > > > It's not clear to me why you need all the date machinery in > > > provider IDs. This things are ephemeral -- why not just use the > > > org that has the domain now? > > Fair enough. Just wondering if we could simplify things, but it sounds > like not. Thanks! > From: Paul Kyzivat > There was quite a lot of thought and effort put into > the details of how the semantics are specified, and on the syntax, to > make it as convenient as possible to use. (E.g., what the defaults are.) More explicitly: If the date for a domain name is omitted, it defaults to 2013-01-01, and that date is usable by any organization which possessed its domain name on that date, or any organization which acquires a new domain name in the future which was never owned before. The intention is to allow all existing telecomm equipment vendors to be able to avoid using dates, and probably most vendors that will be created in the future (if they're careful about choosing a domain name). Also, if a vendor's ownership of its domain name extends across Jan 1 of any year (and we expect that will be universal), they can use the date 20xx-01-01, and that date can be abbreviated to just "xx". That shortens the date specifier to four characters, "(xx)", which we consider is a reasonable overhead to trade for adhering to strict time-invariance for URNs. Dale From nobody Mon Apr 14 18:04:14 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E689D1A0669 for ; Mon, 14 Apr 2014 18:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob4D6ET3ybJM for ; Mon, 14 Apr 2014 18:04:06 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6051A024C for ; Mon, 14 Apr 2014 18:04:05 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id q0Bo1n0031ap0As51142TR; Tue, 15 Apr 2014 01:04:02 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id q1411n00b1KKtkw3i142f0; Tue, 15 Apr 2014 01:04:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3F141Ts006748; Mon, 14 Apr 2014 21:04:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3F141cI006746; Mon, 14 Apr 2014 21:04:01 -0400 Date: Mon, 14 Apr 2014 21:04:01 -0400 Message-Id: <201404150104.s3F141cI006746@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Richard Barnes In-reply-to: (rlb@ipv.sx) References: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397523842; bh=Onr5fOqeu2kpH/EX0VaB5WGu0X4rqE41Sz6bIMKqN6s=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=mIqGSzqstzl4LmSw0dF8d+dcRMmORgTOBDoADjCd2/3DP+99orGl9yoGmHfo6V03M M2moCYx+jyK4wIONRYMbWfn5QmpwwgvutZfZvbKLjJA9LZbPlXI4qTo4vTCFsGO22T EKgh0kez/V3DMSaV9RfrTGqtOyesrW2LQlQE33l/KROdPN/K3iV3SS5IbRvZrP11An g6tGN6qmmG9PJ/KpwsE2xR34qLkcN5Bc5mOyY5yVU0mUbF+x05H/p1ec+7U834scKV DRIHge3mhqXCteDHqIc6UzJzuw9rkIxjHWcewoqko4Netfki5Sig5YuJKPem3npniQ 73Ct+mPpucv4g== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/IxCHiBQ6rSBx4kS0YV3y0dT9f38 Cc: draft-ietf-salud-alert-info-urns@tools.ietf.org, salud@ietf.org Subject: Re: [salud] AD review of draft-ietf-salud-alert-info-urns-12 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 15 Apr 2014 01:04:10 -0000 [as an author] > From: Richard Barnes > Some of the values in Section 8.2 have internal colons, which seems like > you're actually defining two things. But it's not meaningful to remove the > final label. Should these use a different separator? The idea is that a UA could define a rendering corresponding to service:recall, and it would cover all three of the defined recall categories. > In 8.2.6, do you want a language tag instead of a country? Oddly, you actually want a country code. The idea is that ring and ringback signals will tend to vary depending on the PTT administration, and those are more organized on national boundries than on languages. > It seems like the tables in 9.2.* could be collapsed into one. The tables could be combined, but each table has different explanatory material, and combining the tables would make it harder to connect the explanations with the entries. We do expect the IANA registration to use a single table (because the explanations will only be connected through the RFC reference). > Section 13 says that the UA MUST provide a "reasonable rendering". How do > I tell if a UA meets that criterion? Might be better to add in Section 11 > a requirement of the form, "if a UA cannot process the set of Alert URNs in > a message, then it MUST still provide some alert (chosen by local policy). > Failure to parse Alert URNs MUST NOT cause a UA not to alert at a all." Yes, the meaning of "reasonable rendering" is difficult to define. On the other hand, the behaviors of the UA that we want to forbid seem like they would be obvious when one observed it but difficult to specify. I'm not even sure that we want to go as far as requiring a noticable alerting signal was *always* produced -- what if there was a ? I think the requirement that the UA must produce an alert unless specifically requested not to falls under what we have written in section 13, but maybe it's worth specifying explicitly. And note that section 13 is broader than the rule you wrote, since it covers all combinations of URIs regardless of their scheme. Dale From nobody Thu Apr 17 13:58:03 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912661A00E5 for ; Thu, 17 Apr 2014 13:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5Mjd3ye-vD2 for ; Thu, 17 Apr 2014 13:58:00 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 362281A0054 for ; Thu, 17 Apr 2014 13:58:00 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta07.westchester.pa.mail.comcast.net with comcast id r8ej1n0020Fqzac578xw0n; Thu, 17 Apr 2014 20:57:56 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta08.westchester.pa.mail.comcast.net with comcast id r8xw1n0051KKtkw3U8xwVo; Thu, 17 Apr 2014 20:57:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3HKvtQ6012126 for ; Thu, 17 Apr 2014 16:57:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3HKvtvI012125; Thu, 17 Apr 2014 16:57:55 -0400 Date: Thu, 17 Apr 2014 16:57:55 -0400 Message-Id: <201404172057.s3HKvtvI012125@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: salud@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397768276; bh=MdBXgWLp2faVLwU+b1s27Rlt9Ge1ZxIOU0GdQSxdXH8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=e1Bhb9e+GsVBHyaGnhYHJbHOVCsl9XVyAk0cjmDlbB/p/vK4bKeKtZ8NNAsTaiYyk 9Mnrx2IvEGEGJNywA46dGrTx7lcSbS+39MTKmazUY/GxALdtc0f38ODNgEhVWc+b8K b0YXf4H3OJ0gitbir0E017RB20uOMVHK16zFR4oj3BUuI64RJEeZdVYs1WVN27/tkt zmWXV/E99at0PccyyF8NJgxUuS6LKb/VdlB+tHrkOqpAfmxCMhdgg6pN3FulCOG3L9 AQNzaDf/wL+91tCd9CT2plbxKdpTtaDovj2utY1rmwVoXL6CafGVVkiY5tvIgE+fbZ J+5SDhjm2/0dA== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/qtTWLFk0VVRmHtTtTPaNkhus6aw Subject: [salud] Reasonable rendering X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 17 Apr 2014 20:58:01 -0000 [as an individual] Richard Barnes (our new AD) says: > Section 13 says that the UA MUST provide a "reasonable rendering". How do > I tell if a UA meets that criterion? Might be better to add in Section 11 > a requirement of the form, "if a UA cannot process the set of Alert URNs in > a message, then it MUST still provide some alert (chosen by local policy). > Failure to parse Alert URNs MUST NOT cause a UA not to alert at a > all." I was thinking that it might be desirable to add some text to cover Richard's issue. On one hand, it seems that "reasonable rendering" should automatically include "the user can perceive it", but it might be useful to be explicit in regard to this particular feature of signals. One way to do this would be to extend the last paragraph of section 13, which reads The User Agent (UA) MUST produce a reasonable rendering regardless of the combination of URIs (of any schemes) in the Alert-Info header field. by adding In particular, under any circumstances a UA MUST provide some alert unless it is explicitly instructed not to (by Alert-Info URIs that it understands, local policy, or direction of the user). Dale From nobody Fri Apr 25 12:59:46 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123421A03CD for ; Fri, 25 Apr 2014 12:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.2 X-Spam-Level: ** X-Spam-Status: No, score=2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_84=0.6, MANGLED_BELOW=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gY3r1Oxbslt for ; Fri, 25 Apr 2014 12:59:42 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB831A05D1 for ; Fri, 25 Apr 2014 12:59:41 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id uCiA1n0051GhbT854Kzbdj; Fri, 25 Apr 2014 19:59:35 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta07.westchester.pa.mail.comcast.net with comcast id uKzZ1n00x1KKtkw3TKzamB; Fri, 25 Apr 2014 19:59:34 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3PJxXav027688; Fri, 25 Apr 2014 15:59:33 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3PJxXdj027687; Fri, 25 Apr 2014 15:59:33 -0400 Date: Fri, 25 Apr 2014 15:59:33 -0400 Message-Id: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: draft-ietf-salud-alert-info-urns@tools.ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398455975; bh=7p8xazRAYezfgjsJi2iEjr5ZGPbemuLt51rSBJ1/IeY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=AolG2LOMaq6+FQFIC1E2HQGEn5gBU91x7L0VQyIb2WnPdlMLydQhzoR0/XJe5OOIs +i13QSCkK1dB2ggcuGMUsdNh6PMFWLmg7Yniy7KT5FLnet3QjGhjqhLDbIKGR/QvzA 9QutQraDBno5A1K9duv0hHb710DfCKcGcMHlb8U9en3lddkUyxz40JnrSmCCQzLiXS mmlSYatAMq2zmXNt2lkckOJBUlbVqdxM0Y3OWLIGKLVemYpEmByLSQuk+5IuPPD5PQ cvDboAyEqLa59hFWLADd2O9W0E+J8pfTp6K3Ct9z5goNdyCDhWawsefRvewi63IVL7 CRZlH77MW+2KQ== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/asvPgB3O2Xh260sYpj0CbEVtjIM Cc: salud@ietf.org Subject: [salud] Reply to Pearl Liang (IANA) X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 19:59:44 -0000 [as an author] I have reformatted and somewhat revised my proposed response to IANA. The authors generally seem to agree with my response; I want to provide the final draft of the message to verify our agreement and solicit any improvements you have. If I don't hear otherwise, I will send this on Wednesday morning. Dale ---------------------------------------------------------------------- From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: drafts-lastcall@iana.org Subject: [IANA #755327] Last Call: (URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)) to Proposed Standard CC: salud-chairs@tools.ietf.org, draft-ietf-salud-alert-info-urns@tools.ietf.org --text follows this line-- > IANA understands that, upon approval of this document, there are two > actions which IANA must complete. This is correct. > First, in the Formal URN Namespaces subregistry of the Uniform > Resource Names (URN) Namespaces registry located at: > > http://www.iana.org/assignments/urn-namespaces/ > > a new URN will be registered as follows: > > URN Namespace: alert > Reference: [ RFC-to-be ] This is correct. > Second, a new registry called the Alert URN Identifiers registry is > to be created. This is correct. > New URNs in the Alert URN Identifiers Registry are created through > Standards Action as defined by RFC 5226. The process is more complex than that; the details are in section 9.1 of the RFC: The policy for adding a new standard is 'Standards Action'. The policy for adding s or patterns of s within a particular may differ for each and MUST be defined by the document defining the corresponding . That is: New "alert-categories" (items that do not contain a colon) are created by Standards Action. The policy for new "alert-identifiers" (items containing a colon) is set by the alert-category that it starts with. All existing alert-categories specify the policy Standards Action for adding alert-identifiers. The update policy for any alert-category will be stated in the RFC that defines it, so the "Reference" column implicitly specifies the update policy for that alert-category. Perhaps it would help to add a column "update policy" to this registry, which for each alert-category will contain the updating policy for alert-identifiers in that alert-category. (This column would be empty for alert-identifiers.) Or perhaps this registry should be divided into two registries, one for alert-categories (listing an update policy for the related alert-identifiers) and a second registry for the alert-identifiers (without an update policy column). What does IANA recommend for organizing this information? > QUESTIONs: > Should this new registry a sub-registry of the registry > 'Service URN Labels' located at > http://www.iana.org/assignments/urn-serviceid-labels? Or is this new > registry 'Alert URN Identifiers' a stand-alone with a brand new URL? > > Then, if the latter, what should be the name of the master "Parameter" > registry? Is Uniform Resource Names (URN)? See iana.org/protocols for > a list of main registry pages and the registries they include. The new registry will be a new registry named "Alert URN Identifiers" under the protocol name "Uniform Resource Names (URN)", and thus will be alongside "URN Service Labels", not a sub-registry of it. > IANA understands that the initial registrations in this new registry > are to be collected from section 9.2.1 through 9.2.6 of the current > document. IANA understands that the initial registry will look like > this: > > / Reference Description > > -------------------------------------------------------------------------- > service [ RFC-to-be ] Specific telephony > service used in this > call > service:normal [ RFC-to-be ] Normal ring/ringback > rendering (default value) > service:call-waiting [ RFC-to-be ] Call waiting was > initiated at the other side > of the call > service:forward [ RFC-to-be ] Call has been forwarded > service:recall:callback [ RFC-to-be ] Recall due to callback > service:recall:hold [ RFC-to-be ] Recall due to call hold > service:recall:transfer [ RFC-to-be ] Recall due to transfer > source [ RFC-to-be ] Classification > of the other party > to the call > source:unclassified [ RFC-to-be ] Unclassified ring/ringback > rendering (default value) > source:internal [ RFC-to-be ] User at the other side of > the call is internal to the > enterprise or PBX system > source:external [ RFC-to-be ] User at the other side of > the call is external to the > enterprise or PBX system > source:friend [ RFC-to-be ] User at the other side of > the call is a friend > source:family [ RFC-to-be ] User at the other side of > the call is a family member > priority [ RFC-to-be ] Priority of the > call > priority:normal [ RFC-to-be ] Normal ring/ringback > rendering (default value) > priority:low [ RFC-to-be ] Low priority call. > priority:high [ RFC-to-be ] High priority call > duration [ RFC-to-be ] Duration of alerting signal > alerting signal > duration:normal [ RFC-to-be ] Normal ring/ringback > rendering (default value) > duration:short [ RFC-to-be ] Shorter than normal > duration:long [ RFC-to-be ] Longer than normal > delay [ RFC-to-be ] Delay of rendering of alerting > of alerting signal > delay:none [ RFC-to-be ] Immediate alerting > (default value) > delay:yes [ RFC-to-be ] Delayed alerting > locale [ RFC-to-be ] Location-specific > alerting signals > locale:default [ RFC-to-be ] Alerting not location > specific > (default value) > locale:country: > [ RFC-to-be ] Alerting according to the > conventions of the specified > country > > IANA understands that these two actions are the only ones that need > to be completed upon approval of this document. The list of initial registrations in your e-mail is correct (allowing for the irregular use of line breaks in the original e-mail). That is, it is correct in regard to the data items to be recorded; the proposed registry may be organized differently if IANA recommends doing so (as discussed above). Dale, for the authors of ietf-salud-alert-info-urns ---------------------------------------------------------------------- [EOF] From nobody Fri Apr 25 13:09:44 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D0B1A0690 for ; Fri, 25 Apr 2014 13:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.865 X-Spam-Level: ** X-Spam-Status: No, score=2.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_84=0.6, MANGLED_BELOW=2.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3N8zkq0GWQ3 for ; Fri, 25 Apr 2014 13:09:28 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 6783E1A0680 for ; Fri, 25 Apr 2014 13:09:28 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id uJyj1n0021ei1Bg54L9MZc; Fri, 25 Apr 2014 20:09:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id uL9M1n0093ZTu2S3kL9Mdz; Fri, 25 Apr 2014 20:09:21 +0000 Message-ID: <535AC0F1.3050906@alum.mit.edu> Date: Fri, 25 Apr 2014 16:09:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: salud@ietf.org References: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com> In-Reply-To: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398456561; bh=IzfawhpPJNlpU8joujVPltU5RtxV+YzagMe2bzlf0GQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=u5vEzs98TCWKCMFiJWoOe08VviJtiCb0PiCczGYzLMzTXDKtwF0MJI7En6IKDa/iG 5bzNNCF6omU2DdTkuU8VglrZ1rGSwHocp0HcOT0Aw0Of9pY74mcRJDZOsw9xQtMsqn ILhs2sKyTSIkvu3tNQT07PpjL8DTIk3UcywMEtbjFYTfzx0Py3MuuFPvKBIsWMh2C+ 3nlgwmTuYcXhles+FlAkQvNPib2mDqhHasnzKuPzJCTOcHkxu3/huFF2H0bjNn8Rez BTqPXLiYWCE5x8NzAqVzS4YPvsCY3cBjZE8FmXdHpbcHe0YwgubDzLqRZP1Zb3q0UU ZJlHpWejMrp2A== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/lb_dKNcN60XnjhYftZjXahCSmbE Subject: Re: [salud] Reply to Pearl Liang (IANA) X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 20:09:32 -0000 Dale, My only comment is that it is probably better that we decide what we want the registry to look like than to let iana do it for us. Thanks, Paul On 4/25/14 3:59 PM, Dale R. Worley wrote: > [as an author] > > I have reformatted and somewhat revised my proposed response to IANA. > The authors generally seem to agree with my response; I want to > provide the final draft of the message to verify our agreement and > solicit any improvements you have. If I don't hear otherwise, I will > send this on Wednesday morning. > > Dale > ---------------------------------------------------------------------- > From: worley@ariadne.com (Dale R. Worley) > Sender: worley@ariadne.com (Dale R. Worley) > To: drafts-lastcall@iana.org > Subject: [IANA #755327] Last Call: (URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)) to Proposed Standard > CC: salud-chairs@tools.ietf.org, > draft-ietf-salud-alert-info-urns@tools.ietf.org > --text follows this line-- >> IANA understands that, upon approval of this document, there are two >> actions which IANA must complete. > > This is correct. > >> First, in the Formal URN Namespaces subregistry of the Uniform >> Resource Names (URN) Namespaces registry located at: >> >> http://www.iana.org/assignments/urn-namespaces/ >> >> a new URN will be registered as follows: >> >> URN Namespace: alert >> Reference: [ RFC-to-be ] > > This is correct. > >> Second, a new registry called the Alert URN Identifiers registry is >> to be created. > > This is correct. > >> New URNs in the Alert URN Identifiers Registry are created through >> Standards Action as defined by RFC 5226. > > The process is more complex than that; the details are in section 9.1 > of the RFC: > > The policy for adding a new standard is 'Standards > Action'. The policy for adding s or patterns of > s within a particular may differ > for each and MUST be defined by the document defining > the corresponding . > > That is: New "alert-categories" (items that do not contain a colon) > are created by Standards Action. The policy for new > "alert-identifiers" (items containing a colon) is set by the > alert-category that it starts with. All existing alert-categories > specify the policy Standards Action for adding alert-identifiers. The > update policy for any alert-category will be stated in the RFC that > defines it, so the "Reference" column implicitly specifies the update > policy for that alert-category. > > Perhaps it would help to add a column "update policy" to this > registry, which for each alert-category will contain the updating > policy for alert-identifiers in that alert-category. (This column > would be empty for alert-identifiers.) > > Or perhaps this registry should be divided into two registries, one > for alert-categories (listing an update policy for the related > alert-identifiers) and a second registry for the alert-identifiers > (without an update policy column). > > What does IANA recommend for organizing this information? > >> QUESTIONs: >> Should this new registry a sub-registry of the registry >> 'Service URN Labels' located at >> http://www.iana.org/assignments/urn-serviceid-labels? Or is this new >> registry 'Alert URN Identifiers' a stand-alone with a brand new URL? >> >> Then, if the latter, what should be the name of the master "Parameter" >> registry? Is Uniform Resource Names (URN)? See iana.org/protocols for >> a list of main registry pages and the registries they include. > > The new registry will be a new registry named "Alert URN Identifiers" > under the protocol name "Uniform Resource Names (URN)", and thus will > be alongside "URN Service Labels", not a sub-registry of it. > >> IANA understands that the initial registrations in this new registry >> are to be collected from section 9.2.1 through 9.2.6 of the current >> document. IANA understands that the initial registry will look like >> this: >> >> / Reference Description >> >> -------------------------------------------------------------------------- >> service [ RFC-to-be ] Specific telephony >> service used in this >> call >> service:normal [ RFC-to-be ] Normal ring/ringback >> rendering (default value) >> service:call-waiting [ RFC-to-be ] Call waiting was >> initiated at the other side >> of the call >> service:forward [ RFC-to-be ] Call has been forwarded >> service:recall:callback [ RFC-to-be ] Recall due to callback >> service:recall:hold [ RFC-to-be ] Recall due to call hold >> service:recall:transfer [ RFC-to-be ] Recall due to transfer >> source [ RFC-to-be ] Classification >> of the other party >> to the call >> source:unclassified [ RFC-to-be ] Unclassified ring/ringback >> rendering (default value) >> source:internal [ RFC-to-be ] User at the other side of >> the call is internal to the >> enterprise or PBX system >> source:external [ RFC-to-be ] User at the other side of >> the call is external to the >> enterprise or PBX system >> source:friend [ RFC-to-be ] User at the other side of >> the call is a friend >> source:family [ RFC-to-be ] User at the other side of >> the call is a family member >> priority [ RFC-to-be ] Priority of the >> call >> priority:normal [ RFC-to-be ] Normal ring/ringback >> rendering (default value) >> priority:low [ RFC-to-be ] Low priority call. >> priority:high [ RFC-to-be ] High priority call >> duration [ RFC-to-be ] Duration of alerting signal >> alerting signal >> duration:normal [ RFC-to-be ] Normal ring/ringback >> rendering (default value) >> duration:short [ RFC-to-be ] Shorter than normal >> duration:long [ RFC-to-be ] Longer than normal >> delay [ RFC-to-be ] Delay of rendering of alerting >> of alerting signal >> delay:none [ RFC-to-be ] Immediate alerting >> (default value) >> delay:yes [ RFC-to-be ] Delayed alerting >> locale [ RFC-to-be ] Location-specific >> alerting signals >> locale:default [ RFC-to-be ] Alerting not location >> specific >> (default value) >> locale:country: >> [ RFC-to-be ] Alerting according to the >> conventions of the specified >> country >> >> IANA understands that these two actions are the only ones that need >> to be completed upon approval of this document. > > The list of initial registrations in your e-mail is correct (allowing > for the irregular use of line breaks in the original e-mail). That > is, it is correct in regard to the data items to be recorded; the > proposed registry may be organized differently if IANA recommends > doing so (as discussed above). > > Dale, for the authors of ietf-salud-alert-info-urns > ---------------------------------------------------------------------- > [EOF] > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From nobody Fri Apr 25 14:31:53 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54CF1A0670 for ; Fri, 25 Apr 2014 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pURdCN6LzTv0 for ; Fri, 25 Apr 2014 14:31:51 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 082831A0345 for ; Fri, 25 Apr 2014 14:31:50 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id uKbA1n0021ZXKqc57MXku0; Fri, 25 Apr 2014 21:31:44 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id uMXj1n00x1KKtkw3hMXjN7; Fri, 25 Apr 2014 21:31:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3PLVhgS032604; Fri, 25 Apr 2014 17:31:43 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3PLVgQC032602; Fri, 25 Apr 2014 17:31:42 -0400 Date: Fri, 25 Apr 2014 17:31:42 -0400 Message-Id: <201404252131.s3PLVgQC032602@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: salud@ietf.org In-reply-to: <20140425070710.22327.70675.idtracker@ietfa.amsl.com> (iesg-secretary@ietf.org) References: <20140425070710.22327.70675.idtracker@ietfa.amsl.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398461504; bh=54o8qzj0Bh0dbSKwYTHN5kluQw2UYphwe73VMxj2vnY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=QRZIAYJetNmOIfXsZjYZ9pOWMIOaK0TtEObL3jDDLqaWg4s1LUOWCAlw0YPu3wAB8 F4YJJfuALt5DA2oytZg6izlr05JtEoP1bkwckCOTHgvNYKYm4TeNE0PKh1kI8KfzP3 X9bRY9pRE5UlLM9b0hQzgr8Rxo/qUSkaT+++VlA/Ik8QqJmeCcUu6u8K95qjtZRxCP o9PCZxYHOTttxswclOLDgpdaYlGwkKwEN3SZI71g1dunVXj7t4VZiT62+8ttSYtV+b L0o+rI4nRPCyPosu1CxIf5I6j8s4qOtMYDclGSz4qzXHEQxQniI0pGkuZToBdOfPoD 82jP9aBFNM9XQ== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/hx2PmMHF6uydiNlI4eK-Wl9KE44 Subject: [salud] End of IETF Last Call X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 21:31:53 -0000 [as chair] The IETF Last Call for the draft has ended. The next step is to ensure that all the Last Call comments are handled, and then Richard can provide a write-up that officially defines the standards action requested of the IESG. (https://datatracker.ietf.org/doc/help/state/draft-iesg/) Then the draft can be placed before the IESG for approval. There were no Last Call comments. However, Richard raised a number of issues for the authors to consider, and I think it is approporiate to handle them at this time. [as an author] Richard has raised a number of issues in his AD Review (http://www.ietf.org/mail-archive/web/salud/current/msg00496.html). I think that we have satisfied Richard that the issues require no change in the draft, with the possible exception of the following issue, for which I think it might be useful to add a sentence to section 13. Personally, I'm not sure that it's strictly necessary, but it might ensure that implmentations avoid a certain class of error that would be easy to make: http://www.ietf.org/mail-archive/web/salud/current/msg00503.html > > Section 13 says that the UA MUST provide a "reasonable rendering". How do > > I tell if a UA meets that criterion? Might be better to add in Section 11 > > a requirement of the form, "if a UA cannot process the set of Alert URNs in > > a message, then it MUST still provide some alert (chosen by local policy). > > Failure to parse Alert URNs MUST NOT cause a UA not to alert at a > > all." > > I was thinking that it might be desirable to add some text to cover > Richard's issue. On one hand, it seems that "reasonable rendering" > should automatically include "the user can perceive it", but it might > be useful to be explicit in regard to this particular feature of > signals. > > One way to do this would be to extend the last paragraph of section > 13, which reads > > The User Agent (UA) MUST produce a reasonable rendering regardless of > the combination of URIs (of any schemes) in the Alert-Info header > field. > > by adding > > In particular, under any circumstances a UA MUST provide some alert > unless it is explicitly instructed not to (by Alert-Info URIs that > it understands, local policy, or direction of the user). Dale From nobody Fri Apr 25 14:58:05 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889D81A06AD for ; Fri, 25 Apr 2014 14:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVMRyhVSGFsS for ; Fri, 25 Apr 2014 14:57:55 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 951411A050E for ; Fri, 25 Apr 2014 14:57:55 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta07.westchester.pa.mail.comcast.net with comcast id uMFE1n0040Fqzac57MxpTH; Fri, 25 Apr 2014 21:57:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id uMxo1n0103ZTu2S3UMxoZG; Fri, 25 Apr 2014 21:57:49 +0000 Message-ID: <535ADA5C.7010209@alum.mit.edu> Date: Fri, 25 Apr 2014 17:57:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: salud@ietf.org References: <20140425070710.22327.70675.idtracker@ietfa.amsl.com> <201404252131.s3PLVgQC032602@hobgoblin.ariadne.com> In-Reply-To: <201404252131.s3PLVgQC032602@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398463069; bh=cQ8fFg0kj9yne9Qd+KOMGRKsSt+Ji4luOTgv7/ecI7c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=g41lOxYYCqjCn45qlFfUQBCRTHx+G+3zftK3onoGFxGzvP4KuhH/ek8nCg9Ob+/Ux Gb819uHTieX8gHwcx9Y/rpyMsLdsdhN7IRqA2H2HFJ4MTTkAZtvtgeOADKEd8eJbUy NfYFyDt95kRqjJ4cghE1/kiyiEFx0kd6c5hFM18FNmBGUXxJ1tywovb4WF/p9RVXZb BjorzJpsDWvk6mkVp9vx0cNRNl2GuG9PGqz4AfONtjGvD1ledOmniX0aA/FK1AiNAo jbgl6nGCOFPo20oxKakiIfYgZAA1WVfUC4mwT02iXYxFNVle/zrfGM+izpjilaP5Hy eSrfqlVob0uxQ== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/JmS1Y2R-QBFjiLgHB-_6BK-daXA Subject: Re: [salud] End of IETF Last Call X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 21:57:56 -0000 On 4/25/14 5:31 PM, Dale R. Worley wrote: >> I was thinking that it might be desirable to add some text to cover >> Richard's issue. On one hand, it seems that "reasonable rendering" >> should automatically include "the user can perceive it", but it might >> be useful to be explicit in regard to this particular feature of >> signals. >> >> One way to do this would be to extend the last paragraph of section >> 13, which reads >> >> The User Agent (UA) MUST produce a reasonable rendering regardless of >> the combination of URIs (of any schemes) in the Alert-Info header >> field. >> >> by adding >> >> In particular, under any circumstances a UA MUST provide some alert >> unless it is explicitly instructed not to (by Alert-Info URIs that >> it understands, local policy, or direction of the user). While contemplating this I got thinking: What are expectations if you get an INVITE with both Alert-Info and Replaces? Normally one expects that INVITE/Replaces won't alert. I suppose that expectation is really local policy. And ISTM that it would be really unusual to put an Alert-Info with it. And how does that relate to Richard's question? Thanks, Paul From nobody Wed Apr 30 15:10:25 2014 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA411A6F13 for ; Wed, 30 Apr 2014 15:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRL_W2VW6qRd for ; Wed, 30 Apr 2014 15:10:02 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 826701A094C for ; Wed, 30 Apr 2014 15:10:02 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id wLvP1n0040QuhwU5BNA0Cf; Wed, 30 Apr 2014 22:10:00 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta02.westchester.pa.mail.comcast.net with comcast id wNA01n00L1KKtkw3NNA0K2; Wed, 30 Apr 2014 22:10:00 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3UM9xGF002458; Wed, 30 Apr 2014 18:09:59 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3UM9xPV002457; Wed, 30 Apr 2014 18:09:59 -0400 Date: Wed, 30 Apr 2014 18:09:59 -0400 Message-Id: <201404302209.s3UM9xPV002457@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: salud@ietf.org In-reply-to: <535AC0F1.3050906@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <201404251959.s3PJxXdj027687@hobgoblin.ariadne.com> <535AC0F1.3050906@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398895800; bh=okQ6VTqvEum/mbRmB2wFFrns+fHHtee2CJ8qPsqVF2w=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=m8XlJwil8v1jUL2wIHH/nDuKghsc0ZYD26w8ADCp0b16j/+Z0KWhTwdASnOk+Yzc/ uVoTItg7E5C2b5mOKGXF4vATsz+VCQvEMrCMmGtjCXhF/XjtdZWOM8nCYho8gtDkw5 EyeN5qu0TAhFx201uW0Jm4LZV5BILqHbondAb0KanlUszU9IV18Ddya0noxuxR0Avb Fp4avInx5k2WB5oUhGFG3Og5Zapr2qJKNlfSRG77CVXGnCT5wk63OdQjqJnogSQqem 7g+L+I3OxkOp1MICNtjg+T482TmmOr7TqLrkKEKUfNplbb0Fq8dHqt0pgj1I/FyneE GflqgoWuhGm8w== Archived-At: http://mailarchive.ietf.org/arch/msg/salud/HifefThw_SPacm8oG16bGpJXFy0 Subject: [salud] The registry structure (was: Reply to Pearl Liang (IANA)) X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.15 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, 30 Apr 2014 22:10:16 -0000 [as an author] > From: Paul Kyzivat > My only comment is that it is probably better that we decide what we > want the registry to look like than to let iana do it for us. I am looking at the following pages for examples: the "Uniform Resource Names (URN)" section of http://www.iana.org/protocols the "Service URN Labels" page, http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml the "Sieve Extensions" page, http://www.iana.org/assignments/sieve-extensions/sieve-extensions.xhtml (because it has complicated registration procedures). It seems to me that we want "Alert URN Identifiers" to be an item under "Uniform Resource Names (URN)", and we want it to point to a separate web page, as "Service URN Labels" does. How do we want to handle the registration procedures specification? IANA wants to know this and probably needs to know it. Most tables give the registration procedures in the header of the table. E.g., URN Service Labels Registration Procedure(s) Standards Action Reference [RFC5031] But the Sieve table has a separate table that gives registration procedures: Range Registration Procedures ----- ----------------------- vendor-controlled First Come First Served (name begins with "vnd.") IETF-controlled (no "vnd." prefix) Standards track or IESG-approved experimental RFC It would be simpler if there was one combined table, but it would be difficult to find a place to specify that alert-categories require standards action. Perhaps we should separate the alert-categories into a separate table: Alert URN Identifiers alert-categories Registration Procedure(s) Standards Action Reference [RFCxxxx] Name Description Reference Registration Procedure(s) for alert-identifiers ---- ----------- --------- ------------------------- service Specific telephony [RFCxxxx] Standards Action service used in this call source Classification of the [RFCxxxx] Standards Action other party to the call and then Alert URN Identifiers alert-identifiers Registration Procedure(s) As specified in the corresponding alert-category Reference [RFCxxxx] Name Description Reference ---- ----------- --------- service:normal Normal ring/ringback rendering (default value) [RFCxxxx] service:call-waiting [RFCxxxx] Call waiting was initiated at the other side of the call source:unclassified [RFCxxxx] Unclassified ring/ringback rendering (default value) source:internal User at the other side of the call is internal [RFCxxxx] to the enterprise or PBX system What do people think? Dale