From enum-bounces@ietf.org Tue Sep 04 11:35:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaPi-000714-44; Tue, 04 Sep 2007 11:34:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaPg-0006nH-CF for enum@ietf.org; Tue, 04 Sep 2007 11:34:00 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISaPf-0004iZ-2l for enum@ietf.org; Tue, 04 Sep 2007 11:34:00 -0400 Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.7348075; Tue, 04 Sep 2007 11:33:47 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 11:33:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Sep 2007 11:33:46 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-livingood-enum-videomsg-00 Thread-Index: AcfvCPwlFy/+VAccTZGyFQW2CJXx+g== From: "Livingood, Jason" To: "Richard Shockey" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , X-OriginalArrivalTime: 04 Sep 2007 15:33:46.0665 (UTC) FILETIME=[FBCD2190:01C7EF08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" Subject: [Enum] draft-livingood-enum-videomsg-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Given that the WG is winding down, and that the co-authors of this new = I-D wish to make substantive progress before IETF 70, we are requesting = approval of the WG chairs to make this an official WG draft. http://www.ietf.org/internet-drafts/draft-livingood-enum-videomsg-00.txt Regards Jason Livingood _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 04 11:35:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaPf-0006gC-Mn; Tue, 04 Sep 2007 11:33:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaPe-0006Uh-FW for enum@ietf.org; Tue, 04 Sep 2007 11:33:58 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISaPd-0004ic-9V for enum@ietf.org; Tue, 04 Sep 2007 11:33:58 -0400 Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.46265128; Tue, 04 Sep 2007 11:33:43 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 11:33:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Sep 2007 11:33:43 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-livingood-enum-voicemsg-00 Thread-Index: AcfvCPo6gAmTSkWYRLK37hYjXfyryA== From: "Livingood, Jason" To: "Richard Shockey" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , X-OriginalArrivalTime: 04 Sep 2007 15:33:43.0325 (UTC) FILETIME=[F9CF7CD0:01C7EF08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" Subject: [Enum] draft-livingood-enum-voicemsg-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Given that the WG is winding down, and that the co-authors of this new = I-D wish to make substantive progress before IETF 70, we are requesting = approval of the WG chairs to make this an official WG draft. http://www.ietf.org/internet-drafts/draft-livingood-enum-voicemsg-00.txt Regards Jason Livingood _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 04 13:57:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISccK-0006qb-SV; Tue, 04 Sep 2007 13:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISccJ-0006qV-Rs for enum@ietf.org; Tue, 04 Sep 2007 13:55:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISccI-0007oP-KN for enum@ietf.org; Tue, 04 Sep 2007 13:55:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Sep 2007 13:55:06 -0400 X-IronPort-AV: i="4.20,207,1186372800"; d="scan'208"; a="130891408:sNHT51739734" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l84Ht61n007169; Tue, 4 Sep 2007 13:55:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l84Hsf6M006808; Tue, 4 Sep 2007 17:54:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:54:49 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:54:48 -0400 Message-ID: <46DD9BE9.3000606@cisco.com> Date: Tue, 04 Sep 2007 13:54:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2007 17:54:48.0714 (UTC) FILETIME=[AF9356A0:01C7EF1C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1039; t=1188928506; x=1189792506; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-voicemsg-00 |Sender:=20 |To:=20=22Livingood,=20Jason=22=20; bh=JVY5FiyDjhyJYiVvBY7/Q38mztM6UUwieBkuz8N/w+0=; b=nROUlFur57V8hF7epjsfB/RVN3tWTBcfIAkHXFMM26f39twBcmHmQhJDw4JKqRJNetN2TWrO BhUHRnU/7dMvj87exlwkd3VlwbzCAgraMWfzpJ5C8WLXs1h84MBQz9FR; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: enum@ietf.org, Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , =?ISO-8859-1?Q?Patrik_F=E4lts?=, Hadriel Kaplan , Richard Shockey , =?ISO-8859-1?Q?tr=F6m?= , "Harvey, Chris" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org I have some difficulty with this proposal. The problem is that it uses enum to solve a problem that is not unique to phone-number addresses. The desire to reach a voicemail or other message taking service for a particular callee is applicable to sip as well as telephone numbered addresses. An enum solution solves half of the problem, and thus ensures that there will be divergent solutions. This problem was already addressed as part of callerprefs. (RFCs 3840 and 3841.) I don't see why that solution won't work here. Paul Livingood, Jason wrote: > Given that the WG is winding down, and that the co-authors of this new I-D wish to make substantive progress before IETF 70, we are requesting approval of the WG chairs to make this an official WG draft. > > http://www.ietf.org/internet-drafts/draft-livingood-enum-voicemsg-00.txt > > Regards > Jason Livingood > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 04 14:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISd1q-0001lP-8h; Tue, 04 Sep 2007 14:21:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISd1o-0001lI-Vh for enum@ietf.org; Tue, 04 Sep 2007 14:21:33 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISd1o-0008G4-H3 for enum@ietf.org; Tue, 04 Sep 2007 14:21:32 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l84ILCdU019800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Sep 2007 11:21:13 -0700 From: "Richard Shockey" To: "'Livingood, Jason'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> Date: Tue, 4 Sep 2007 14:20:44 -0400 Message-ID: <005a01c7ef20$522532f0$f66f98d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcfvCPo6gAmTSkWYRLK37hYjXfyryAAFnEvQ Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'Don Troshynski' , "'Zhou, Tong'" , "'Ferrise, Rich'" , 'Hadriel Kaplan' , "'Harvey, Chris'" Subject: [Enum] RE: draft-livingood-enum-voicemsg-00 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In theory, as co-chair, have no objections to this request.=20 If anyone has objections to making this a WG document post them now or forever hold your peace.=20 This is a straight forward document well within current charter and I = don=92t think it would be useful to delay this by applying the new registration procedure, which BTW needs to be worked on NOW well in advance of = Vancouver. Hint Bernie :-) !!=20 I do suggest that you beef up the issue of why RFC 4238 is not = appropriate for the application you choose.=20 This will come under some scrutiny from the VPIM/LEMONADE WG people. You might run it past them for comments etc. > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Tuesday, September 04, 2007 11:34 AM > To: Richard Shockey; Patrik F=E4ltstr=F6m; enum@ietf.org > Cc: Zhou, Tong; Ferrise, Rich; Harvey, Chris; Don Troshynski; Hadriel > Kaplan > Subject: draft-livingood-enum-voicemsg-00 > =20 > Given that the WG is winding down, and that the co-authors of this = new > I-D wish to make substantive progress before IETF 70, we are > requesting approval of the WG chairs to make this an official WG > draft. > =20 > http://www.ietf.org/internet-drafts/draft-livingood-enum-voicemsg- > 00.txt > =20 > Regards > Jason Livingood _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 04 14:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdYb-0008BY-UV; Tue, 04 Sep 2007 14:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdYa-0008BT-1I for enum@ietf.org; Tue, 04 Sep 2007 14:55:24 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdYY-0000Ny-S9 for enum@ietf.org; Tue, 04 Sep 2007 14:55:24 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20070904185522b1200dpch6e>; Tue, 4 Sep 2007 18:55:22 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l84ItL4p022107 for ; Tue, 4 Sep 2007 14:55:21 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l84ItL7p022103; Tue, 4 Sep 2007 14:55:21 -0400 Date: Tue, 4 Sep 2007 14:55:21 -0400 Message-Id: <200709041855.l84ItL7p022103@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> (Jason_Livingood@cable.comcast.com) Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: "Livingood, Jason" Given that the WG is winding down, and that the co-authors of this new I-D wish to make substantive progress before IETF 70, we are requesting approval of the WG chairs to make this an official WG draft. http://www.ietf.org/internet-drafts/draft-livingood-enum-videomsg-00.txt What's the difference between videomsg and voicemsg? Do we really need a separate ENUM resolution for both of them, or could we use media negotiation (like is done elsewhere in SIP)? Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 05 10:03:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISvRk-0004G5-KD; Wed, 05 Sep 2007 10:01:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISvRj-0004Fw-Dt for enum@ietf.org; Wed, 05 Sep 2007 10:01:31 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISvRi-0004MI-8A for enum@ietf.org; Wed, 05 Sep 2007 10:01:31 -0400 Received: from ([10.52.116.31]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.36531871; Wed, 05 Sep 2007 10:01:04 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 10:01:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-voicemsg-00 Date: Wed, 5 Sep 2007 10:01:03 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <46DD9BE9.3000606@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-voicemsg-00 Thread-Index: AcfvHMRnZkgJbBzESJyLgdtMM+uKQAAphmLg References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> From: "Livingood, Jason" To: "Paul Kyzivat" X-OriginalArrivalTime: 05 Sep 2007 14:01:03.0750 (UTC) FILETIME=[32756A60:01C7EFC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: enum@ietf.org, Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > The problem is that it uses enum to solve a problem that is=20 > not unique to phone-number addresses.=20 You can debate that if you like, but my use cases are for service = providers offering TN-based VoIP services. This is a problem that = exists today, at scale, in my and other networks. I am happy to discuss = future, non-TN-based services and am certainly aware of the fact that = SIP URIs handle this (which is a big benefit of SIP of course). But I = need to solve a very straight-forward, TN-based problem. I want to do a = DNS lookup in my ENUM servers and for a given TN be able to determine = where a voice mailbox is located so that I can then route that call = appropriately, inexpensively, and using open-standards-based methods. The approach to use ENUM is also very simple and easy to implement for = SPs who are now widely implementing ENUM in their VoIP service = architectures. In addition, there is not another ENUM service type that = meets the needs of this application. For all of these reasons, we = believe this merits a new ENUM service type. Furthermore, I believe in = the future when the WG is no longer active, the function of approval for = new types is that it is technically compliant with the general = guidelines for ENUM registrations. In the end, as with most ENUM = services or other RFCs, the true test is running code and then market = adoption and we're confident in both. > The desire to reach a=20 > voicemail or other message taking service for a particular=20 > callee is applicable to sip as well as telephone numbered=20 > addresses.=20 This is true. However, I do not know of many providers offering = non-TN-based voicemail. We are trying to solve a problem that SPs have = today. > An enum solution solves half of the problem, and=20 > thus ensures that there will be divergent solutions. What is the other half?? We need to be able to (1) determine that a = call is destined for voicemail (no issues, do it today), (2) figure out = where the voice mailbox is located (this I-D), and then (3) route the = call appropriately (no issues, do it today). Regards, Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 05 18:46:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT3bm-0004K6-BY; Wed, 05 Sep 2007 18:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT3bl-0004K0-7y for enum@ietf.org; Wed, 05 Sep 2007 18:44:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT3bj-00029U-U8 for enum@ietf.org; Wed, 05 Sep 2007 18:44:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Sep 2007 18:44:23 -0400 X-IronPort-AV: i="4.20,212,1186372800"; d="scan'208"; a="131074665:sNHT67586756" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l85MiNOp006483; Wed, 5 Sep 2007 18:44:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l85MiIZ6025390; Wed, 5 Sep 2007 22:44:19 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 18:44:18 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 18:44:18 -0400 Message-ID: <46DF3140.3050905@cisco.com> Date: Wed, 05 Sep 2007 18:44:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Sep 2007 22:44:18.0713 (UTC) FILETIME=[4B509890:01C7F00E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2939; t=1189032263; x=1189896263; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-voicemsg-00 |Sender:=20 |To:=20=22Livingood,=20Jason=22=20; bh=6M4uVkmqPvn8Mv5WpiuQMRH4R27g1CvZCG2dvVMFJ40=; b=fqPbZ7Y0sVy8fj5krEGiLTSu2szTzyly++NMKfKNXd9z2wFJ5zSnu3MvUTy7pBJdA6PRxmr8 U0wQrf9cnOtEbJCmPU/McARE1Uj9/B6WZ+uDRrbiDe5PZ+6rBbcmTha3; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: enum@ietf.org, Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: >> The problem is that it uses enum to solve a problem that is >> not unique to phone-number addresses. > > You can debate that if you like, but my use cases are for service providers offering TN-based VoIP services. This is a problem that exists today, at scale, in my and other networks. I am happy to discuss future, non-TN-based services and am certainly aware of the fact that SIP URIs handle this (which is a big benefit of SIP of course). But I need to solve a very straight-forward, TN-based problem. I want to do a DNS lookup in my ENUM servers and for a given TN be able to determine where a voice mailbox is located so that I can then route that call appropriately, inexpensively, and using open-standards-based methods. > > The approach to use ENUM is also very simple and easy to implement for SPs who are now widely implementing ENUM in their VoIP service architectures. In addition, there is not another ENUM service type that meets the needs of this application. For all of these reasons, we believe this merits a new ENUM service type. Furthermore, I believe in the future when the WG is no longer active, the function of approval for new types is that it is technically compliant with the general guidelines for ENUM registrations. In the end, as with most ENUM services or other RFCs, the true test is running code and then market adoption and we're confident in both. I have no desire to get into a pissing match. I will leave it to others to decide if the expediency of the situation justifies one solution for phone numbers and a different solution to the same problem when the target is a sip address. But I think it is relevant to recognize that this is setting up a path with divergent solutions. >> The desire to reach a >> voicemail or other message taking service for a particular >> callee is applicable to sip as well as telephone numbered >> addresses. > > This is true. However, I do not know of many providers offering non-TN-based voicemail. We are trying to solve a problem that SPs have today. Sadly, I expect it is true that not many providers offer this. But that will hopefully change. Certainly providers do offer recording of text messages. As MSRP is implemented that will entail accepting an INVITE session with a media stream - just not a voice media stream. For those systems that support both voice and text, it will be natural for the same server to accept either or both. >> An enum solution solves half of the problem, and >> thus ensures that there will be divergent solutions. > > What is the other half?? We need to be able to (1) determine that a call is destined for voicemail (no issues, do it today), (2) figure out where the voice mailbox is located (this I-D), and then (3) route the call appropriately (no issues, do it today). The other half is non-phone-number based calls. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 06 10:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITInj-0004rd-0S; Thu, 06 Sep 2007 10:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITInh-0004rO-C6 for enum@ietf.org; Thu, 06 Sep 2007 10:57:45 -0400 Received: from mail20.messagelabs.com ([216.82.245.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITIng-0001OG-6m for enum@ietf.org; Thu, 06 Sep 2007 10:57:45 -0400 X-VirusChecked: Checked X-Env-Sender: daryl@level3.net X-Msg-Ref: server-6.tower-20.messagelabs.com!1189090656!40792168!5 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 30083 invoked from network); 6 Sep 2007 14:57:40 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-6.tower-20.messagelabs.com with SMTP; 6 Sep 2007 14:57:40 -0000 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f10bb8-10 (Postfix) with ESMTP id DC1F24E42; Thu, 6 Sep 2007 14:57:39 +0000 (GMT) Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 From: Daryl Malas To: "Livingood, Jason" In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain Date: Thu, 06 Sep 2007 09:02:47 -0600 Message-Id: <1189090967.1297.228.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: enum@ietf.org, Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , Richard Shockey , Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= , "Harvey, Chris" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Just a thought on this one... Isn't a voice mail server ultimately just a UAS? Therefore, I would imagine a SP would simply provide a sip uri of voicemail@domain.com as a route and/or forward choice in the customer/subscribers routing profile? This is similar to how some traditional (many circuit switch) LEC's provide voice mail to their subscribers. They simply have a hunt group for an additional TN or TG (Trunk group). I don't see how this is different than capabilities that exist in the sip world today. Whether a subscriber dials the voice message platform directly or via a TN with ENUM resolution, a URI is a URI...it's ultimately just a UAS?! ...or, am I missing something here? Doesn't it really matter to have an additional value in ENUM called voicemsg? Just curious. Thanks...--Daryl On Tue, 2007-09-04 at 11:33 -0400, Livingood, Jason wrote: > Given that the WG is winding down, and that the co-authors of this new I-D wish to make substantive progress before IETF 70, we are requesting approval of the WG chairs to make this an official WG draft. > > http://www.ietf.org/internet-drafts/draft-livingood-enum-voicemsg-00.txt > > Regards > Jason Livingood > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 07 15:03:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITj5e-0005QC-IK; Fri, 07 Sep 2007 15:02:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITj5c-0005AK-E6 for enum@ietf.org; Fri, 07 Sep 2007 15:02:00 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITj5b-0005Xr-VX for enum@ietf.org; Fri, 07 Sep 2007 15:02:00 -0400 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.7508915; Fri, 07 Sep 2007 15:01:10 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 15:01:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-voicemsg-00 Date: Fri, 7 Sep 2007 15:01:09 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <46DF3140.3050905@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-voicemsg-00 Thread-Index: AcfwDmBShF8EA04qSjSrIoZ8Vw6L9ABcOzIQ References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> From: "Livingood, Jason" To: "Paul Kyzivat" X-OriginalArrivalTime: 07 Sep 2007 19:01:10.0730 (UTC) FILETIME=[744802A0:01C7F181] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: enum@ietf.org, Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > I have no desire to get into a pissing match. I will leave it=20 > to others to decide if the expediency of the situation=20 > justifies one solution for phone numbers and a different=20 > solution to the same problem when the target is a sip=20 > address. But I think it is relevant to recognize that this is=20 > setting up a path with divergent solutions. I can't be the one that registers all possible ENUM services though. ;-) =20 In all seriousness, my application will use a SIP URI that includes a TN in the user address. Now, theoretically, that could be paul@domain.com just as easily as 12155551212@domain.com. This registration would not preclude that - the registration is for a type with specific URIs, without regard to what is actually inside those URIs if you know what I mean. I added in the Tel URI as I figured it might be useful to someone else (though not me). > >> An enum solution solves half of the problem, and thus ensures that=20 > >> there will be divergent solutions. > >=20 > > What is the other half?? We need to be able to (1)=20 > determine that a call is destined for voicemail (no issues,=20 > do it today), (2) figure out where the voice mailbox is=20 > located (this I-D), and then (3) route the call appropriately=20 > (no issues, do it today). >=20 > The other half is non-phone-number based calls. And I do not believe this draft precludes those calls. I would be **more** than happy to add one or more examples to section 5 Examples that show non-TN-based SIP URIs here if you feel that would help. For example, perhaps: 5.4 Example of a calling party send to a voice messaging system, Using a 'sip' URI Scheme where the URI does not contain a telephone number =20 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa.=20 NAPTR 10 100 "u" "E2U+voicemsg:sip"=20 "!^.*$!sip:johndoe@gw.example.com!".=20 =20 In this example, a calling party has attempted a session which has=20 gone unanswered after a certain period of time. The calling party's=20 session is sent to the appropriate voice messaging server, a=20 personalized greeting is played to the calling party, after which=20 they record a voice message to the called party. The URI that this=20 session is directed to does not include a telephone number, as this=20 user has multiple service that are not particularly tied to telephone numbers whereby text, audio, video and other multimedia messages can be received and accessed. Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 07 17:58:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlov-0003x2-4T; Fri, 07 Sep 2007 17:56:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlot-0003wv-KB for enum@ietf.org; Fri, 07 Sep 2007 17:56:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITlos-0001YT-Rl for enum@ietf.org; Fri, 07 Sep 2007 17:56:55 -0400 X-IronPort-AV: E=Sophos;i="4.20,222,1186372800"; d="scan'208";a="70447498" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Sep 2007 17:56:55 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l87Lus9P032458; Fri, 7 Sep 2007 17:56:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l87LuoBg027902; Fri, 7 Sep 2007 21:56:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 17:56:50 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 17:56:49 -0400 Message-ID: <46E1C920.70009@cisco.com> Date: Fri, 07 Sep 2007 17:56:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2007 21:56:49.0787 (UTC) FILETIME=[FE0C7CB0:01C7F199] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6387; t=1189202214; x=1190066214; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-voicemsg-00 |Sender:=20 |To:=20=22Livingood,=20Jason=22=20; bh=q3Jip43sgJgJpmJl450KmYjFEh+CYMv9NhmEW7wCFHM=; b=hM6Q3qSoboKQlkln9tjjSzd8TMYJMILmRhngeonWde7L+zZDv8Q8TgxeGzM63nex1Fsuxl1W cLBlWtjf67HD/QMXx4BZ9cbttosbReOqFK5tiN4uXdVAdylnoDbj6zlP; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: enum@ietf.org, Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: >> I have no desire to get into a pissing match. I will leave it >> to others to decide if the expediency of the situation >> justifies one solution for phone numbers and a different >> solution to the same problem when the target is a sip >> address. But I think it is relevant to recognize that this is >> setting up a path with divergent solutions. > > I can't be the one that registers all possible ENUM services though. > ;-) > In all seriousness, my application will use a SIP URI that includes a TN > in the user address. Now, theoretically, that could be paul@domain.com > just as easily as 12155551212@domain.com. This registration would not > preclude that - the registration is for a type with specific URIs, > without regard to what is actually inside those URIs if you know what I > mean. I added in the Tel URI as I figured it might be useful to someone > else (though not me). I'm not sure I understand. I *think* you are saying that given an E.164 number +12155551212, you intend to use enum to map it to: sip:12155551212@domain.com (the primary destination) and sip:vm-addr@vmdomain.com (for VM) And you are saying that it would be fine with you if the mapping were instead: sip:paul@domain.com (the primary destination) and sip:vm-addr@vmdomain.com (for VM) Is that right? If so, it means that people that are calling my E.164 number will get the option of my primary address or my VM, but those who know my address as sip:paul@domain.com won't have the VM option. So the VM option is then only avaiable with E.164 numbers. >>>> An enum solution solves half of the problem, and thus ensures that >>>> there will be divergent solutions. >>> What is the other half?? We need to be able to (1) >> determine that a call is destined for voicemail (no issues, >> do it today), (2) figure out where the voice mailbox is >> located (this I-D), and then (3) route the call appropriately >> (no issues, do it today). >> >> The other half is non-phone-number based calls. > > And I do not believe this draft precludes those calls. I would be > **more** than happy to add one or more examples to section 5 Examples > that show non-TN-based SIP URIs here if you feel that would help. For > example, perhaps: > > 5.4 Example of a calling party send to a voice messaging system, Using a > > 'sip' URI Scheme where the URI does not contain a telephone number > > $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. > NAPTR 10 100 "u" "E2U+voicemsg:sip" > "!^.*$!sip:johndoe@gw.example.com!". > > In this example, a calling party has attempted a session which has > gone unanswered after a certain period of time. The calling party's > session is sent to the appropriate voice messaging server, a > personalized greeting is played to the calling party, after which > they record a voice message to the called party. The URI that this > session is directed to does not include a telephone number, as this > user has multiple service that are not particularly tied to telephone > numbers whereby text, audio, video and other multimedia messages can > be received and accessed. Thats fine, but its not the case I am concerned with. My concern is when the original target of the call was and it goes unanswered for awhile and is supposed to fail over to VM. People building systems where the AORs are not phone numbers *have* a way to do that. Either the VM is actually registered as a lower priority contact, or it is *configured* as a lower priority contact. If I have that already, and then I want to be reached via an E.164 number as well, it would make perfect sense to register an enum entry for sip that points to sip:paul@domain.com. But it *doesn't* make sense to put a separate entry in enum for my VM, because the VM will be handled *after* the translation is done and the call is routed to the translated address. Note: it makes a big difference whether we are talking about public enum, or private enum, or some other kind of enum. I can see how in some cases you might want to use a private enum as a sip location service for resolving E.164-based AORs *after* they reach your domain where you are acting on behalf of the recipient. At that point if you want to use this mechanism to keep track of different classes of contacts for the AOR, I have no problem. But its a different story with public enum, where it is presumed that the *caller* (or an agent working on behalf of the caller) is doing the resolving of the e.164 number. As I've been trying to explain, the problem is that this leads to partitioning the world into those who use e.164 numbers as their AORs and those who don't, with entirely different policies for how to reach VM in the two cases. For instance, a caller who wants to reach VM directly without ringing the callee's phone first, would use ENUM to select the VM if the target is a phone number. But if the target is a non-e.164-sip-address then the way currently defined for doing that is for the caller to use callerprefs. And if the target is an e.164 number and there is no VM entry in enum, callerprefs is again the best hope. Note that callerprefs has not been widely adopted. (Though it is specified in IMS.) This may partly be because it is complex, but also probably because nobody has a compelling need for the features it provides. If a *different* solution is adopted for E.164 numbers, which only works for E.164 numbers, then there will be features (such as "straight to VM") that only work for E.164 numbers. Then if the feature is recognized as important, the non-e.164 world will have to adopt an incompatible solution. And UAs that support both will need to implement both solutions. I recognize that callerprefs is an ugly thing that only a parent could love. (I am almost a parent, and I don't love it.) I wouldn't be upset at a *different* solution, so long as it works for any kind of called address. Callerprefs does have the advantage that it is already an rfc, and there are is even a use-case rfc that shows how to use it to selectively call for VM-only, or to make a call and exclude going to VM. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 07 18:59:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITmlH-0004lJ-Im; Fri, 07 Sep 2007 18:57:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITmlH-0004fM-10 for enum@ietf.org; Fri, 07 Sep 2007 18:57:15 -0400 Received: from mail.aus-biz.com ([65.23.153.184]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITmlG-0003B4-C2 for enum@ietf.org; Fri, 07 Sep 2007 18:57:14 -0400 Received: from [192.168.1.133] (unknown [202.10.81.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTP id 69EDD12328C; Fri, 7 Sep 2007 18:57:11 -0400 (EDT) Message-ID: <46E1D746.9020407@e164.org> Date: Sat, 08 Sep 2007 08:57:10 +1000 From: Duane User-Agent: Thunderbird 2.0.0.6 (X11/20070830) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: enum@ietf.org, Don Troshynski , Paul Kyzivat , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" , "Zhou, Tong" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: > In all seriousness, my application will use a SIP URI that includes a TN > in the user address. Now, theoretically, that could be paul@domain.com > just as easily as 12155551212@domain.com. This registration would not > preclude that - the registration is for a type with specific URIs, > without regard to what is actually inside those URIs if you know what I > mean. I added in the Tel URI as I figured it might be useful to someone > else (though not me). If you are going to this much trouble why not include a http type as well so people can access voicemail in a webmail type fashion -- Best regards, Duane _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 08 10:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU1Ts-00008l-OC; Sat, 08 Sep 2007 10:40:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU1Tr-00008f-Jb for enum@ietf.org; Sat, 08 Sep 2007 10:40:15 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU1Tr-0002bG-AU for enum@ietf.org; Sat, 08 Sep 2007 10:40:15 -0400 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.46430820; Sat, 08 Sep 2007 10:39:52 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Sep 2007 10:39:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-voicemsg-00 Date: Sat, 8 Sep 2007 10:39:51 -0400 Message-ID: <5179391446F07840B1BADBA758DE1B1E0BF760@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <46E1D746.9020407@e164.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-voicemsg-00 Thread-Index: Acfxontm0zZ8TU3EQsy8jcy5GO5fIQAg1nog References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> <46E1D746.9020407@e164.org> From: "Harvey, Chris" To: "Duane" X-OriginalArrivalTime: 08 Sep 2007 14:39:52.0231 (UTC) FILETIME=[1D94AB70:01C7F226] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: enum@ietf.org, Don Troshynski , Paul Kyzivat , "Ferrise, Rich" , Hadriel Kaplan , "Livingood, Jason" , "Zhou, Tong" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org =20 > If you are going to this much trouble why not include a http type as > well so people can access voicemail in a webmail type fashion We wouldn't preclude that idea from a future registration, but currently our plans for 'webmail type access' to voicemails are centered around a different UA experience along with most other MSO's. It's an interesting idea though worthy of future consideration outside of our current proposal. Chris Harvey _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 09 22:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYc5-0006fI-TP; Sun, 09 Sep 2007 22:02:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYc4-0006fD-6N for enum@ietf.org; Sun, 09 Sep 2007 22:02:56 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYc2-0005Fk-V0 for enum@ietf.org; Sun, 09 Sep 2007 22:02:56 -0400 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.7547900; Sun, 09 Sep 2007 22:02:31 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 22:02:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-voicemsg-00 Date: Sun, 9 Sep 2007 22:02:24 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BA63D@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <46E1C920.70009@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-voicemsg-00 Thread-Index: AcfxmgmO5s5naCkPQSumPeR0zVH6aABrv0yQ References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> <46E1C920.70009@cisco.com> From: "Livingood, Jason" To: "Paul Kyzivat" X-OriginalArrivalTime: 10 Sep 2007 02:02:31.0595 (UTC) FILETIME=[A5AD5FB0:01C7F34E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: enum@ietf.org, Don Troshynski , "Zhou, Tong" , "Ferrise, Rich" , Hadriel Kaplan , "Harvey, Chris" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > > In all seriousness, my application will use a SIP URI that=20 > includes a=20 > > TN in the user address. Now, theoretically, that could be=20 > > paul@domain.com just as easily as 12155551212@domain.com. This=20 > > registration would not preclude that - the registration is=20 > for a type=20 > > with specific URIs, without regard to what is actually inside those=20 > > URIs if you know what I mean. I added in the Tel URI as I=20 > figured it=20 > > might be useful to someone else (though not me). >=20 > I'm not sure I understand. I *think* you are saying that=20 > given an E.164 number +12155551212, you intend to use enum to=20 > map it to: > sip:12155551212@domain.com (the primary destination) > and sip:vm-addr@vmdomain.com (for VM) >=20 > And you are saying that it would be fine with you if the mapping were > instead: > sip:paul@domain.com (the primary destination) > and sip:vm-addr@vmdomain.com (for VM) > > Is that right? Yes, a destination voicemail service could be ANYTHINGHERE@vmdomain.com, where ANYTHING HERE was a TN, a text name, etc. So, call attempted to sip:12155551212@domain.com could go to sip:12155551212@vmdomain.com or it could go to sip:paul@vmdomain.com In terms of mapping sip:paul@domain.com to any particular voicemail location, that is outside the scope of this ENUMservice since it does not include a TN and ENUM requires a TN to perform a query. =20 That being said, however, I suppose if your SIP UAS or UAC had some internal mapping of paul@domain.com to 12155551212, then I suppose that could perform some ENUM query, but that is not really what is intended here.=20 =20 > If so, it means that people that are calling my E.164 number=20 > will get the option of my primary address or my VM, but those=20 > who know my address as sip:paul@domain.com won't have the VM=20 > option. So the VM option is then only avaiable with E.164 numbers. This is an ENUM service and so it therefore depends upon a TN to actually do something. This ENUM service in no way precludes a SIP UAS or UAC from in some way mapping sip:paul@domain.com to a sip-addressed voicemail box, nor does it even attempt to address this, as it does not involve a TN. > Thats fine, but its not the case I am concerned with. >=20 > My concern is when the original target of the call was=20 > and it goes unanswered for awhile and=20 > is supposed to fail over to VM. That is completely cool with me, but how is that relevant to an ENUMservice, which is by definition doing something based on a TN as input? I believe the case you cite, which in no way involves a TN, functions perfectly will by itself in SIP using existing RFCs today.=20 > People building systems where the AORs are not phone numbers=20 > *have* a way to do that.=20 I agree with you. This ENUM service is for people where the AORs *are* TNs.=20 > Note: it makes a big difference whether we are talking about=20 > public enum, or private enum, or some other kind of enum. I=20 > can see how in some cases you might want to use a private=20 > enum as a sip location service for resolving E.164-based AORs=20 > *after* they reach your domain where you are acting on behalf=20 > of the recipient. At that point if you want to use this=20 > mechanism to keep track of different classes of contacts for=20 > the AOR, I have no problem. The intended case here is private ENUM. =20 >From the draft here is text we included: =20 3. Distribution of Data=20 =20 The authors believe that it is more likely that these records will be distributed on a purely private basis, but they may also be=20 distributed in public ENUM trees. Distribution of this NAPTR data=20 could be either (a) on a private basis (within a service provider's=20 internal network, or on a private basis between one or more parties=20 using a variety of security mechanisms to prohibit general public=20 access) or (b) openly available.=20 =20 > But its a different story with public enum, where it is=20 > presumed that the *caller* (or an agent working on behalf of=20 > the caller) is doing the resolving of the e.164 number. As=20 > I've been trying to explain, the problem is that this leads=20 > to partitioning the world into those who use > e.164 numbers as their AORs and those who don't, with=20 > entirely different policies for how to reach VM in the two cases. I hear you, but doesn't that partitioning of TN-based communications and non-TN-based communications already exist in the marketplace? I am not sure this discussion can go anywhere other than into a philosophical debate over TNs vs. user names, besides which this is a WG that is all doing IP-based stuff with TNs as an input. =20 > For instance, a caller who wants to reach VM directly without=20 > ringing the callee's phone first, would use ENUM to select=20 > the VM if the target is a phone number. But if the target is=20 > a non-e.164-sip-address then the way currently defined for=20 > doing that is for the caller to use callerprefs. And if the=20 > target is an e.164 number and there is no VM entry in enum,=20 > callerprefs is again the best hope. Please explain how, when someone dials 1-215-555-1212, which is routed to my (Cisco BTS) Call Management Server, and no one answers, I can use callerprefs to determine which of, say 10 different voicemail pods to send the call to. > Note that callerprefs has not been widely adopted. (Though it=20 > is specified in IMS.)=20 And this is part of my problem. We need to deploy a workable solution rapidly, and happen to see that this ENUM service will immediately work to do so with minor modifications to SIP routing functions and ENUM server functions. > This may partly be because it is=20 > complex, but also probably because nobody has a compelling=20 > need for the features it provides.=20 I admit to not knowing much about your callerprefs drafts, but did read them quickly after you referred to them earlier. I am not sure they help me with our problem in the relatively short-term. However, we have what we believe is a compelling need for the features provided by this ENUMservice. > If a *different* solution=20 > is adopted for E.164 numbers, which only works for E.164=20 > numbers, then there will be features (such as "straight to=20 > VM") that only work for E.164 numbers.=20 In terms of voicemail, it seems to me that one could get to a SIP-based voicemail system using a non-E.164 number just fine, and someone with either a UAC or UAS can develop a feature to go straight to voicemail. > Then if the feature is=20 > recognized as important, the non-e.164 world will have to=20 > adopt an incompatible solution. And UAs that support both=20 > will need to implement both solutions. >=20 > I recognize that callerprefs is an ugly thing that only a=20 > parent could love. (I am almost a parent, and I don't love=20 > it.) I wouldn't be upset at a *different* solution, so long=20 > as it works for any kind of called address.=20 > Callerprefs does=20 > have the advantage that it is already an rfc, and there are=20 > is even a use-case rfc that shows how to use it to=20 > selectively call for VM-only, or to make a call and exclude=20 > going to VM. I absolutely 100% respect the hard work that I am sure went into those RFCs, they are extremely detailed and thorough. I am just not sure that they apply to our use cases, or at least they do not appear to be as rapidly and easily implemented. In this case, my preference is for what is cheapest, fastest, and simplist (just good enough to do the job). The advantage of ENUM services for this is that once a VoIP network supports SIP and ENUM, a new ENUM service represents nearly no additional work or investment. Regards Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sun Sep 09 22:10:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYhN-0004DU-6Z; Sun, 09 Sep 2007 22:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYhM-0004DP-0M for enum@ietf.org; Sun, 09 Sep 2007 22:08:24 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYhK-0005Mg-SA for enum@ietf.org; Sun, 09 Sep 2007 22:08:23 -0400 Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.46449565; Sun, 09 Sep 2007 22:08:10 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 22:08:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-voicemsg-00 Date: Sun, 9 Sep 2007 22:04:21 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602026BA63F@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <5179391446F07840B1BADBA758DE1B1E0BF760@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-voicemsg-00 Thread-Index: Acfxontm0zZ8TU3EQsy8jcy5GO5fIQAg1nogAEo2izA= References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> <46E1D746.9020407@e164.org> <5179391446F07840B1BADBA758DE1B1E0BF760@PACDCEXCMB04.cable.comcast.com> From: "Livingood, Jason" To: "Harvey, Chris" , "Duane" X-OriginalArrivalTime: 10 Sep 2007 02:08:10.0842 (UTC) FILETIME=[6FE25BA0:01C7F34F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: enum@ietf.org, Don Troshynski , Paul Kyzivat , "Ferrise, Rich" , Hadriel Kaplan , "Zhou, Tong" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Excellent idea. We can pull some similar text from RFC 4002. This would merely be another sub-type to the overall "voicemsg" type. We will be able to quickly update this for the next I-D revision. Regards Jason=20 > -----Original Message----- > From: Harvey, Chris=20 > Sent: Saturday, September 08, 2007 10:40 AM > To: 'Duane' > Cc: Paul Kyzivat; enum@ietf.org; Don Troshynski; Zhou, Tong;=20 > Ferrise, Rich; Hadriel Kaplan; Livingood, Jason > Subject: RE: [Enum] draft-livingood-enum-voicemsg-00 >=20 > =20 > > If you are going to this much trouble why not include a=20 > http type as=20 > > well so people can access voicemail in a webmail type fashion >=20 > We wouldn't preclude that idea from a future registration,=20 > but currently our plans for 'webmail type access' to=20 > voicemails are centered around a different UA experience=20 > along with most other MSO's. >=20 > It's an interesting idea though worthy of future=20 > consideration outside of our current proposal. >=20 > Chris Harvey >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 10 15:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpMm-0001Pf-27; Mon, 10 Sep 2007 15:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpMk-0001P4-Fb for enum@ietf.org; Mon, 10 Sep 2007 15:56:14 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUpMi-00022U-Ba for enum@ietf.org; Mon, 10 Sep 2007 15:56:14 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070910195611b1100ok0e3e>; Mon, 10 Sep 2007 19:56:11 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l8AJuA4p009947 for ; Mon, 10 Sep 2007 15:56:10 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l8AJuABp009943; Mon, 10 Sep 2007 15:56:10 -0400 Date: Mon, 10 Sep 2007 15:56:10 -0400 Message-Id: <200709101956.l8AJuABp009943@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1189090967.1297.228.camel@montag.eng.level3.com> (daryl@level3.net) Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <1189090967.1297.228.camel@montag.eng.level3.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: Daryl Malas Isn't a voice mail server ultimately just a UAS? Therefore, I would imagine a SP would simply provide a sip uri of voicemail@domain.com as a route and/or forward choice in the customer/subscribers routing profile? Or in SIP terms, an additional contact for the AOR that has a low q value. This is similar to how some traditional (many circuit switch) LEC's provide voice mail to their subscribers. They simply have a hunt group for an additional TN or TG (Trunk group). I don't see how this is different than capabilities that exist in the sip world today. Whether a subscriber dials the voice message platform directly or via a TN with ENUM resolution, a URI is a URI...it's ultimately just a UAS?! ...or, am I missing something here? Doesn't it really matter to have an additional value in ENUM called voicemsg? The sipX system uses this technique. And I expect that just about every natively SIP system does also. E.g., a contact lookup for sip:5718@example.com gets you the URI of a registered phone and the URI for the media server, with URI parameters instructing it to deposit voicemail in the correct mailbox: INVITE sip:9207275718@example.com SIP/2.0 From: ;tag=cp41w9vzg7 To: Call-Id: 3c26701104e2-goolwjfexwgr Cseq: 26 INVITE Contact: ;flow-id=1 SIP/2.0 302 Moved Temporarily Contact: Contact: ;q=0.1 From: ;tag=cp41w9vzg7 To: ;tag=ddpkbnbien Call-Id: 3c26701104e2-goolwjfexwgr Cseq: 26 INVITE Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 10 16:40:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUq1z-0005tt-MN; Mon, 10 Sep 2007 16:38:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUq1x-0005sL-Lh for enum@ietf.org; Mon, 10 Sep 2007 16:38:49 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUq1x-0004gN-30 for enum@ietf.org; Mon, 10 Sep 2007 16:38:49 -0400 X-IronPort-AV: E=Sophos;i="4.20,233,1186372800"; d="scan'208";a="70669898" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2007 16:38:49 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8AKcmte013000; Mon, 10 Sep 2007 16:38:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8AKcQEM026288; Mon, 10 Sep 2007 20:38:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 16:38:41 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 16:38:41 -0400 Message-ID: <46E5AB51.4050703@cisco.com> Date: Mon, 10 Sep 2007 16:38:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <1189090967.1297.228.camel@montag.eng.level3.com> <200709101956.l8AJuABp009943@dragon.ariadne.com> In-Reply-To: <200709101956.l8AJuABp009943@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2007 20:38:41.0465 (UTC) FILETIME=[92D49290:01C7F3EA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4137; t=1189456728; x=1190320728; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-voicemsg-00 |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=D8mMpEIGSumlQsTq3xHrRklFIEI9iIhgvcwCICeXQ+M=; b=gsDd6YTfhvP4MBwRKC1uDmAduZBsKk9JoZRwXSPSW4GmTdXyIq8bIxw2NIXQLsNfmBUgCv1G u3hRJeIDMmkh7QARU9kMwbq0Osi5X1F6gbqQaZhn7zzYolwXtsbqM11D; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Daryl Malas > > Isn't a voice mail server ultimately just a UAS? Therefore, I would > imagine a SP would simply provide a sip uri of voicemail@domain.com as a > route and/or forward choice in the customer/subscribers routing profile? > > Or in SIP terms, an additional contact for the AOR that has a low q > value. > > This is similar to how some traditional (many circuit switch) LEC's > provide voice mail to their subscribers. They simply have a hunt group > for an additional TN or TG (Trunk group). I don't see how this is > different than capabilities that exist in the sip world today. Whether > a subscriber dials the voice message platform directly or via a TN with > ENUM resolution, a URI is a URI...it's ultimately just a UAS?! ...or, > am I missing something here? Doesn't it really matter to have an > additional value in ENUM called voicemsg? > > The sipX system uses this technique. And I expect that just about > every natively SIP system does also. I thought this until I saw how IMS works. (I guess its arguable whether it is a "natively SIP system".) It seems that the natural way to handle VM for it is: A proxy aware of the VM policy of the user (call it the "vm-proxy") is in the signaling path for every call, before the "home-proxy" that does translation of AOR based on the location service. Initially the vm-proxy establishes a timer, and then allows the call to proceed to the home-proxy and be translated based on the location service, including forking, etc. If the call is answered before the timer expires, vm-proxy simply cancels its timer. (No VM involvement.) If a busy response is returned before the timer expires (all downstream forking by home-proxy and beyond exhausted and busy is the *best* response) then the vm-proxy acts as a forking proxy and sends the call to VM. If the timer expires without a final response having been seen, then the vm-proxy acts as a forking proxy - canceling the transaction to the home-proxy and then forking the call to the VM system. This is roughly comparable to configuring a lowest priority entry for the VM system in the location service of every applicable user. But there are some significant differences: THe VM-on-no-answer is timer based, and uncoordinated with how many of the registered candidates have been tried. It could be a problem if there are a number of candidates and sequential forking is being done. OTOH, it may be more consistent with the user experience people expect. Another problem is that it interacts poorly with callerprefs. With callerprefs the candidates are collected and ranked. But here the pool of candidates is split into two. At best callerprefs will be applied to each half separately. At worst they won't be applied to the VM system at all. So for instance callerprefs that *prefer* VM over a live user may not work well (or at all). Paul > E.g., a contact lookup for > sip:5718@example.com gets you the URI of a registered phone and the > URI for the media server, with URI parameters instructing it to > deposit voicemail in the correct mailbox: > > INVITE sip:9207275718@example.com SIP/2.0 > From: ;tag=cp41w9vzg7 > To: > Call-Id: 3c26701104e2-goolwjfexwgr > Cseq: 26 INVITE > Contact: ;flow-id=1 > > > SIP/2.0 302 Moved Temporarily > Contact: > Contact: > ;q=0.1 > From: ;tag=cp41w9vzg7 > To: ;tag=ddpkbnbien > Call-Id: 3c26701104e2-goolwjfexwgr > Cseq: 26 INVITE > > Dale > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 11 15:27:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBMw-0007KQ-Il; Tue, 11 Sep 2007 15:25:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBMw-0007KJ-2L for enum@ietf.org; Tue, 11 Sep 2007 15:25:54 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVBMv-0007FL-PI for enum@ietf.org; Tue, 11 Sep 2007 15:25:53 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <200709111925530120043j4ue>; Tue, 11 Sep 2007 19:25:53 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l8BJPq4p025903 for ; Tue, 11 Sep 2007 15:25:52 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l8BJPqv2025899; Tue, 11 Sep 2007 15:25:52 -0400 Date: Tue, 11 Sep 2007 15:25:52 -0400 Message-Id: <200709111925.l8BJPqv2025899@dragon.ariadne.com> To: enum@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46E5AB51.4050703@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <1189090967.1297.228.camel@montag.eng.level3.com> <200709101956.l8AJuABp009943@dragon.ariadne.com> <46E5AB51.4050703@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: Paul Kyzivat I thought this until I saw how IMS works. (I guess its arguable whether it is a "natively SIP system".) Yeah, I've wondered that myself. A proxy aware of the VM policy of the user (call it the "vm-proxy") is in the signaling path for every call, before the "home-proxy" that does translation of AOR based on the location service. Initially the vm-proxy establishes a timer, and then allows the call to proceed to the home-proxy and be translated based on the location service, including forking, etc. This is pretty much a forking proxy that sets an expiration time on the first (phone) leg, and if that leg fails or times out, sends the call to a second (voicemail) leg. Another problem is that it interacts poorly with callerprefs. With callerprefs the candidates are collected and ranked. But here the pool of candidates is split into two. At best callerprefs will be applied to each half separately. At worst they won't be applied to the VM system at all. So for instance callerprefs that *prefer* VM over a live user may not work well (or at all). Early automobiles were steered with reins, because that was how you had steered horses. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 12 11:12:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVTrY-0006nI-HF; Wed, 12 Sep 2007 11:10:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVIHh-0000Tn-8I for enum@ietf.org; Tue, 11 Sep 2007 22:48:57 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVIHf-0007ri-QG for enum@ietf.org; Tue, 11 Sep 2007 22:48:57 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l8C2mep05068; Tue, 11 Sep 2007 19:48:40 -0700 In-Reply-To: <46CD9ADC.9000006@enum.at> References: <46CD9ADC.9000006@enum.at> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Tue, 11 Sep 2007 19:48:40 -0700 To: Alexander Mayrhofer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-Mailman-Approved-At: Wed, 12 Sep 2007 11:10:42 -0400 Cc: enum@ietf.org, Rohan Mahy Subject: [Enum] Re: Last Call: draft-ietf-enum-calendar-service (A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services) to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Alex, I think this change will make the document better, so I would like to include it. I want to point out another area of potential confusion so we can have it out in the open sooner rather than later. There are really three distinct operations that you can do with calendaring: manipulating one of your calendars, viewing someone else's free/busy status, and scheduling (proposing an event). Whether we should have subtype for protocol, or a subtype for the "operation" you are trying to perform. thanks, -rohan On Aug 23, 2007, at 7:34 AM, Alexander Mayrhofer wrote: > The IESG wrote: >> The IESG has received a request from the Telephone Number Mapping WG >> (enum) to consider the following document: >> >> - 'A Telephone Number Mapping (ENUM) Service Registration for >> Internet >> Calendaring Services ' >> as a Proposed Standard > > Hi, > > (yes, i know that it's _very very_ late for this, and i hate to > receive > similar comments on my documents... but - better late than never?) > > Two things (i start with the non-issue..) > > - I seem to have overlooked that the shortcut title of the document > still > says "IM Enumservice", even though this is the calendar > Enumservice, seems > to be a leftover from copying the other template. > > Now the harder issue: Subtypes. > > - In the light of the discussions around Enumservice classification in > Chicago, i examined the type/subtype combinations, and i feel a bit > unease > about not using any subtypes for this Enumservice, because this > Enumservice > covers two completely different calendaring protocols (iMIP and > CalDAV). I > consider being "ical" and "application class" Enumservice, > according what we > added to the enumservices guide in the recent revision. > > A bit more about the subtyping decision: > > Keep in mind that a client is not allowed to "look" at the URI > scheme for > choosing a ENUM records, so it can only guess whether the record > would be > for an iMIP or an CalDAV address when there is no subtype given. > Only the > type and subtype must be used to choose a NAPTR from a set of > records - so a > client would not be able to find out whether a NAPTR refers to a > "iMIP" or > "CalDAV" resource.. > > That might well lead to problems when a client finds out that the > "ical" > record it has just chosen lists a iMIP address, while the client only > supports CalDAV. According to RFC3761, it can't "go back" anymore, > and try > the other "ical" record, even if that would have contained a CalDAV > URI. So > the client would fail to contact the calendaring resource, even > though it > _would_ have been able to contact it in case it had chosen the > other record > ("russian ENUM roulette", anybody?) > > - A second concern might be that there _could_ be calendaring > protocols that > use http/https URIs as well, but don't represent CalDAV resources (who > knows?). A client would have no chance in finding out which "http- > using" > calendaring protocol the NAPTR addresses without contacting the actual > calendar service. > > I'd suggest to change (yes, i know, 5 mins after 12) that Enumservice > registration to two distinct registrations, both with a subtype, like: > > a) Name: "iCal" > Type: "ical" > Subtype: "caldav" > URI schemes: "http", "https" > > b) Name: "iCal" > Type: "ical" > Subtype: "imip" > URI schemes: "mailto" > > That would clarify to the client which calendaring protocol is in > use, would > allow other potential calendaring protocols to use http/https as > well, and > generally give me a better feeling about that Enumservice than the > current > document does... > > Comments? > > (and, again, sorry for being late!) > > --- > Alex Mayrhofer > enum.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 11:55:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVr1v-0005Zm-Sf; Thu, 13 Sep 2007 11:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVr1t-0005XB-Qk for enum@ietf.org; Thu, 13 Sep 2007 11:54:57 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVr1s-0008Nj-9U for enum@ietf.org; Thu, 13 Sep 2007 11:54:57 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8DFsYN0008413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 13 Sep 2007 08:54:35 -0700 From: "Richard Shockey" To: Date: Thu, 13 Sep 2007 11:54:48 -0400 Message-ID: <055701c7f61e$6a898e40$3f9caac0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acf2GNb+jCN6VfN6Q9a9A80Eyw+pegABYthw Content-language: en-us X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Enum] FW: I-D ACTION:draft-livingood-enum-voicemsg-01.txt X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 16:17:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVv7h-0001q7-0F; Thu, 13 Sep 2007 16:17:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVv7f-0001l3-Ov for enum@ietf.org; Thu, 13 Sep 2007 16:17:11 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVv7e-00062v-I9 for enum@ietf.org; Thu, 13 Sep 2007 16:17:11 -0400 Received: from ([10.52.116.30]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.11485180; Thu, 13 Sep 2007 16:16:57 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 16:16:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Thu, 13 Sep 2007 16:16:56 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <200709041855.l84ItL7p022103@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: AcfvJUFYONjrLD0FSjC5Eujfw2K72gG99bTw References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com> From: "Livingood, Jason" To: , X-OriginalArrivalTime: 13 Sep 2007 20:16:56.0732 (UTC) FILETIME=[08635DC0:01C7F643] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org This is a great question, and one the authors stuggled with mightily. I believe you could make such an arguement, essentially since SIP can obviously negotiate endpoint capabilities and determine if it is a video or voice session. (call it mmsg for media message if you like) However, one of the concerns we surfaced is that it is possible that the server infrastructure in SP networks supporting these messaging services is separate, which may make it useful to be able to determine if it should go to a video or voice messaging server, rather than use some intervening network element to further proxy the communication and determine where to direct the session.=20 But good point. Any other thoughts on this?? Jason > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Tuesday, September 04, 2007 2:55 PM > To: enum@ietf.org > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >=20 > From: "Livingood, Jason" >=20 > Given that the WG is winding down, and that the co-authors of this > new I-D wish to make substantive progress before IETF 70, we are > requesting approval of the WG chairs to make this an official WG > draft. >=20 > =20 > http://www.ietf.org/internet-drafts/draft-livingood-enum-video > msg-00.txt >=20 > What's the difference between videomsg and voicemsg? Do we=20 > really need a separate ENUM resolution for both of them, or=20 > could we use media negotiation (like is done elsewhere in SIP)? >=20 > Dale >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 16:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvcd-0001Yk-Ri; Thu, 13 Sep 2007 16:49:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvcc-0001Yb-JF for enum@ietf.org; Thu, 13 Sep 2007 16:49:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVvcc-0003rs-1d for enum@ietf.org; Thu, 13 Sep 2007 16:49:10 -0400 X-IronPort-AV: E=Sophos;i="4.20,251,1186383600"; d="scan'208";a="523734052" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2007 13:49:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8DKn7cD016035; Thu, 13 Sep 2007 13:49:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DKn6F0007007; Thu, 13 Sep 2007 20:49:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 16:49:00 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 16:49:00 -0400 Message-ID: <46E9A23B.9060908@cisco.com> Date: Thu, 13 Sep 2007 16:48:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Livingood, Jason" Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com> <45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2007 20:49:00.0445 (UTC) FILETIME=[8302ACD0:01C7F647] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2339; t=1189716547; x=1190580547; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20; bh=dO94yUNMyZWWARSzTiGregf7TXRXloGSoVlvvGoHHNc=; b=m+AfH0m5WvHJvz2X++KzuxEIathJ2h75yqjAuageMopojuFF9rL/3Z3z5Wb6yQKjx70l3j04 HuEGo/dHalFUbIr0YbOu2HNZw2QXQ0RVDhlC0yJzrZGGoVCmHJIu+cRs; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: enum@ietf.org, Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Livingood, Jason wrote: > This is a great question, and one the authors stuggled with mightily. I > believe you could make such an arguement, essentially since SIP can > obviously negotiate endpoint capabilities and determine if it is a video > or voice session. (call it mmsg for media message if you like) > > However, one of the concerns we surfaced is that it is possible that the > server infrastructure in SP networks supporting these messaging services > is separate, which may make it useful to be able to determine if it > should go to a video or voice messaging server, rather than use some > intervening network element to further proxy the communication and > determine where to direct the session. > > But good point. Any other thoughts on this?? Who is making the decision about which type to choose from enum? If its not the UAC then how does it know which it wants? And does your answer differ if the INVITE doesn't contain an offer? While you're at it, don't forget there is other media than voice and video. At least there is MSRP and real time text. The advocates for real time text will be on you if you don't support that. Paul > Jason > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: Tuesday, September 04, 2007 2:55 PM >> To: enum@ietf.org >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >> >> From: "Livingood, Jason" >> >> Given that the WG is winding down, and that the co-authors of this >> new I-D wish to make substantive progress before IETF 70, we are >> requesting approval of the WG chairs to make this an official WG >> draft. >> >> >> http://www.ietf.org/internet-drafts/draft-livingood-enum-video >> msg-00.txt >> >> What's the difference between videomsg and voicemsg? Do we >> really need a separate ENUM resolution for both of them, or >> could we use media negotiation (like is done elsewhere in SIP)? >> >> Dale >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum >> > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 16:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvii-00080b-RP; Thu, 13 Sep 2007 16:55:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvig-00080C-TG for enum@ietf.org; Thu, 13 Sep 2007 16:55:26 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVvif-0007MK-Eq for enum@ietf.org; Thu, 13 Sep 2007 16:55:26 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8DKsuVa030979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Sep 2007 13:54:57 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Livingood, Jason'" References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> <46E1C920.70009@cisco.com> In-Reply-To: <46E1C920.70009@cisco.com> Subject: RE: [Enum] draft-livingood-enum-voicemsg-00 Date: Thu, 13 Sep 2007 16:55:09 -0400 Message-ID: <06e301c7f648$62ba4040$282ec0c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcfxmfqZ+cdLpUvzQzyCxPeXtgvB9QAmCoBA Content-language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: enum@ietf.org, 'Don Troshynski' , "'Zhou, Tong'" , "'Ferrise, Rich'" , 'Hadriel Kaplan' , paf@cisco.com, "'Harvey, Chris'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org In line ..PLEASE READ CAREFULLY. > > Livingood, Jason wrote: > >> I have no desire to get into a pissing match. I will leave it > >> to others to decide if the expediency of the situation > >> justifies one solution for phone numbers and a different > >> solution to the same problem when the target is a sip > >> address. But I think it is relevant to recognize that this is > >> setting up a path with divergent solutions. This is an important thread since it highlights some of the critical issues in the registration draft that we need to continue to make progress on. Hint Hint .. http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-04.tx t The issue is what are the criterion by which a particular scheme can be registered or not. This is an issue we have not completely resolved in the registration document and it is a critical requirement. I tend to support the position that if someone has a workable idea that meets a reasonable test of "usefulness" and there are no glaring conflicts with other schemes the registration should proceed. > > Note: it makes a big difference whether we are talking about public > enum, or private enum, or some other kind of enum. I can see how in > some cases you might want to use a private enum as a sip location service > for resolving E.164-based AORs *after* they reach your domain where you > are acting on behalf of the recipient. At that point if you want to use > this mechanism to keep track of different classes of contacts for the AOR, > I have no problem. > > But its a different story with public enum, where it is presumed that > the *caller* (or an agent working on behalf of the caller) is doing > the resolving of the e.164 number. As I've been trying to explain, the > problem is that this leads to partitioning the world into those who > use e.164 numbers as their AORs and those who don't, with entirely > different policies for how to reach VM in the two cases. > > For instance, a caller who wants to reach VM directly without ringing > the callee's phone first, would use ENUM to select the VM if the > target is a phone number. But if the target is a non-e.164-sip-address then > the way currently defined for doing that is for the caller to use > callerprefs. And if the target is an e.164 number and there is no VM > entry in enum, callerprefs is again the best hope. > > Note that callerprefs has not been widely adopted. (Though it is > specified in IMS.) This may partly be because it is complex, but also > probably because nobody has a compelling need for the features it > provides. That is a understatement if I have ever heard one. :-) If a *different* solution is adopted for E.164 numbers, > which only works for E.164 numbers, then there will be features (such as > "straight to VM") that only work for E.164 numbers. Then if the > feature is recognized as important, the non-e.164 world will have to adopt an > incompatible solution. And UAs that support both will need to > implement both solutions. Now as I read this draft it struck me that the application being described is more focused on intra vs inter domain VM retrieval and as such would be principally used in private enum instantiations. There should be no question that the enum service registration process can be used to define private applications that will never be used in e164.arpa or other globally visible DNS root. We have already opened up that barn door with the PSTN Signaling data RFC 4769 and with the (by the grace of ...) CNAM data as well. The issue on the table is whether this document meets the criterion for WG document and IMHO it is well within our existing charter. Since there is clearly interest here and the Enumservices registration procedures document is far from completion. I am inclined to support making this a WG document unless there is strong objection. DISCLAMER: Just because it is a WG document does not mean it will ultimately be approved etc. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 17:39:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwP5-0003cc-Qw; Thu, 13 Sep 2007 17:39:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVwP4-0003cW-At for enum@ietf.org; Thu, 13 Sep 2007 17:39:14 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVwP3-000559-FY for enum@ietf.org; Thu, 13 Sep 2007 17:39:14 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l8DLd2hS027789; Thu, 13 Sep 2007 15:39:02 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 13 Sep 2007 15:39:02 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Thu, 13 Sep 2007 15:39:04 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> In-Reply-To: <46E9A23B.9060908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf2R5m6XBcCUFtuQY27ppS7RBnSBwAA1g/g References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> From: "Jean-Francois Mule" To: "Paul Kyzivat" , "Livingood, Jason" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: enum@ietf.org, Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org To add to Jason's response, Dale wrote: > >> What's the difference between videomsg and voicemsg? Do we > >> really need a separate ENUM resolution for both of them, or > >> could we use media negotiation (like is done elsewhere in SIP)? Providing the granularity could be beneficial for some use cases. One example is providing end-user control of what type of message to leave before call attempt when both the caller and caller's UA can support voice+video: - Alice and Bob both have a mobile terminal with video capability. - Alice calls Bob's mobile using an e164 and Bob's UA returns busy - Alice's terminal pops up a dialog box asking her if she prefers to leave a voice or video mail... - and there are days or even time of days when Alice might prefer leaving a voicemail. Sure you can implement this example by letting the UAs start offer/answer to figure out what the capabilities of the UAs and then prompt the end-user. Another example is one where Alice wants to leave a video msg to Bob and Bob's mobile does not support video but he has configured his user profile to accept video messages on his PVR at home. In this case, media negotiations would only result in voice and not allow the caller preference for video (or it might if ...). Paul added: > While you're at it, don't forget there is other media than voice and > video. At least there is MSRP and real time text. The advocates for > real > time text will be on you if you don't support that. I won't speak for the MSRP case but for real-time, *conversational* text, I am not sure I understand the use case though. Wouldn't the caller use an IM/sms uri to leave a text message?=20 May be some folks do want to see what people write character by character when writing a text message, including the characters they delete and words they rewrite before confirming the message to be sent. Jean-Francois. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, September 13, 2007 2:49 PM > To: Livingood, Jason > Cc: enum@ietf.org; Dale.Worley@comcast.net > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >=20 >=20 >=20 > Livingood, Jason wrote: > > This is a great question, and one the authors stuggled with mightily. > I > > believe you could make such an arguement, essentially since SIP can > > obviously negotiate endpoint capabilities and determine if it is a > video > > or voice session. (call it mmsg for media message if you like) > > > > However, one of the concerns we surfaced is that it is possible that > the > > server infrastructure in SP networks supporting these messaging > services > > is separate, which may make it useful to be able to determine if it > > should go to a video or voice messaging server, rather than use some > > intervening network element to further proxy the communication and > > determine where to direct the session. > > > > But good point. Any other thoughts on this?? >=20 > Who is making the decision about which type to choose from enum? If > its > not the UAC then how does it know which it wants? And does your answer > differ if the INVITE doesn't contain an offer? >=20 > While you're at it, don't forget there is other media than voice and > video. At least there is MSRP and real time text. The advocates for > real > time text will be on you if you don't support that. >=20 > Paul >=20 > > Jason > > > >> -----Original Message----- > >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > >> Sent: Tuesday, September 04, 2007 2:55 PM > >> To: enum@ietf.org > >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > >> > >> From: "Livingood, Jason" > >> > >> Given that the WG is winding down, and that the co-authors of > this > >> new I-D wish to make substantive progress before IETF 70, we are > >> requesting approval of the WG chairs to make this an official WG > >> draft. > >> > >> > >> http://www.ietf.org/internet-drafts/draft-livingood-enum-video > >> msg-00.txt > >> > >> What's the difference between videomsg and voicemsg? Do we > >> really need a separate ENUM resolution for both of them, or > >> could we use media negotiation (like is done elsewhere in SIP)? > >> > >> Dale > >> > >> _______________________________________________ > >> enum mailing list > >> enum@ietf.org > >> https://www1.ietf.org/mailman/listinfo/enum > >> > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 18:50:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxVY-0004Yb-C0; Thu, 13 Sep 2007 18:50:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVxVW-0004Uc-Sv for enum@ietf.org; Thu, 13 Sep 2007 18:49:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVxVV-0001DY-KF for enum@ietf.org; Thu, 13 Sep 2007 18:49:58 -0400 X-IronPort-AV: E=Sophos;i="4.20,251,1186372800"; d="scan'208";a="131885722" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2007 18:49:56 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DMnvF1029413; Thu, 13 Sep 2007 18:49:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DMnvDw009286; Thu, 13 Sep 2007 22:49:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 18:49:56 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 18:49:56 -0400 Message-ID: <46E9BE95.4020007@cisco.com> Date: Thu, 13 Sep 2007 18:49:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jean-Francois Mule Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2007 22:49:56.0498 (UTC) FILETIME=[67F47F20:01C7F658] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7089; t=1189723797; x=1190587797; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20 |To:=20Jean-Francois=20Mule=20; bh=kRxDsHFJRXNyRJLSEDUbO+VniM0qLUlZNT19jSy0pWM=; b=u1Zs1RIUPsfXadSaOyFw8huqX8wcTZ6qPGn5DZjOKK0hjTEE7MmgRd2H19yxFVbG6zB8jJcr hIRSFLYO1WqhyZV8d0ZqHTzAeO3mDZCgou39KE+EnjI5A7w2WxVOyJYR; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: enum@ietf.org, Dale.Worley@comcast.net, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Jean-Francois Mule wrote: > To add to Jason's response, Dale wrote: >>>> What's the difference between videomsg and voicemsg? Do we >>>> really need a separate ENUM resolution for both of them, or >>>> could we use media negotiation (like is done elsewhere in SIP)? > Providing the granularity could be beneficial for some use cases. > One example is providing end-user control of what type of message to > leave before call attempt when both the caller and caller's UA can > support voice+video: > - Alice and Bob both have a mobile terminal with video > capability. > - Alice calls Bob's mobile using an e164 and Bob's UA returns > busy > - Alice's terminal pops up a dialog box asking her if she > prefers to leave a voice or video mail... > - and there are days or even time of days when Alice might > prefer leaving a voicemail. > Sure you can implement this example by letting the UAs start > offer/answer to figure out what the capabilities of the UAs and then > prompt the end-user. Alice's *preference* for what to use shouldn't be impacted by what is in the e164 registry. What is thought to be possible might be. That is actually an issue here. If an attempt was made to call Bob's mobile, the fact that it only had voice should also not impact Alice's preferences when failing over to another device. If Bob actually had *separate* VMs, one for audio, and a different one for audio+video, then if Alice prefers to have video the choice is obvious. But *why* would Bob have separate ones when audio is a subset of audio+video? That makes no sense. Its more significant if the enum db was being used like a registrar - with multiple devices having differing capabilities all registered. Then Alice may want to select which one to use based on her capabilities. But these selections by Alice only work for *user* enum. And if that is what we are talking about then this is starting to sound very much like callerprefs and callee capabilities revisited, but only for phone numbers. We could easily make a case that callerprefs and callee capabilities *ought* to be revisited, but not just for phone numbers. And I can warn you - it is a swamp. > Another example is one where Alice wants to leave a video msg to Bob and > Bob's mobile does not support video but he has configured his user > profile to accept video messages on his PVR at home. In this case, media > negotiations would only result in voice and not allow the caller > preference for video (or it might if ...). Much like above. But the preferences are really tricky to decide: - would alice rather talk live to bob, or leave a message with video? I can't even imagine how to provision a phone with a policy for that kind of decision that would work better than a random choice. I think it needs to be offered up to the caller to choose. It then starts to look like presence. > Paul added: >> While you're at it, don't forget there is other media than voice and >> video. At least there is MSRP and real time text. The advocates for >> real >> time text will be on you if you don't support that. > I won't speak for the MSRP case but for real-time, *conversational* > text, I am not sure I understand the use case though. Wouldn't the > caller use an IM/sms uri to leave a text message? > May be some folks do want to see what people write character by > character when writing a text message, including the characters they > delete and words they rewrite before confirming the message to be sent. I got flamed enough to know this is a very sensitive issue to some people. It would seem logical that character by character text or message by message text is irrelevant when leaving a message. But it does matter if the caller's device only supports one of them, or if the device of the callee when retrieving the message only supports one. I would think that the internal storage format could be the same for both if there is support for "transcoding" to either protocol. But either way, hopefully text will be just another medium, so it ought to fit in here with the others. Paul > Jean-Francois. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, September 13, 2007 2:49 PM >> To: Livingood, Jason >> Cc: enum@ietf.org; Dale.Worley@comcast.net >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >> >> >> >> Livingood, Jason wrote: >>> This is a great question, and one the authors stuggled with > mightily. >> I >>> believe you could make such an arguement, essentially since SIP can >>> obviously negotiate endpoint capabilities and determine if it is a >> video >>> or voice session. (call it mmsg for media message if you like) >>> >>> However, one of the concerns we surfaced is that it is possible that >> the >>> server infrastructure in SP networks supporting these messaging >> services >>> is separate, which may make it useful to be able to determine if it >>> should go to a video or voice messaging server, rather than use some >>> intervening network element to further proxy the communication and >>> determine where to direct the session. >>> >>> But good point. Any other thoughts on this?? >> Who is making the decision about which type to choose from enum? If >> its >> not the UAC then how does it know which it wants? And does your answer >> differ if the INVITE doesn't contain an offer? >> >> While you're at it, don't forget there is other media than voice and >> video. At least there is MSRP and real time text. The advocates for >> real >> time text will be on you if you don't support that. >> >> Paul >> >>> Jason >>> >>>> -----Original Message----- >>>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>>> Sent: Tuesday, September 04, 2007 2:55 PM >>>> To: enum@ietf.org >>>> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >>>> >>>> From: "Livingood, Jason" >>>> >>>> Given that the WG is winding down, and that the co-authors of >> this >>>> new I-D wish to make substantive progress before IETF 70, we are >>>> requesting approval of the WG chairs to make this an official WG >>>> draft. >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-livingood-enum-video >>>> msg-00.txt >>>> >>>> What's the difference between videomsg and voicemsg? Do we >>>> really need a separate ENUM resolution for both of them, or >>>> could we use media negotiation (like is done elsewhere in SIP)? >>>> >>>> Dale >>>> >>>> _______________________________________________ >>>> enum mailing list >>>> enum@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/enum >>>> >>> _______________________________________________ >>> enum mailing list >>> enum@ietf.org >>> https://www1.ietf.org/mailman/listinfo/enum >>> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 21:25:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVzvT-0002Sd-Ec; Thu, 13 Sep 2007 21:24:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVzvR-0002SV-8H for enum@ietf.org; Thu, 13 Sep 2007 21:24:53 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVzvQ-0002DR-6y for enum@ietf.org; Thu, 13 Sep 2007 21:24:53 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8E1OIVg013136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Sep 2007 18:24:24 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Jean-Francois Mule'" , References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> <46E9BE95.4020007@cisco.com> In-Reply-To: <46E9BE95.4020007@cisco.com> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Thu, 13 Sep 2007 21:24:29 -0400 Message-ID: <000001c7f66e$04b1dff0$0e159fd0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acf2WGGy4N5TLeNMQBaxh4On0L+bjAAFW5Sg Content-Language: en-us X-Spam-Score: 0.5 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Again ..the discussion over these issues once again highlights that this is a relevant document to discuss as a WG document. Any objections? > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, September 13, 2007 6:50 PM > To: Jean-Francois Mule > Cc: enum@ietf.org; Dale.Worley@comcast.net; Livingood, Jason > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > > > > Jean-Francois Mule wrote: > > To add to Jason's response, Dale wrote: > >>>> What's the difference between videomsg and voicemsg? Do we > >>>> really need a separate ENUM resolution for both of them, or > >>>> could we use media negotiation (like is done elsewhere in SIP)? > > Providing the granularity could be beneficial for some use cases. > > One example is providing end-user control of what type of message to > > leave before call attempt when both the caller and caller's UA can > > support voice+video: > > - Alice and Bob both have a mobile terminal with video > > capability. > > - Alice calls Bob's mobile using an e164 and Bob's UA returns > > busy > > - Alice's terminal pops up a dialog box asking her if she > > prefers to leave a voice or video mail... > > - and there are days or even time of days when Alice might > > prefer leaving a voicemail. > > Sure you can implement this example by letting the UAs start > > offer/answer to figure out what the capabilities of the UAs and then > > prompt the end-user. > > Alice's *preference* for what to use shouldn't be impacted by what is > in > the e164 registry. What is thought to be possible might be. That is > actually an issue here. If an attempt was made to call Bob's mobile, > the > fact that it only had voice should also not impact Alice's preferences > when failing over to another device. > > If Bob actually had *separate* VMs, one for audio, and a different one > for audio+video, then if Alice prefers to have video the choice is > obvious. But *why* would Bob have separate ones when audio is a subset > of audio+video? That makes no sense. > > Its more significant if the enum db was being used like a registrar - > with multiple devices having differing capabilities all registered. > Then > Alice may want to select which one to use based on her capabilities. > > But these selections by Alice only work for *user* enum. And if that > is > what we are talking about then this is starting to sound very much > like > callerprefs and callee capabilities revisited, but only for phone > numbers. We could easily make a case that callerprefs and callee > capabilities *ought* to be revisited, but not just for phone numbers. > And I can warn you - it is a swamp. > > > Another example is one where Alice wants to leave a video msg to Bob > and > > Bob's mobile does not support video but he has configured his user > > profile to accept video messages on his PVR at home. In this case, > media > > negotiations would only result in voice and not allow the caller > > preference for video (or it might if ...). > > Much like above. But the preferences are really tricky to decide: > > - would alice rather talk live to bob, or leave a message with video? > > I can't even imagine how to provision a phone with a policy for that > kind of decision that would work better than a random choice. I think > it > needs to be offered up to the caller to choose. It then starts to look > like presence. > > > Paul added: > >> While you're at it, don't forget there is other media than voice > and > >> video. At least there is MSRP and real time text. The advocates for > >> real > >> time text will be on you if you don't support that. > > I won't speak for the MSRP case but for real-time, *conversational* > > text, I am not sure I understand the use case though. Wouldn't the > > caller use an IM/sms uri to leave a text message? > > May be some folks do want to see what people write character by > > character when writing a text message, including the characters they > > delete and words they rewrite before confirming the message to be > sent. > > I got flamed enough to know this is a very sensitive issue to some > people. It would seem logical that character by character text or > message by message text is irrelevant when leaving a message. But it > does matter if the caller's device only supports one of them, or if > the > device of the callee when retrieving the message only supports one. > > I would think that the internal storage format could be the same for > both if there is support for "transcoding" to either protocol. > > But either way, hopefully text will be just another medium, so it > ought > to fit in here with the others. > > Paul > > > Jean-Francois. > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Thursday, September 13, 2007 2:49 PM > >> To: Livingood, Jason > >> Cc: enum@ietf.org; Dale.Worley@comcast.net > >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > >> > >> > >> > >> Livingood, Jason wrote: > >>> This is a great question, and one the authors stuggled with > > mightily. > >> I > >>> believe you could make such an arguement, essentially since SIP > can > >>> obviously negotiate endpoint capabilities and determine if it is a > >> video > >>> or voice session. (call it mmsg for media message if you like) > >>> > >>> However, one of the concerns we surfaced is that it is possible > that > >> the > >>> server infrastructure in SP networks supporting these messaging > >> services > >>> is separate, which may make it useful to be able to determine if > it > >>> should go to a video or voice messaging server, rather than use > some > >>> intervening network element to further proxy the communication and > >>> determine where to direct the session. > >>> > >>> But good point. Any other thoughts on this?? > >> Who is making the decision about which type to choose from enum? If > >> its > >> not the UAC then how does it know which it wants? And does your > answer > >> differ if the INVITE doesn't contain an offer? > >> > >> While you're at it, don't forget there is other media than voice > and > >> video. At least there is MSRP and real time text. The advocates for > >> real > >> time text will be on you if you don't support that. > >> > >> Paul > >> > >>> Jason > >>> > >>>> -----Original Message----- > >>>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > >>>> Sent: Tuesday, September 04, 2007 2:55 PM > >>>> To: enum@ietf.org > >>>> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > >>>> > >>>> From: "Livingood, Jason" > >>>> > >>>> Given that the WG is winding down, and that the co-authors of > >> this > >>>> new I-D wish to make substantive progress before IETF 70, we > are > >>>> requesting approval of the WG chairs to make this an official > WG > >>>> draft. > >>>> > >>>> > >>>> http://www.ietf.org/internet-drafts/draft-livingood-enum-video > >>>> msg-00.txt > >>>> > >>>> What's the difference between videomsg and voicemsg? Do we > >>>> really need a separate ENUM resolution for both of them, or > >>>> could we use media negotiation (like is done elsewhere in SIP)? > >>>> > >>>> Dale > >>>> > >>>> _______________________________________________ > >>>> enum mailing list > >>>> enum@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/enum > >>>> > >>> _______________________________________________ > >>> enum mailing list > >>> enum@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/enum > >>> > >> _______________________________________________ > >> enum mailing list > >> enum@ietf.org > >> https://www1.ietf.org/mailman/listinfo/enum > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Thu Sep 13 22:32:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0zA-0000n7-8b; Thu, 13 Sep 2007 22:32:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0z8-0000mx-Ax for enum@ietf.org; Thu, 13 Sep 2007 22:32:46 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW0z6-00049q-MH for enum@ietf.org; Thu, 13 Sep 2007 22:32:46 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 874C3CA212; Fri, 14 Sep 2007 03:32:43 +0100 (BST) In-Reply-To: <000001c7f66e$04b1dff0$0e159fd0$@us> References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> <46E9BE95.4020007@cisco.com> <000001c7f66e$04b1dff0$0e159fd0$@us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <172618A6-94E9-49F3-8E36-B7F070FC2DF8@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-livingood-enum-videomsg-00 Date: Fri, 14 Sep 2007 03:32:34 +0100 To: Richard Shockey X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: enum@ietf.org, 'Paul Kyzivat' , paf@cisco.com, Dale.Worley@comcast.net, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi esteemed co-chair, folks, I think that it is eminently suitable as a WG draft. It seems a perfectly reasonable idea (and draft) to me. How soon can this be turned around? [BTW, the guideline document already gives a lot of guidance on how Enumservices should be categorised. I would be uncomfortable if that document added much on censoring an Enumservice proposal because it didn't fit the one true way of doing things. We wouldn't have SIP if that had been the case in the past - whether H.323 was all we needed was a very hard question for the IETF in '96-'97] all the best, Lawrence On 14 Sep 2007, at 02:24, Richard Shockey wrote: > Again ..the discussion over these issues once again highlights that > this is > a relevant document to discuss as a WG document. > > Any objections? > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, September 13, 2007 6:50 PM >> To: Jean-Francois Mule >> Cc: enum@ietf.org; Dale.Worley@comcast.net; Livingood, Jason >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >> >> >> >> Jean-Francois Mule wrote: >>> To add to Jason's response, Dale wrote: >>>>>> What's the difference between videomsg and voicemsg? Do we >>>>>> really need a separate ENUM resolution for both of them, or >>>>>> could we use media negotiation (like is done elsewhere in SIP)? >>> Providing the granularity could be beneficial for some use cases. >>> One example is providing end-user control of what type of message to >>> leave before call attempt when both the caller and caller's UA can >>> support voice+video: >>> - Alice and Bob both have a mobile terminal with video >>> capability. >>> - Alice calls Bob's mobile using an e164 and Bob's UA returns >>> busy >>> - Alice's terminal pops up a dialog box asking her if she >>> prefers to leave a voice or video mail... >>> - and there are days or even time of days when Alice might >>> prefer leaving a voicemail. >>> Sure you can implement this example by letting the UAs start >>> offer/answer to figure out what the capabilities of the UAs and then >>> prompt the end-user. >> >> Alice's *preference* for what to use shouldn't be impacted by >> what is >> in >> the e164 registry. What is thought to be possible might be. That is >> actually an issue here. If an attempt was made to call Bob's mobile, >> the >> fact that it only had voice should also not impact Alice's >> preferences >> when failing over to another device. >> >> If Bob actually had *separate* VMs, one for audio, and a >> different one >> for audio+video, then if Alice prefers to have video the choice is >> obvious. But *why* would Bob have separate ones when audio is a >> subset >> of audio+video? That makes no sense. >> >> Its more significant if the enum db was being used like a >> registrar - >> with multiple devices having differing capabilities all registered. >> Then >> Alice may want to select which one to use based on her capabilities. >> >> But these selections by Alice only work for *user* enum. And if that >> is >> what we are talking about then this is starting to sound very much >> like >> callerprefs and callee capabilities revisited, but only for phone >> numbers. We could easily make a case that callerprefs and callee >> capabilities *ought* to be revisited, but not just for phone >> numbers. >> And I can warn you - it is a swamp. >> >>> Another example is one where Alice wants to leave a video msg to Bob >> and >>> Bob's mobile does not support video but he has configured his user >>> profile to accept video messages on his PVR at home. In this case, >> media >>> negotiations would only result in voice and not allow the caller >>> preference for video (or it might if ...). >> >> Much like above. But the preferences are really tricky to decide: >> >> - would alice rather talk live to bob, or leave a message with >> video? >> >> I can't even imagine how to provision a phone with a policy for that >> kind of decision that would work better than a random choice. I >> think >> it >> needs to be offered up to the caller to choose. It then starts to >> look >> like presence. >> >>> Paul added: >>>> While you're at it, don't forget there is other media than voice >> and >>>> video. At least there is MSRP and real time text. The advocates for >>>> real >>>> time text will be on you if you don't support that. >>> I won't speak for the MSRP case but for real-time, *conversational* >>> text, I am not sure I understand the use case though. Wouldn't the >>> caller use an IM/sms uri to leave a text message? >>> May be some folks do want to see what people write character by >>> character when writing a text message, including the characters they >>> delete and words they rewrite before confirming the message to be >> sent. >> >> I got flamed enough to know this is a very sensitive issue to some >> people. It would seem logical that character by character text or >> message by message text is irrelevant when leaving a message. But it >> does matter if the caller's device only supports one of them, or if >> the >> device of the callee when retrieving the message only supports one. >> >> I would think that the internal storage format could be the same for >> both if there is support for "transcoding" to either protocol. >> >> But either way, hopefully text will be just another medium, so it >> ought >> to fit in here with the others. >> >> Paul >> >>> Jean-Francois. >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Thursday, September 13, 2007 2:49 PM >>>> To: Livingood, Jason >>>> Cc: enum@ietf.org; Dale.Worley@comcast.net >>>> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >>>> >>>> >>>> >>>> Livingood, Jason wrote: >>>>> This is a great question, and one the authors stuggled with >>> mightily. >>>> I >>>>> believe you could make such an arguement, essentially since SIP >> can >>>>> obviously negotiate endpoint capabilities and determine if it is a >>>> video >>>>> or voice session. (call it mmsg for media message if you like) >>>>> >>>>> However, one of the concerns we surfaced is that it is possible >> that >>>> the >>>>> server infrastructure in SP networks supporting these messaging >>>> services >>>>> is separate, which may make it useful to be able to determine if >> it >>>>> should go to a video or voice messaging server, rather than use >> some >>>>> intervening network element to further proxy the communication and >>>>> determine where to direct the session. >>>>> >>>>> But good point. Any other thoughts on this?? >>>> Who is making the decision about which type to choose from enum? If >>>> its >>>> not the UAC then how does it know which it wants? And does your >> answer >>>> differ if the INVITE doesn't contain an offer? >>>> >>>> While you're at it, don't forget there is other media than voice >> and >>>> video. At least there is MSRP and real time text. The advocates for >>>> real >>>> time text will be on you if you don't support that. >>>> >>>> Paul >>>> >>>>> Jason >>>>> >>>>>> -----Original Message----- >>>>>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>>>>> Sent: Tuesday, September 04, 2007 2:55 PM >>>>>> To: enum@ietf.org >>>>>> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >>>>>> >>>>>> From: "Livingood, Jason" >>>>>> >>>>>> Given that the WG is winding down, and that the co-authors of >>>> this >>>>>> new I-D wish to make substantive progress before IETF 70, we >> are >>>>>> requesting approval of the WG chairs to make this an official >> WG >>>>>> draft. >>>>>> >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-livingood-enum-video >>>>>> msg-00.txt >>>>>> >>>>>> What's the difference between videomsg and voicemsg? Do we >>>>>> really need a separate ENUM resolution for both of them, or >>>>>> could we use media negotiation (like is done elsewhere in SIP)? >>>>>> >>>>>> Dale >>>>>> >>>>>> _______________________________________________ >>>>>> enum mailing list >>>>>> enum@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/enum >>>>>> >>>>> _______________________________________________ >>>>> enum mailing list >>>>> enum@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/enum >>>>> >>>> _______________________________________________ >>>> enum mailing list >>>> enum@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/enum >>> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 14 05:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7bI-0008N4-Bn; Fri, 14 Sep 2007 05:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7bH-0008My-FT for enum@ietf.org; Fri, 14 Sep 2007 05:36:35 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW7bG-0008Gr-5x for enum@ietf.org; Fri, 14 Sep 2007 05:36:35 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l8E9aPSn013283; Fri, 14 Sep 2007 03:36:26 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 14 Sep 2007 03:36:26 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Fri, 14 Sep 2007 03:36:19 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> In-Reply-To: <46E9BE95.4020007@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf2WHA5gKATsly4TGic6B2Fj+lilgAWFYcA References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> <46E9BE95.4020007@cisco.com> From: "Jean-Francois Mule" To: "Paul Kyzivat" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: enum@ietf.org, Dale.Worley@comcast.net, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Paul, You wrote: > Alice's *preference* for what to use shouldn't be impacted by what is > in > the e164 registry.=20 But in some cases, I do see a negative if the "e164 registry" were provide information that might help meet Alice's preference without even having to call Bob. > If Bob actually had *separate* VMs, one for audio, and a different one > for audio+video, then if Alice prefers to have video the choice is > obvious. But *why* would Bob have separate ones when audio is a subset > of audio+video? That makes no sense. Why constraint Bob's choice? There are real life scenarios today for why many of us have to deal with various multimedia mailboxes and why some are audio-only, while others are audio+video. It may make no sense to you but why not allow mechanisms for Bob to deal with it? > It would seem logical that character by character text or > message by message text is irrelevant when leaving a message.=20 This was the point I meant. > But it > does matter if the caller's device only supports one of them, or if > the > device of the callee when retrieving the message only supports one. Now, you are diverging: we should separate message deposit from message retrieval and how the latter is linked with device capabilities should not necessarily impact how the former is made possible.=20 Jean-Francois. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 14 05:38:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7dE-0002zu-C8; Fri, 14 Sep 2007 05:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7dD-0002w3-30 for enum@ietf.org; Fri, 14 Sep 2007 05:38:35 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW7dB-0008JY-Rx for enum@ietf.org; Fri, 14 Sep 2007 05:38:35 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l8E9cVKf013891; Fri, 14 Sep 2007 03:38:31 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 14 Sep 2007 03:38:31 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Fri, 14 Sep 2007 03:38:24 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C65E098F@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf2WHA5gKATsly4TGic6B2Fj+lilgAWFYcAAACIJQA= References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> From: "Jean-Francois Mule" To: "Paul Kyzivat" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: enum@ietf.org, Dale.Worley@comcast.net, "Livingood, Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Correction: > But in some cases, I do see a negative if the "e164 registry" were ^ not=20 > provide information that might help meet Alice's preference without > even > having to call Bob. > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Friday, September 14, 2007 3:36 AM > To: Paul Kyzivat > Cc: enum@ietf.org; Dale.Worley@comcast.net; Livingood,Jason > Subject: RE: [Enum] draft-livingood-enum-videomsg-00 >=20 > Hi Paul, >=20 > You wrote: > > Alice's *preference* for what to use shouldn't be impacted by what > is > > in > > the e164 registry. > But in some cases, I do see a negative if the "e164 registry" were > provide information that might help meet Alice's preference without > even > having to call Bob. >=20 > > If Bob actually had *separate* VMs, one for audio, and a different > one > > for audio+video, then if Alice prefers to have video the choice is > > obvious. But *why* would Bob have separate ones when audio is a > subset > > of audio+video? That makes no sense. > Why constraint Bob's choice? There are real life scenarios today for > why > many of us have to deal with various multimedia mailboxes and why some > are audio-only, while others are audio+video. It may make no sense to > you but why not allow mechanisms for Bob to deal with it? >=20 > > It would seem logical that character by character text or > > message by message text is irrelevant when leaving a message. > This was the point I meant. >=20 > > But it > > does matter if the caller's device only supports one of them, or if > > the > > device of the callee when retrieving the message only supports one. > Now, you are diverging: we should separate message deposit from > message > retrieval and how the latter is linked with device capabilities should > not necessarily impact how the former is made possible. >=20 > Jean-Francois. >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 14 09:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBas-0008S2-EV; Fri, 14 Sep 2007 09:52:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBar-0008RY-69 for enum@ietf.org; Fri, 14 Sep 2007 09:52:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWBaq-0007gD-Sj for enum@ietf.org; Fri, 14 Sep 2007 09:52:25 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWBb5-0008TP-5r; Fri, 14 Sep 2007 08:52:39 -0500 From: "Brian Rosen" To: "'Jean-Francois Mule'" , "'Paul Kyzivat'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Fri, 14 Sep 2007 09:52:20 -0400 Message-ID: <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf2WHA5gKATsly4TGic6B2Fj+lilgAWFYcAAAkT75A= In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > > It would seem logical that character by character text or > > message by message text is irrelevant when leaving a message. > This was the point I meant. > > > But it > > does matter if the caller's device only supports one of them, or if > > the > > device of the callee when retrieving the message only supports one. > Now, you are diverging: we should separate message deposit from message > retrieval and how the latter is linked with device capabilities should > not necessarily impact how the former is made possible. I think you have a problem here anyway. If I'm a deaf caller and I send an INVITE with a real-time text codec, and the call gets diverted to a text-mail system, then are you expecting the offer to be refused, and the answer to only supply message-at-a-time options? What if I have different clients for IM then real-time text? Brian _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 14 16:18:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHcd-0002Wh-Tq; Fri, 14 Sep 2007 16:18:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHcd-0002Wa-7L for enum@ietf.org; Fri, 14 Sep 2007 16:18:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWHcc-0003Ar-Pv for enum@ietf.org; Fri, 14 Sep 2007 16:18:39 -0400 X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="18139148" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 14 Sep 2007 13:18:38 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8EKIcnq004796; Fri, 14 Sep 2007 13:18:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8EKIULg025498; Fri, 14 Sep 2007 20:18:37 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 16:18:33 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 16:18:32 -0400 Message-ID: <46EAEC96.8000803@cisco.com> Date: Fri, 14 Sep 2007 16:18:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> In-Reply-To: <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Sep 2007 20:18:32.0509 (UTC) FILETIME=[6BE386D0:01C7F70C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1768; t=1189801118; x=1190665118; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20; bh=OuHqccWx034y/uzpYtstQv1wUV8G4djsm6Bvi0Df+Mc=; b=UfDm+iys2T0Lz/+i829fOyBozqgHpIX6AFmy8n/sEks+6jbiTP3WHGFcUC8rGAAI52yWEq7m u0bk7MiVw1+lKRckaCao94XjNkamUKg45XW1YGvCbQXWS8mCPmjYS7ds; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: enum@ietf.org, "'Livingood, Jason'" , Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Brian Rosen wrote: >>> It would seem logical that character by character text or >>> message by message text is irrelevant when leaving a message. >> This was the point I meant. >> >>> But it >>> does matter if the caller's device only supports one of them, or if >>> the >>> device of the callee when retrieving the message only supports one. >> Now, you are diverging: we should separate message deposit from message >> retrieval and how the latter is linked with device capabilities should >> not necessarily impact how the former is made possible. > I think you have a problem here anyway. > > If I'm a deaf caller and I send an INVITE with a real-time text codec, and > the call gets diverted to a text-mail system, then are you expecting the > offer to be refused, and the answer to only supply message-at-a-time > options? > > What if I have different clients for IM then real-time text? Yeah, this is what I was getting at. From a practical perspective it probably does make sense for the RTT devices to also support IM, because there will be lots of cases where an IM call is the only alternative to no call, even if the RTT is preferred. Such devices would preferably always offer both in order to maximize the chances of call success. Also, it seems like it would be quite straightforward for a UI that supports RTT to also support IM. But that doesn't mean that is what will get deployed. If any RTT devices without IM support get out there, then I imagine there would strong pushes for answering systems to support them. Even if every device that supports RTT also supports IM, that would at least drive a demand that answering systems that support voice support either RTT or IM or both. Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 14 16:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHvY-0005FM-U8; Fri, 14 Sep 2007 16:38:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHvX-0005D8-G0; Fri, 14 Sep 2007 16:38:11 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWHvX-0003cK-71; Fri, 14 Sep 2007 16:38:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D2987175C1; Fri, 14 Sep 2007 20:37:40 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IWHv2-0004EU-AU; Fri, 14 Sep 2007 16:37:40 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 14 Sep 2007 16:37:40 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: enum mailing list , enum chair , Internet Architecture Board , RFC Editor Subject: [Enum] Document Action: 'Infrastructure ENUM Requirements' to Informational RFC X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IESG has approved the following document: - 'Infrastructure ENUM Requirements ' as an Informational RFC This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-04.txt Technical Summary This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Because end user ENUM as defined in RFC 3761 requires end user opt-in and control of the location of the NAPTRs, it is not suitable for interconnection needs bu service providers. The requirements in the document are needed for the WG to develop a technical solution. Working Group Summary The working group reviewed this document in 2005-6 and was document NIT review preformed by Alexander Mayrhofer Protocol Quality This document was reviewed for the IESG by Jon Peterson. Gen-ART review was performed by Gonzalo Camarillo. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 14 16:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWI1m-0005c6-Op; Fri, 14 Sep 2007 16:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWI1l-0005ab-7y for enum@ietf.org; Fri, 14 Sep 2007 16:44:37 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWI1j-0001vv-Vs for enum@ietf.org; Fri, 14 Sep 2007 16:44:37 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWI1h-0001DJ-VX; Fri, 14 Sep 2007 15:44:34 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Fri, 14 Sep 2007 16:44:32 -0400 Message-ID: <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf3DHUfgLwzHBsCTAGAvghy9dcJ3wAAu+VA In-Reply-To: <46EAEC96.8000803@cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: enum@ietf.org, "'Livingood, Jason'" , Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yeah, and we need another enum service or two if we're differentiating voice from video. Which, I think, is pretty ridiculous, but if we're going down that path, then we need one for every possible kind of media. What do you do if you offer video+audio+real time text+im? In particular, is it the origination network that decides what mailbox service you get or the termination side? If it's done with enum, then it's the origination side, which makes the enum dip to route the call, that decides. That means the recipient, who has all of these services, doesn't decide how they are used, other than possibly controlling what services are advertised in the enum zone. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, September 14, 2007 4:19 PM > To: Brian Rosen > Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; > 'Livingood, Jason' > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > > > > Brian Rosen wrote: > >>> It would seem logical that character by character text or > >>> message by message text is irrelevant when leaving a message. > >> This was the point I meant. > >> > >>> But it > >>> does matter if the caller's device only supports one of them, or if > >>> the > >>> device of the callee when retrieving the message only supports one. > >> Now, you are diverging: we should separate message deposit from message > >> retrieval and how the latter is linked with device capabilities should > >> not necessarily impact how the former is made possible. > > I think you have a problem here anyway. > > > > If I'm a deaf caller and I send an INVITE with a real-time text codec, > and > > the call gets diverted to a text-mail system, then are you expecting the > > offer to be refused, and the answer to only supply message-at-a-time > > options? > > > > What if I have different clients for IM then real-time text? > > Yeah, this is what I was getting at. > > From a practical perspective it probably does make sense for the RTT > devices to also support IM, because there will be lots of cases where an > IM call is the only alternative to no call, even if the RTT is > preferred. Such devices would preferably always offer both in order to > maximize the chances of call success. Also, it seems like it would be > quite straightforward for a UI that supports RTT to also support IM. > > But that doesn't mean that is what will get deployed. If any RTT devices > without IM support get out there, then I imagine there would strong > pushes for answering systems to support them. > > Even if every device that supports RTT also supports IM, that would at > least drive a demand that answering systems that support voice support > either RTT or IM or both. > > Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Fri Sep 14 18:41:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJqc-00052n-41; Fri, 14 Sep 2007 18:41:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJqb-00051w-Do for enum@ietf.org; Fri, 14 Sep 2007 18:41:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWJqa-0008Th-H1 for enum@ietf.org; Fri, 14 Sep 2007 18:41:13 -0400 X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="524209873" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2007 15:41:12 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8EMfBwY018591; Fri, 14 Sep 2007 15:41:11 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8EMfAef003380; Fri, 14 Sep 2007 22:41:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 18:41:11 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 18:41:10 -0400 Message-ID: <46EB0E05.5030405@cisco.com> Date: Fri, 14 Sep 2007 18:41:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> In-Reply-To: <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Sep 2007 22:41:10.0751 (UTC) FILETIME=[58FF9EF0:01C7F720] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4727; t=1189809671; x=1190673671; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20; bh=gacrIsCdXAqoVvU2hRrlLo9my8DA3p10JB4Ftt3W4Ac=; b=IpFvzcQpnYIRbtQEr7ZkT48eyjl2JQM8kEqxAQO9PDA/u9qjgXOiFQTBQKe/TdlBs7t1YLXb nO5sEBgaXhswMHsm6zODSYjo111s6u/hdZkdRF3joOl0+tWZOLvGyrgb; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: enum@ietf.org, "'Livingood, Jason'" , Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Brian, You and I are on the same page here! Who chooses depends on whether this is user enum or infrastructure enum I guess. If its infrastructure enum used at the terminating side then the policies are recipient policies. But because the data is coming from enum, it seems likely that it will have to be the same policy for all of the provider's subscribers. If its user enum, then it is the caller that is choosing. I guess that is ok, if the user decided to put all that stuff in there for the caller to choose from. As you note, the problem with this scheme is that it doesn't seem to provide a way to indicate a target for combinations. I guess you can enter the same URL several times, for: audio, video, im, rtt, etc. And then the caller can gather all of those and cluster them by URL to figure out what combinations are supported. Ugh! When applied at the infrastructure side this is a lot like callee capabilities. It would be a lot simpler if you could simply enter a sip URL *with* the capabilities as a single enum entry. But I think that is not possible, because the output of enum is just a URL, but the sip capabilities are represented as *header* parameters and so not part of the URL. When applied at the user enum side, this is a lot like presence. My biggest problem is that I see phone numbers and sip urls not as layers but simply as alternative forms of addressing the same pool of potential callees. So I think there should be a common mechanism for any problem that comes down to choosing among alternative targets for a given address. Whether I call sip:pkyzivat@cisco.com or tel:+19785551881 I still need to potential to fail over to voicemail if there is no answer. A different mechanism based on address type is a liability. Paul Brian Rosen wrote: > Yeah, and we need another enum service or two if we're differentiating voice > from video. > > Which, I think, is pretty ridiculous, but if we're going down that path, > then we need one for every possible kind of media. > > What do you do if you offer video+audio+real time text+im? In particular, > is it the origination network that decides what mailbox service you get or > the termination side? If it's done with enum, then it's the origination > side, which makes the enum dip to route the call, that decides. > > That means the recipient, who has all of these services, doesn't decide how > they are used, other than possibly controlling what services are advertised > in the enum zone. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, September 14, 2007 4:19 PM >> To: Brian Rosen >> Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; >> 'Livingood, Jason' >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >> >> >> >> Brian Rosen wrote: >>>>> It would seem logical that character by character text or >>>>> message by message text is irrelevant when leaving a message. >>>> This was the point I meant. >>>> >>>>> But it >>>>> does matter if the caller's device only supports one of them, or if >>>>> the >>>>> device of the callee when retrieving the message only supports one. >>>> Now, you are diverging: we should separate message deposit from message >>>> retrieval and how the latter is linked with device capabilities should >>>> not necessarily impact how the former is made possible. >>> I think you have a problem here anyway. >>> >>> If I'm a deaf caller and I send an INVITE with a real-time text codec, >> and >>> the call gets diverted to a text-mail system, then are you expecting the >>> offer to be refused, and the answer to only supply message-at-a-time >>> options? >>> >>> What if I have different clients for IM then real-time text? >> Yeah, this is what I was getting at. >> >> From a practical perspective it probably does make sense for the RTT >> devices to also support IM, because there will be lots of cases where an >> IM call is the only alternative to no call, even if the RTT is >> preferred. Such devices would preferably always offer both in order to >> maximize the chances of call success. Also, it seems like it would be >> quite straightforward for a UI that supports RTT to also support IM. >> >> But that doesn't mean that is what will get deployed. If any RTT devices >> without IM support get out there, then I imagine there would strong >> pushes for answering systems to support them. >> >> Even if every device that supports RTT also supports IM, that would at >> least drive a demand that answering systems that support voice support >> either RTT or IM or both. >> >> Paul > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 15 10:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWYYN-00052l-I8; Sat, 15 Sep 2007 10:23:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWYYL-00052Y-NL for enum@ietf.org; Sat, 15 Sep 2007 10:23:21 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWYYK-0002N7-Ez for enum@ietf.org; Sat, 15 Sep 2007 10:23:21 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWYYc-0000qg-Ii; Sat, 15 Sep 2007 09:23:38 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Sat, 15 Sep 2007 10:23:16 -0400 Message-ID: <0b7301c7f7a3$f6fca1b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf3IF8bj7bYJzFiSI2Ey3KIt81U0gAgs5+A In-Reply-To: <46EB0E05.5030405@cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: enum@ietf.org, "'Livingood, Jason'" , Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yah A nit though. With infrastructure enum, conventionally, the origination carrier uses infrastructure enum to discover a route to the destination carrier. The destination carrier gets to decide what URIs to put in the zone, but it would be the origination side which decided which of these URIs to follow if there was more than one. Since the query doesn't have the media "offer", there isn't any cleverness possible in what is returned from the query. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, September 14, 2007 6:41 PM > To: Brian Rosen > Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; > 'Livingood, Jason' > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > > Brian, > > You and I are on the same page here! > > Who chooses depends on whether this is user enum or infrastructure enum > I guess. If its infrastructure enum used at the terminating side then > the policies are recipient policies. But because the data is coming from > enum, it seems likely that it will have to be the same policy for all of > the provider's subscribers. > > If its user enum, then it is the caller that is choosing. I guess that > is ok, if the user decided to put all that stuff in there for the caller > to choose from. > > As you note, the problem with this scheme is that it doesn't seem to > provide a way to indicate a target for combinations. I guess you can > enter the same URL several times, for: audio, video, im, rtt, etc. And > then the caller can gather all of those and cluster them by URL to > figure out what combinations are supported. Ugh! > > When applied at the infrastructure side this is a lot like callee > capabilities. It would be a lot simpler if you could simply enter a sip > URL *with* the capabilities as a single enum entry. But I think that is > not possible, because the output of enum is just a URL, but the sip > capabilities are represented as *header* parameters and so not part of > the URL. > > When applied at the user enum side, this is a lot like presence. > > My biggest problem is that I see phone numbers and sip urls not as > layers but simply as alternative forms of addressing the same pool of > potential callees. So I think there should be a common mechanism for any > problem that comes down to choosing among alternative targets for a > given address. Whether I call sip:pkyzivat@cisco.com or tel:+19785551881 > I still need to potential to fail over to voicemail if there is no > answer. A different mechanism based on address type is a liability. > > Paul > > Brian Rosen wrote: > > Yeah, and we need another enum service or two if we're differentiating > voice > > from video. > > > > Which, I think, is pretty ridiculous, but if we're going down that path, > > then we need one for every possible kind of media. > > > > What do you do if you offer video+audio+real time text+im? In > particular, > > is it the origination network that decides what mailbox service you get > or > > the termination side? If it's done with enum, then it's the origination > > side, which makes the enum dip to route the call, that decides. > > > > That means the recipient, who has all of these services, doesn't decide > how > > they are used, other than possibly controlling what services are > advertised > > in the enum zone. > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, September 14, 2007 4:19 PM > >> To: Brian Rosen > >> Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; > >> 'Livingood, Jason' > >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > >> > >> > >> > >> Brian Rosen wrote: > >>>>> It would seem logical that character by character text or > >>>>> message by message text is irrelevant when leaving a message. > >>>> This was the point I meant. > >>>> > >>>>> But it > >>>>> does matter if the caller's device only supports one of them, or if > >>>>> the > >>>>> device of the callee when retrieving the message only supports one. > >>>> Now, you are diverging: we should separate message deposit from > message > >>>> retrieval and how the latter is linked with device capabilities > should > >>>> not necessarily impact how the former is made possible. > >>> I think you have a problem here anyway. > >>> > >>> If I'm a deaf caller and I send an INVITE with a real-time text codec, > >> and > >>> the call gets diverted to a text-mail system, then are you expecting > the > >>> offer to be refused, and the answer to only supply message-at-a-time > >>> options? > >>> > >>> What if I have different clients for IM then real-time text? > >> Yeah, this is what I was getting at. > >> > >> From a practical perspective it probably does make sense for the RTT > >> devices to also support IM, because there will be lots of cases where > an > >> IM call is the only alternative to no call, even if the RTT is > >> preferred. Such devices would preferably always offer both in order to > >> maximize the chances of call success. Also, it seems like it would be > >> quite straightforward for a UI that supports RTT to also support IM. > >> > >> But that doesn't mean that is what will get deployed. If any RTT > devices > >> without IM support get out there, then I imagine there would strong > >> pushes for answering systems to support them. > >> > >> Even if every device that supports RTT also supports IM, that would at > >> least drive a demand that answering systems that support voice support > >> either RTT or IM or both. > >> > >> Paul > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 15 10:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWZ0z-0006Gr-5i; Sat, 15 Sep 2007 10:52:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWZ0x-00069y-C5 for enum@ietf.org; Sat, 15 Sep 2007 10:52:55 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWZ0w-0000Ph-Ce for enum@ietf.org; Sat, 15 Sep 2007 10:52:55 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8FEq3pq007911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Sep 2007 07:52:07 -0700 From: "Richard Shockey" To: "'Brian Rosen'" , "'Paul Kyzivat'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <0b7301c7f7a3$f6fca1b0$640fa8c0@cis.neustar.com> In-Reply-To: <0b7301c7f7a3$f6fca1b0$640fa8c0@cis.neustar.com> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Sat, 15 Sep 2007 10:52:06 -0400 Message-ID: <040d01c7f7a8$006a4780$013ed680$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acf3IF8bj7bYJzFiSI2Ey3KIt81U0gAgs5+AAAEQQaA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org So whats your point ? What you are doing is reducing the aggregate number of invites to the destination carrier since you may have narrowed your service search parameters to those advertised. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Saturday, September 15, 2007 10:23 AM > To: 'Paul Kyzivat' > Cc: enum@ietf.org; 'Livingood, Jason'; Dale.Worley@comcast.net > Subject: RE: [Enum] draft-livingood-enum-videomsg-00 > > Yah > > A nit though. With infrastructure enum, conventionally, the > origination > carrier uses infrastructure enum to discover a route to the > destination > carrier. The destination carrier gets to decide what URIs to put in > the > zone, but it would be the origination side which decided which of > these URIs > to follow if there was more than one. Since the query doesn't have > the > media "offer", there isn't any cleverness possible in what is returned > from > the query. > > Brian > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, September 14, 2007 6:41 PM > > To: Brian Rosen > > Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; > > 'Livingood, Jason' > > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > > > > Brian, > > > > You and I are on the same page here! > > > > Who chooses depends on whether this is user enum or infrastructure > enum > > I guess. If its infrastructure enum used at the terminating side > then > > the policies are recipient policies. But because the data is coming > from > > enum, it seems likely that it will have to be the same policy for > all of > > the provider's subscribers. > > > > If its user enum, then it is the caller that is choosing. I guess > that > > is ok, if the user decided to put all that stuff in there for the > caller > > to choose from. > > > > As you note, the problem with this scheme is that it doesn't seem to > > provide a way to indicate a target for combinations. I guess you can > > enter the same URL several times, for: audio, video, im, rtt, etc. > And > > then the caller can gather all of those and cluster them by URL to > > figure out what combinations are supported. Ugh! > > > > When applied at the infrastructure side this is a lot like callee > > capabilities. It would be a lot simpler if you could simply enter a > sip > > URL *with* the capabilities as a single enum entry. But I think that > is > > not possible, because the output of enum is just a URL, but the sip > > capabilities are represented as *header* parameters and so not part > of > > the URL. > > > > When applied at the user enum side, this is a lot like presence. > > > > My biggest problem is that I see phone numbers and sip urls not as > > layers but simply as alternative forms of addressing the same pool > of > > potential callees. So I think there should be a common mechanism for > any > > problem that comes down to choosing among alternative targets for a > > given address. Whether I call sip:pkyzivat@cisco.com or > tel:+19785551881 > > I still need to potential to fail over to voicemail if there is no > > answer. A different mechanism based on address type is a liability. > > > > Paul > > > > Brian Rosen wrote: > > > Yeah, and we need another enum service or two if we're > differentiating > > voice > > > from video. > > > > > > Which, I think, is pretty ridiculous, but if we're going down that > path, > > > then we need one for every possible kind of media. > > > > > > What do you do if you offer video+audio+real time text+im? In > > particular, > > > is it the origination network that decides what mailbox service > you get > > or > > > the termination side? If it's done with enum, then it's the > origination > > > side, which makes the enum dip to route the call, that decides. > > > > > > That means the recipient, who has all of these services, doesn't > decide > > how > > > they are used, other than possibly controlling what services are > > advertised > > > in the enum zone. > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Friday, September 14, 2007 4:19 PM > > >> To: Brian Rosen > > >> Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; > > >> 'Livingood, Jason' > > >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > > >> > > >> > > >> > > >> Brian Rosen wrote: > > >>>>> It would seem logical that character by character text or > > >>>>> message by message text is irrelevant when leaving a message. > > >>>> This was the point I meant. > > >>>> > > >>>>> But it > > >>>>> does matter if the caller's device only supports one of them, > or if > > >>>>> the > > >>>>> device of the callee when retrieving the message only supports > one. > > >>>> Now, you are diverging: we should separate message deposit from > > message > > >>>> retrieval and how the latter is linked with device capabilities > > should > > >>>> not necessarily impact how the former is made possible. > > >>> I think you have a problem here anyway. > > >>> > > >>> If I'm a deaf caller and I send an INVITE with a real-time text > codec, > > >> and > > >>> the call gets diverted to a text-mail system, then are you > expecting > > the > > >>> offer to be refused, and the answer to only supply message-at-a- > time > > >>> options? > > >>> > > >>> What if I have different clients for IM then real-time text? > > >> Yeah, this is what I was getting at. > > >> > > >> From a practical perspective it probably does make sense for the > RTT > > >> devices to also support IM, because there will be lots of cases > where > > an > > >> IM call is the only alternative to no call, even if the RTT is > > >> preferred. Such devices would preferably always offer both in > order to > > >> maximize the chances of call success. Also, it seems like it > would be > > >> quite straightforward for a UI that supports RTT to also support > IM. > > >> > > >> But that doesn't mean that is what will get deployed. If any RTT > > devices > > >> without IM support get out there, then I imagine there would > strong > > >> pushes for answering systems to support them. > > >> > > >> Even if every device that supports RTT also supports IM, that > would at > > >> least drive a demand that answering systems that support voice > support > > >> either RTT or IM or both. > > >> > > >> Paul > > > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 15 10:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWZ6y-00055G-3e; Sat, 15 Sep 2007 10:59:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWZ6w-000559-RO for enum@ietf.org; Sat, 15 Sep 2007 10:59:06 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWZ6v-0000ZC-Va for enum@ietf.org; Sat, 15 Sep 2007 10:59:06 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8FEwbtu008581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Sep 2007 07:58:38 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'Brian Rosen'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> In-Reply-To: <46EB0E05.5030405@cisco.com> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Sat, 15 Sep 2007 10:58:40 -0400 Message-ID: <040e01c7f7a8$e9042d80$bb0c8880$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acf3IFKXm8jbVmDOTmqP0TCAtb4m7wAh+JBA Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Paul this discussion is excellent but you have not answered my practical question of what are, if any, the policies the IETF should have regarding what strings should or should not be Enumservice registrations. Should we have a separate ones for user vs infrastructure or just let 10,000 flowers bloom .. You are dancing around the issue without confronting it. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, September 14, 2007 6:41 PM > To: Brian Rosen > Cc: enum@ietf.org; 'Livingood, Jason'; Dale.Worley@comcast.net > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > > Brian, > > You and I are on the same page here! > > Who chooses depends on whether this is user enum or infrastructure > enum > I guess. If its infrastructure enum used at the terminating side then > the policies are recipient policies. But because the data is coming > from > enum, it seems likely that it will have to be the same policy for all > of > the provider's subscribers. > > If its user enum, then it is the caller that is choosing. I guess that > is ok, if the user decided to put all that stuff in there for the > caller > to choose from. > > As you note, the problem with this scheme is that it doesn't seem to > provide a way to indicate a target for combinations. I guess you can > enter the same URL several times, for: audio, video, im, rtt, etc. And > then the caller can gather all of those and cluster them by URL to > figure out what combinations are supported. Ugh! > > When applied at the infrastructure side this is a lot like callee > capabilities. It would be a lot simpler if you could simply enter a > sip > URL *with* the capabilities as a single enum entry. But I think that > is > not possible, because the output of enum is just a URL, but the sip > capabilities are represented as *header* parameters and so not part of > the URL. > > When applied at the user enum side, this is a lot like presence. > > My biggest problem is that I see phone numbers and sip urls not as > layers but simply as alternative forms of addressing the same pool of > potential callees. So I think there should be a common mechanism for > any > problem that comes down to choosing among alternative targets for a > given address. Whether I call sip:pkyzivat@cisco.com or > tel:+19785551881 > I still need to potential to fail over to voicemail if there is no > answer. A different mechanism based on address type is a liability. > > Paul > > Brian Rosen wrote: > > Yeah, and we need another enum service or two if we're > differentiating voice > > from video. > > > > Which, I think, is pretty ridiculous, but if we're going down that > path, > > then we need one for every possible kind of media. > > > > What do you do if you offer video+audio+real time text+im? In > particular, > > is it the origination network that decides what mailbox service you > get or > > the termination side? If it's done with enum, then it's the > origination > > side, which makes the enum dip to route the call, that decides. > > > > That means the recipient, who has all of these services, doesn't > decide how > > they are used, other than possibly controlling what services are > advertised > > in the enum zone. > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, September 14, 2007 4:19 PM > >> To: Brian Rosen > >> Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; > >> 'Livingood, Jason' > >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > >> > >> > >> > >> Brian Rosen wrote: > >>>>> It would seem logical that character by character text or > >>>>> message by message text is irrelevant when leaving a message. > >>>> This was the point I meant. > >>>> > >>>>> But it > >>>>> does matter if the caller's device only supports one of them, or > if > >>>>> the > >>>>> device of the callee when retrieving the message only supports > one. > >>>> Now, you are diverging: we should separate message deposit from > message > >>>> retrieval and how the latter is linked with device capabilities > should > >>>> not necessarily impact how the former is made possible. > >>> I think you have a problem here anyway. > >>> > >>> If I'm a deaf caller and I send an INVITE with a real-time text > codec, > >> and > >>> the call gets diverted to a text-mail system, then are you > expecting the > >>> offer to be refused, and the answer to only supply message-at-a- > time > >>> options? > >>> > >>> What if I have different clients for IM then real-time text? > >> Yeah, this is what I was getting at. > >> > >> From a practical perspective it probably does make sense for the > RTT > >> devices to also support IM, because there will be lots of cases > where an > >> IM call is the only alternative to no call, even if the RTT is > >> preferred. Such devices would preferably always offer both in order > to > >> maximize the chances of call success. Also, it seems like it would > be > >> quite straightforward for a UI that supports RTT to also support > IM. > >> > >> But that doesn't mean that is what will get deployed. If any RTT > devices > >> without IM support get out there, then I imagine there would strong > >> pushes for answering systems to support them. > >> > >> Even if every device that supports RTT also supports IM, that would > at > >> least drive a demand that answering systems that support voice > support > >> either RTT or IM or both. > >> > >> Paul > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 15 13:37:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbaI-0003TZ-K6; Sat, 15 Sep 2007 13:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbaH-0003TR-1H for enum@ietf.org; Sat, 15 Sep 2007 13:37:33 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWbaF-00079E-RD for enum@ietf.org; Sat, 15 Sep 2007 13:37:33 -0400 Received: from hkaplan [75.68.59.21] by acmepacket.com with ESMTP (SMTPD-9.10) id A859057C; Sat, 15 Sep 2007 13:37:29 -0400 From: "Hadriel Kaplan" To: "'Paul Kyzivat'" , "'Brian Rosen'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com><0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Sat, 15 Sep 2007 13:36:05 -0400 Message-ID: <002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Acf3IGbbJyRVcvrnT0WgUoygSlZECAAlgSRQ In-Reply-To: <46EB0E05.5030405@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > As you note, the problem with this scheme is that it doesn't seem to > provide a way to indicate a target for combinations. I guess you can > enter the same URL several times, for: audio, video, im, rtt, etc. And > then the caller can gather all of those and cluster them by URL to > figure out what combinations are supported. Ugh! > > When applied at the infrastructure side this is a lot like callee > capabilities. It would be a lot simpler if you could simply enter a sip > URL *with* the capabilities as a single enum entry. But I think that is > not possible, because the output of enum is just a URL, but the sip > capabilities are represented as *header* parameters and so not part of > the URL. I'm not sure that having multiple as separate entries is such a bad thing. But if I understand it correctly, can't one have multiple enumservice types in one record? So for instance: "E2U+voicemsg+videomsg:sip". > My biggest problem is that I see phone numbers and sip urls not as > layers but simply as alternative forms of addressing the same pool of > potential callees. So I think there should be a common mechanism for any > problem that comes down to choosing among alternative targets for a > given address. Whether I call sip:pkyzivat@cisco.com or tel:+19785551881 > I still need to potential to fail over to voicemail if there is no > answer. A different mechanism based on address type is a liability. I think I share your view in general, but I don't see how that is contradictory to these drafts registering these enum services. The draft is not suggesting that you can't fail over to voicemail for a generic sip url. This is the enum wg, and by definition enum is for phone numbers. The registration database for generic sip user urls is controlled by the target user's domain's registrar, and there is no protocol defined for accessing that DB directly (well, other than diameter by some other standards groups). The method by which a proxy or registrar retrieves the end-user's capabilities or preferences from the DB is not defined, except for phone numbers through enum. Obviously having this type of info in enum allows a call flow to happen that can't for generic sip urls; for example, I can have my voicemail be hosted by a completely different domain than my mobile, and someone wanting to leave me a voicemail only, could send it directly to the other domain without sending a sip request to my mobile one to be redirected. But I don't see how that type of difference matters - by the very existence of enum, there is a different "mechanism" for phone numbers than generic sip urls. -hadriel _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 15 13:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWboL-0001OP-Rg; Sat, 15 Sep 2007 13:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWboK-0001OI-PN for enum@ietf.org; Sat, 15 Sep 2007 13:52:04 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWboJ-0007O5-35 for enum@ietf.org; Sat, 15 Sep 2007 13:52:04 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id F2EA4CA826; Sat, 15 Sep 2007 18:52:01 +0100 (BST) In-Reply-To: <002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com><0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-livingood-enum-videomsg-00 Date: Sat, 15 Sep 2007 18:51:52 +0100 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: enum@ietf.org, 'Paul Kyzivat' , "'Livingood, Jason'" , Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Howard, folks, You beat me to it. One sure can (but not quite with your syntax). For example, cell phones could WELL have a service field of "e2u+voice:tel+sms:tel". Thus in your case it would be e2u+voicemsg:sip+videomsg:sip" It works for me. For the rest of this thread, I roll my eyes. all the best, Lawrence On 15 Sep 2007, at 18:36, Hadriel Kaplan wrote: >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> As you note, the problem with this scheme is that it doesn't seem to >> provide a way to indicate a target for combinations. I guess you can >> enter the same URL several times, for: audio, video, im, rtt, etc. >> And >> then the caller can gather all of those and cluster them by URL to >> figure out what combinations are supported. Ugh! >> >> When applied at the infrastructure side this is a lot like callee >> capabilities. It would be a lot simpler if you could simply enter >> a sip >> URL *with* the capabilities as a single enum entry. But I think >> that is >> not possible, because the output of enum is just a URL, but the sip >> capabilities are represented as *header* parameters and so not >> part of >> the URL. > > I'm not sure that having multiple as separate entries is such a bad > thing. > But if I understand it correctly, can't one have multiple > enumservice types > in one record? So for instance: "E2U+voicemsg+videomsg:sip". > > >> My biggest problem is that I see phone numbers and sip urls not as >> layers but simply as alternative forms of addressing the same pool of >> potential callees. So I think there should be a common mechanism >> for any >> problem that comes down to choosing among alternative targets for a >> given address. Whether I call sip:pkyzivat@cisco.com or tel: >> +19785551881 >> I still need to potential to fail over to voicemail if there is no >> answer. A different mechanism based on address type is a liability. > > I think I share your view in general, but I don't see how that is > contradictory to these drafts registering these enum services. The > draft is > not suggesting that you can't fail over to voicemail for a generic > sip url. > This is the enum wg, and by definition enum is for phone numbers. The > registration database for generic sip user urls is controlled by > the target > user's domain's registrar, and there is no protocol defined for > accessing > that DB directly (well, other than diameter by some other standards > groups). > The method by which a proxy or registrar retrieves the end-user's > capabilities or preferences from the DB is not defined, except for > phone > numbers through enum. > > Obviously having this type of info in enum allows a call flow to > happen that > can't for generic sip urls; for example, I can have my voicemail be > hosted > by a completely different domain than my mobile, and someone > wanting to > leave me a voicemail only, could send it directly to the other domain > without sending a sip request to my mobile one to be redirected. > But I > don't see how that type of difference matters - by the very > existence of > enum, there is a different "mechanism" for phone numbers than > generic sip > urls. > > -hadriel > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 15 14:02:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbyE-0007Nk-5P; Sat, 15 Sep 2007 14:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbyD-0007Lq-OP for enum@ietf.org; Sat, 15 Sep 2007 14:02:17 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWbyC-00080o-IL for enum@ietf.org; Sat, 15 Sep 2007 14:02:17 -0400 Received: from hkaplan [75.68.59.21] by acmepacket.com with ESMTP (SMTPD-9.10) id AE24032C; Sat, 15 Sep 2007 14:02:12 -0400 From: "Hadriel Kaplan" To: "'lconroy'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com><0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com><46EB0E05.5030405@cisco.com><002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Sat, 15 Sep 2007 14:00:48 -0400 Message-ID: <002c01c7f7c2$591bf8f0$800101df@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Acf3wSQd1B5NVUUjRTmyfh3F9u/QQAAARhCA In-Reply-To: <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: enum@ietf.org, 'Paul Kyzivat' , "'Livingood, Jason'" , Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Yup, I was just about to correct myself. (after actually looking at 3761 abnf) :) -hadriel > -----Original Message----- > From: lconroy [mailto:lconroy@insensate.co.uk] > Sent: Saturday, September 15, 2007 1:52 PM > To: Hadriel Kaplan > Cc: enum@ietf.org; 'Paul Kyzivat'; 'Livingood,Jason'; > Dale.Worley@comcast.net > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > > Hi Howard, folks, > You beat me to it. > One sure can (but not quite with your syntax). > For example, cell phones could WELL have a service field of > "e2u+voice:tel+sms:tel". > Thus in your case it would be e2u+voicemsg:sip+videomsg:sip" > It works for me. > For the rest of this thread, I roll my eyes. > > all the best, > Lawrence > > > > On 15 Sep 2007, at 18:36, Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> > >> As you note, the problem with this scheme is that it doesn't seem to > >> provide a way to indicate a target for combinations. I guess you can > >> enter the same URL several times, for: audio, video, im, rtt, etc. > >> And > >> then the caller can gather all of those and cluster them by URL to > >> figure out what combinations are supported. Ugh! > >> > >> When applied at the infrastructure side this is a lot like callee > >> capabilities. It would be a lot simpler if you could simply enter > >> a sip > >> URL *with* the capabilities as a single enum entry. But I think > >> that is > >> not possible, because the output of enum is just a URL, but the sip > >> capabilities are represented as *header* parameters and so not > >> part of > >> the URL. > > > > I'm not sure that having multiple as separate entries is such a bad > > thing. > > But if I understand it correctly, can't one have multiple > > enumservice types > > in one record? So for instance: "E2U+voicemsg+videomsg:sip". > > > > > >> My biggest problem is that I see phone numbers and sip urls not as > >> layers but simply as alternative forms of addressing the same pool of > >> potential callees. So I think there should be a common mechanism > >> for any > >> problem that comes down to choosing among alternative targets for a > >> given address. Whether I call sip:pkyzivat@cisco.com or tel: > >> +19785551881 > >> I still need to potential to fail over to voicemail if there is no > >> answer. A different mechanism based on address type is a liability. > > > > I think I share your view in general, but I don't see how that is > > contradictory to these drafts registering these enum services. The > > draft is > > not suggesting that you can't fail over to voicemail for a generic > > sip url. > > This is the enum wg, and by definition enum is for phone numbers. The > > registration database for generic sip user urls is controlled by > > the target > > user's domain's registrar, and there is no protocol defined for > > accessing > > that DB directly (well, other than diameter by some other standards > > groups). > > The method by which a proxy or registrar retrieves the end-user's > > capabilities or preferences from the DB is not defined, except for > > phone > > numbers through enum. > > > > Obviously having this type of info in enum allows a call flow to > > happen that > > can't for generic sip urls; for example, I can have my voicemail be > > hosted > > by a completely different domain than my mobile, and someone > > wanting to > > leave me a voicemail only, could send it directly to the other domain > > without sending a sip request to my mobile one to be redirected. > > But I > > don't see how that type of difference matters - by the very > > existence of > > enum, there is a different "mechanism" for phone numbers than > > generic sip > > urls. > > > > -hadriel > > > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Sat Sep 15 14:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbzR-0002v6-BS; Sat, 15 Sep 2007 14:03:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWbzP-0002ux-6S for enum@ietf.org; Sat, 15 Sep 2007 14:03:31 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWbzN-0005Vu-WB for enum@ietf.org; Sat, 15 Sep 2007 14:03:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Enum] draft-livingood-enum-videomsg-00 Date: Sat, 15 Sep 2007 20:03:45 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1E20@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf3IFKXm8jbVmDOTmqP0TCAtb4m7wAh+JBAAAY13T4= References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <040e01c7f7a8$e9042d80$bb0c8880$@us> From: "Stastny Richard" To: "Richard Shockey" X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: enum@ietf.org, "Livingood,Jason" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi all, =20 following this discussion, I have a serious problem that we are ever be = able=20 to create a document for ENUM service registrations and to close this WG I just remember "unused" (and others), which is still in linbo. =20 An ENUM service shall describe the mapping of a E.164 number to=20 a URI. period =20 Is there any shortage in alphanumeric strings that we have to consider? =20 IMHO everybody should be able to describe such a mapping - the = usefulness will be shown in practice. =20 A client need not to understand all enumservices defined, only yhe one = it may be able to use =20 There is alo ne need to define if an enumservice is to be used in user = ENUM or infrastructure ENUM, this will also shown in practice =20 So we should step on or two steps back and simply allow ENUM services to be defined, they should be checked only if the are correctly defined. The usefulness will be shown in practice =20 regards Richard ________________________________ Von: Richard Shockey [mailto:richard@shockey.us] Gesendet: Sa 15.09.2007 16:58 An: 'Paul Kyzivat'; 'Brian Rosen' Cc: enum@ietf.org; Dale.Worley@comcast.net; 'Livingood,Jason' Betreff: RE: [Enum] draft-livingood-enum-videomsg-00 Paul this discussion is excellent but you have not answered my practical question of what are, if any, the policies the IETF should have = regarding what strings should or should not be Enumservice registrations. Should = we have a separate ones for user vs infrastructure or just let 10,000 = flowers bloom .. You are dancing around the issue without confronting it. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, September 14, 2007 6:41 PM > To: Brian Rosen > Cc: enum@ietf.org; 'Livingood, Jason'; Dale.Worley@comcast.net > Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >=20 > Brian, >=20 > You and I are on the same page here! >=20 > Who chooses depends on whether this is user enum or infrastructure > enum > I guess. If its infrastructure enum used at the terminating side then > the policies are recipient policies. But because the data is coming > from > enum, it seems likely that it will have to be the same policy for all > of > the provider's subscribers. >=20 > If its user enum, then it is the caller that is choosing. I guess = that > is ok, if the user decided to put all that stuff in there for the > caller > to choose from. >=20 > As you note, the problem with this scheme is that it doesn't seem to > provide a way to indicate a target for combinations. I guess you can > enter the same URL several times, for: audio, video, im, rtt, etc. = And > then the caller can gather all of those and cluster them by URL to > figure out what combinations are supported. Ugh! >=20 > When applied at the infrastructure side this is a lot like callee > capabilities. It would be a lot simpler if you could simply enter a > sip > URL *with* the capabilities as a single enum entry. But I think that > is > not possible, because the output of enum is just a URL, but the sip > capabilities are represented as *header* parameters and so not part = of > the URL. >=20 > When applied at the user enum side, this is a lot like presence. >=20 > My biggest problem is that I see phone numbers and sip urls not as > layers but simply as alternative forms of addressing the same pool of > potential callees. So I think there should be a common mechanism for > any > problem that comes down to choosing among alternative targets for a > given address. Whether I call sip:pkyzivat@cisco.com or > tel:+19785551881 > I still need to potential to fail over to voicemail if there is no > answer. A different mechanism based on address type is a liability. >=20 > Paul >=20 > Brian Rosen wrote: > > Yeah, and we need another enum service or two if we're > differentiating voice > > from video. > > > > Which, I think, is pretty ridiculous, but if we're going down that > path, > > then we need one for every possible kind of media. > > > > What do you do if you offer video+audio+real time text+im? In > particular, > > is it the origination network that decides what mailbox service you > get or > > the termination side? If it's done with enum, then it's the > origination > > side, which makes the enum dip to route the call, that decides. > > > > That means the recipient, who has all of these services, doesn't > decide how > > they are used, other than possibly controlling what services are > advertised > > in the enum zone. > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Friday, September 14, 2007 4:19 PM > >> To: Brian Rosen > >> Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; > >> 'Livingood, Jason' > >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 > >> > >> > >> > >> Brian Rosen wrote: > >>>>> It would seem logical that character by character text or > >>>>> message by message text is irrelevant when leaving a message. > >>>> This was the point I meant. > >>>> > >>>>> But it > >>>>> does matter if the caller's device only supports one of them, = or > if > >>>>> the > >>>>> device of the callee when retrieving the message only supports > one. > >>>> Now, you are diverging: we should separate message deposit from > message > >>>> retrieval and how the latter is linked with device capabilities > should > >>>> not necessarily impact how the former is made possible. > >>> I think you have a problem here anyway. > >>> > >>> If I'm a deaf caller and I send an INVITE with a real-time text > codec, > >> and > >>> the call gets diverted to a text-mail system, then are you > expecting the > >>> offer to be refused, and the answer to only supply message-at-a- > time > >>> options? > >>> > >>> What if I have different clients for IM then real-time text? > >> Yeah, this is what I was getting at. > >> > >> From a practical perspective it probably does make sense for the > RTT > >> devices to also support IM, because there will be lots of cases > where an > >> IM call is the only alternative to no call, even if the RTT is > >> preferred. Such devices would preferably always offer both in = order > to > >> maximize the chances of call success. Also, it seems like it would > be > >> quite straightforward for a UI that supports RTT to also support > IM. > >> > >> But that doesn't mean that is what will get deployed. If any RTT > devices > >> without IM support get out there, then I imagine there would = strong > >> pushes for answering systems to support them. > >> > >> Even if every device that supports RTT also supports IM, that = would > at > >> least drive a demand that answering systems that support voice > support > >> either RTT or IM or both. > >> > >> Paul > > >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 10:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHgk-0008PW-Hh; Mon, 17 Sep 2007 10:35:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHgi-0008PG-OZ for enum@ietf.org; Mon, 17 Sep 2007 10:35:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXHgh-0007zy-Vm for enum@ietf.org; Mon, 17 Sep 2007 10:35:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Sep 2007 10:35:00 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8HEYx4R015133; Mon, 17 Sep 2007 10:34:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8HEYO3L016847; Mon, 17 Sep 2007 14:34:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 10:34:24 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 10:34:23 -0400 Message-ID: <46EE906E.9050904@cisco.com> Date: Mon, 17 Sep 2007 10:34:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Shockey Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <040e01c7f7a8$e9042d80$bb0c8880$@us> In-Reply-To: <040e01c7f7a8$e9042d80$bb0c8880$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2007 14:34:24.0026 (UTC) FILETIME=[D7AC4FA0:01C7F937] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6498; t=1190039699; x=1190903699; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20 |To:=20Richard=20Shockey=20; bh=j4PnRobK2V0OpikCt0Zkn5ZD+btvVt0vI+UOs/XyvuY=; b=j3rk6HtduWlETRKyFGfaHlO3/xGzpNdAZgxWQSSdNt9mf6MAoBGUDcqinLCl+ltK8Ob/+a9j 1HqhvQvqbl8al6WhQ5wnES9/7F9S+atG6FlSMth8KTJYRBtxaQGph8SH; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Richard Shockey wrote: > Paul this discussion is excellent but you have not answered my practical > question of what are, if any, the policies the IETF should have regarding > what strings should or should not be Enumservice registrations. Should we > have a separate ones for user vs infrastructure or just let 10,000 flowers > bloom .. Well, with some misgivings, I guess I must go with letting some 10s of flowers bloom. (We are in big trouble if there O(10k) of these things. I don't think DNS can deal with that.) I think the problems I have here are not with *defining* these usages. The problem is with proper use (and non-use) of them. I don't see any way to deal with that here. Paul > You are dancing around the issue without confronting it. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, September 14, 2007 6:41 PM >> To: Brian Rosen >> Cc: enum@ietf.org; 'Livingood, Jason'; Dale.Worley@comcast.net >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >> >> Brian, >> >> You and I are on the same page here! >> >> Who chooses depends on whether this is user enum or infrastructure >> enum >> I guess. If its infrastructure enum used at the terminating side then >> the policies are recipient policies. But because the data is coming >> from >> enum, it seems likely that it will have to be the same policy for all >> of >> the provider's subscribers. >> >> If its user enum, then it is the caller that is choosing. I guess that >> is ok, if the user decided to put all that stuff in there for the >> caller >> to choose from. >> >> As you note, the problem with this scheme is that it doesn't seem to >> provide a way to indicate a target for combinations. I guess you can >> enter the same URL several times, for: audio, video, im, rtt, etc. And >> then the caller can gather all of those and cluster them by URL to >> figure out what combinations are supported. Ugh! >> >> When applied at the infrastructure side this is a lot like callee >> capabilities. It would be a lot simpler if you could simply enter a >> sip >> URL *with* the capabilities as a single enum entry. But I think that >> is >> not possible, because the output of enum is just a URL, but the sip >> capabilities are represented as *header* parameters and so not part of >> the URL. >> >> When applied at the user enum side, this is a lot like presence. >> >> My biggest problem is that I see phone numbers and sip urls not as >> layers but simply as alternative forms of addressing the same pool of >> potential callees. So I think there should be a common mechanism for >> any >> problem that comes down to choosing among alternative targets for a >> given address. Whether I call sip:pkyzivat@cisco.com or >> tel:+19785551881 >> I still need to potential to fail over to voicemail if there is no >> answer. A different mechanism based on address type is a liability. >> >> Paul >> >> Brian Rosen wrote: >> > Yeah, and we need another enum service or two if we're >> differentiating voice >> > from video. >> > >> > Which, I think, is pretty ridiculous, but if we're going down that >> path, >> > then we need one for every possible kind of media. >> > >> > What do you do if you offer video+audio+real time text+im? In >> particular, >> > is it the origination network that decides what mailbox service you >> get or >> > the termination side? If it's done with enum, then it's the >> origination >> > side, which makes the enum dip to route the call, that decides. >> > >> > That means the recipient, who has all of these services, doesn't >> decide how >> > they are used, other than possibly controlling what services are >> advertised >> > in the enum zone. >> > >> >> -----Original Message----- >> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> Sent: Friday, September 14, 2007 4:19 PM >> >> To: Brian Rosen >> >> Cc: 'Jean-Francois Mule'; enum@ietf.org; Dale.Worley@comcast.net; >> >> 'Livingood, Jason' >> >> Subject: Re: [Enum] draft-livingood-enum-videomsg-00 >> >> >> >> >> >> >> >> Brian Rosen wrote: >> >>>>> It would seem logical that character by character text or >> >>>>> message by message text is irrelevant when leaving a message. >> >>>> This was the point I meant. >> >>>> >> >>>>> But it >> >>>>> does matter if the caller's device only supports one of them, or >> if >> >>>>> the >> >>>>> device of the callee when retrieving the message only supports >> one. >> >>>> Now, you are diverging: we should separate message deposit from >> message >> >>>> retrieval and how the latter is linked with device capabilities >> should >> >>>> not necessarily impact how the former is made possible. >> >>> I think you have a problem here anyway. >> >>> >> >>> If I'm a deaf caller and I send an INVITE with a real-time text >> codec, >> >> and >> >>> the call gets diverted to a text-mail system, then are you >> expecting the >> >>> offer to be refused, and the answer to only supply message-at-a- >> time >> >>> options? >> >>> >> >>> What if I have different clients for IM then real-time text? >> >> Yeah, this is what I was getting at. >> >> >> >> From a practical perspective it probably does make sense for the >> RTT >> >> devices to also support IM, because there will be lots of cases >> where an >> >> IM call is the only alternative to no call, even if the RTT is >> >> preferred. Such devices would preferably always offer both in order >> to >> >> maximize the chances of call success. Also, it seems like it would >> be >> >> quite straightforward for a UI that supports RTT to also support >> IM. >> >> >> >> But that doesn't mean that is what will get deployed. If any RTT >> devices >> >> without IM support get out there, then I imagine there would strong >> >> pushes for answering systems to support them. >> >> >> >> Even if every device that supports RTT also supports IM, that would >> at >> >> least drive a demand that answering systems that support voice >> support >> >> either RTT or IM or both. >> >> >> >> Paul >> > >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 10:40:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHm1-00062w-Tw; Mon, 17 Sep 2007 10:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXHm0-0005zE-6r for enum@ietf.org; Mon, 17 Sep 2007 10:40:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXHly-0005UT-SV for enum@ietf.org; Mon, 17 Sep 2007 10:40:28 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Sep 2007 10:40:26 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8HEeQhi010835; Mon, 17 Sep 2007 10:40:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8HEdh3N019605; Mon, 17 Sep 2007 14:40:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 10:39:57 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 10:39:57 -0400 Message-ID: <46EE91BB.4040705@cisco.com> Date: Mon, 17 Sep 2007 10:39:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com><0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> In-Reply-To: <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2007 14:39:57.0189 (UTC) FILETIME=[9E40F350:01C7F938] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4111; t=1190040026; x=1190904026; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20 |To:=20lconroy=20; bh=sCD4FPjhUWlHBeWMmBB5ef/tMornTVFTZ1tvkP9blLA=; b=UiVZMwqt+Oy6iW0X5BP/Vd6rPPPTxBaMoSkoQizzyjwQ0kdnziOxYJzmNZxjS+a8738O5jiY eDGxUTV0IqWMqxRd8JgJcCUR7L5cLqqqBO+x4FxUidt1GTc7Ohd6jzii; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" , Hadriel Kaplan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi Howard, folks, > You beat me to it. > One sure can (but not quite with your syntax). > For example, cell phones could WELL have a service field of > "e2u+voice:tel+sms:tel". > Thus in your case it would be e2u+voicemsg:sip+videomsg:sip" > It works for me. Interesting. That makes this a lot more like callee capabilities, though it is limited to binary feature tags. I'll just warn you that having started down that path, you may find it to be the same slippery slope that callerprefs became. The initial draft of callerprefs was very simple - naively so. It became the mess that it ended up by trying to remove ambiguity and cover the cases that were thought to be within its scope. Paul > For the rest of this thread, I roll my eyes. > > all the best, > Lawrence > > > > On 15 Sep 2007, at 18:36, Hadriel Kaplan wrote: >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> >>> As you note, the problem with this scheme is that it doesn't seem to >>> provide a way to indicate a target for combinations. I guess you can >>> enter the same URL several times, for: audio, video, im, rtt, etc. And >>> then the caller can gather all of those and cluster them by URL to >>> figure out what combinations are supported. Ugh! >>> >>> When applied at the infrastructure side this is a lot like callee >>> capabilities. It would be a lot simpler if you could simply enter a sip >>> URL *with* the capabilities as a single enum entry. But I think that is >>> not possible, because the output of enum is just a URL, but the sip >>> capabilities are represented as *header* parameters and so not part of >>> the URL. >> >> I'm not sure that having multiple as separate entries is such a bad >> thing. >> But if I understand it correctly, can't one have multiple enumservice >> types >> in one record? So for instance: "E2U+voicemsg+videomsg:sip". >> >> >>> My biggest problem is that I see phone numbers and sip urls not as >>> layers but simply as alternative forms of addressing the same pool of >>> potential callees. So I think there should be a common mechanism for any >>> problem that comes down to choosing among alternative targets for a >>> given address. Whether I call sip:pkyzivat@cisco.com or tel:+19785551881 >>> I still need to potential to fail over to voicemail if there is no >>> answer. A different mechanism based on address type is a liability. >> >> I think I share your view in general, but I don't see how that is >> contradictory to these drafts registering these enum services. The >> draft is >> not suggesting that you can't fail over to voicemail for a generic sip >> url. >> This is the enum wg, and by definition enum is for phone numbers. The >> registration database for generic sip user urls is controlled by the >> target >> user's domain's registrar, and there is no protocol defined for accessing >> that DB directly (well, other than diameter by some other standards >> groups). >> The method by which a proxy or registrar retrieves the end-user's >> capabilities or preferences from the DB is not defined, except for phone >> numbers through enum. >> >> Obviously having this type of info in enum allows a call flow to >> happen that >> can't for generic sip urls; for example, I can have my voicemail be >> hosted >> by a completely different domain than my mobile, and someone wanting to >> leave me a voicemail only, could send it directly to the other domain >> without sending a sip request to my mobile one to be redirected. But I >> don't see how that type of difference matters - by the very existence of >> enum, there is a different "mechanism" for phone numbers than generic sip >> urls. >> >> -hadriel >> >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 16:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMiQ-0007yG-QR; Mon, 17 Sep 2007 15:57:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMiP-0007yB-SF for enum@ietf.org; Mon, 17 Sep 2007 15:57:05 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXMiP-0002N0-FR for enum@ietf.org; Mon, 17 Sep 2007 15:57:05 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8HJuSvo015725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Sep 2007 12:56:29 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'lconroy'" References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com><0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> <46EE91BB.4040705@cisco.com> In-Reply-To: <46EE91BB.4040705@cisco.com> Date: Mon, 17 Sep 2007 15:56:19 -0400 Message-ID: <00a901c7f964$d5bb82b0$81328810$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acf5OKje1Xc7+ThEQ+eGb/qPiE37EAAK0MRA Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: enum@ietf.org, Dale.Worley@comcast.net, "'Livingood, Jason'" , 'Hadriel Kaplan' Subject: [Enum] In scope for ENUM - draft-livingood-enum-videomsg-voicemsg X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Well as for the slippery slope ..I guess we will all need a toboggan. There is sufficient evidence here to have these documents ruled in scope. Barring any further strong objections, it is the view of the chairs that there is rough consensus that these should be ENUM WG documents. I'd suggest that the two be combined into one document since the are sufficiently related. > > I'll just warn you that having started down that path, you may find it > to be the same slippery slope that callerprefs became. The initial > draft > of callerprefs was very simple - naively so. It became the mess that > it > ended up by trying to remove ambiguity and cover the cases that were > thought to be within its scope. > > Paul > > > For the rest of this thread, I roll my eyes. > > > > all the best, > > Lawrence > > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 16:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMrX-0007rF-SE; Mon, 17 Sep 2007 16:06:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXMrW-0007r0-AM for enum@ietf.org; Mon, 17 Sep 2007 16:06:30 -0400 Received: from smtp.denic.de ([81.91.161.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXMrV-0002hw-Uz for enum@ietf.org; Mon, 17 Sep 2007 16:06:30 -0400 Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1IXMrU-0004mg-RB; Mon, 17 Sep 2007 22:06:28 +0200 Received: from localhost by mail-int1.denic.de with local id 1IXMrU-0003wJ-00; Mon, 17 Sep 2007 22:06:28 +0200 Date: Mon, 17 Sep 2007 22:06:28 +0200 From: Peter Koch To: IETF ENUM WG Subject: Re: [Enum] draft-livingood-enum-videomsg-00 Message-ID: <20070917200628.GK9940@denics7.denic.de> Mail-Followup-To: IETF ENUM WG References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <040e01c7f7a8$e9042d80$bb0c8880$@us> <32755D354E6B65498C3BD9FD496C7D466B1E20@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1E20@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org On Sat, Sep 15, 2007 at 08:03:45PM +0200, Stastny Richard wrote: > Is there any shortage in alphanumeric strings that we have to consider? no, but that's also true for, say, email header fields or media types. Still, interoperability is key here and having multiple competing service types for similar or identical uses does not provide for enough guidance for implementors and operators/users. Even more so as long as all these services finally end up as Proposed Standards. -Peter _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 17:21:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNz8-0002sm-8l; Mon, 17 Sep 2007 17:18:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNz7-0002hz-2o for enum@ietf.org; Mon, 17 Sep 2007 17:18:25 -0400 Received: from alnrmhc11.comcast.net ([204.127.225.91]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXNyu-0004aZ-Kr for enum@ietf.org; Mon, 17 Sep 2007 17:18:12 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070917211811b1100oibbpe>; Mon, 17 Sep 2007 21:18:11 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l8HLIB4p026701 for ; Mon, 17 Sep 2007 17:18:11 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l8HLIBve026697; Mon, 17 Sep 2007 17:18:11 -0400 Date: Mon, 17 Sep 2007 17:18:11 -0400 Message-Id: <200709172118.l8HLIBve026697@dragon.ariadne.com> From: Dale.Worley@comcast.net To: enum@ietf.org In-reply-to: <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> (jf.mule@cablelabs.com) Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org From: "Jean-Francois Mule" Another example is one where Alice wants to leave a video msg to Bob and Bob's mobile does not support video but he has configured his user profile to accept video messages on his PVR at home. In this case, media negotiations would only result in voice and not allow the caller preference for video (or it might if ...). Why would media negotiations only result in voice messaging? If the original INVITE (specifying both voice and video) is forked to the messaging service, the messaging service would know that video was desired. IMHO, the whole concept of listing messaging services separately in Enum is ill-advised. SIP has done a great deal of work to allow distributed selection among a dynamic, prioritized set of recipients with varying capabilities. Trying to force that choice onto the originating UA at the *start* of the call is just going to make it work worse. Listing voice and video messaging *separately* in Enum (and so requiring that any other type of messaging must further be listed separately) just amplifies these failure modes. Dale _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 18:09:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXOjk-0007pq-4a; Mon, 17 Sep 2007 18:06:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXOjj-0007pl-GL for enum@ietf.org; Mon, 17 Sep 2007 18:06:35 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXOji-0005V6-K2 for enum@ietf.org; Mon, 17 Sep 2007 18:06:35 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 865D9CAD4A; Mon, 17 Sep 2007 23:06:31 +0100 (BST) In-Reply-To: <200709172118.l8HLIBve026697@dragon.ariadne.com> References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> <200709172118.l8HLIBve026697@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10DF346C-2623-4BC4-BBB6-F9D789174D4E@insensate.co.uk> Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-livingood-enum-videomsg-00 Date: Mon, 17 Sep 2007 23:06:23 +0100 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: enum WG , Paul Kyzivat , Jason Livingood , Hadriel Kaplan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Dale, folks, Frankly, I have been waiting for this thread to wither so we can deal with the few typos in the documents and get some clarification. Just when you thought it was safe to go out on the streets... I understand the concerns over slopes, but this is the ENUM WG, not SIP. Nor is it SIPPING (we have SPEERMINT for that). I like these drafts. I concur that these are dead on appropriate for ENUM. If you want full blown IMS with all of the service features that entails, then the SIP Enumservice is fine. You get what the IMS provider offers. In this case, however... The use cases in the docs are more detailed than I think is needed, but being able to indicate that this contact will get you to a server that will allow you to leave a message (or to retrieve messages left for you) is precisely what ENUM publication is about. It is a specific kind of human interaction. Do I think this is a worthy service, likely to be of widespread use and widely understood? Absolutely. I don't think this is a waste of a string and IANA's time in making a registration. I for one would dearly like this service to be available - I know how to use it to fire up any of my minimal dumb SIP clients to do what I want to do. If the registrant publishes the information, it's my choice whether to use it or another or give up and use none of them. Oh, and I can do that right now, with pretty much any 3261 compliant UAC. Heck, an old 2543-compliant UAC will do. To suggest that SIP can do everything may be true. To suggest that this means that there is no need for any indication that this particular URI will get you to this kind of B2BUA that is providing this kind of service is horse feathers. The real question for the ENUM WG is: Can I, as an implementer, understand what will happen if I follow this URI? From these drafts, do I know what kind of teleservice I will get if I use a NAPTR with these service fields? I think, for voicemsg, the answer is undoubtedly yes. The use cases indicate that this is going to get you to a B2BUA that provides a very specific service. For videomsg, I think so (at least for videomsg:sip). I'm not completely sure for videomsg:tel. You may notice that we left out video:tel from the voice:tel RFC (it was there in the earlier vovi drafts) - that was to avoid having to specify exactly WHAT kind of interface would be used. However, that discussion will have to wait for the next round of the draft(s) as a WG item. For now, we return you to your normal station. all the best, Lawrence On 17 Sep 2007, at 22:18, Dale.Worley@comcast.net wrote: > From: "Jean-Francois Mule" > > Another example is one where Alice wants to leave a video msg to > Bob and > Bob's mobile does not support video but he has configured his user > profile to accept video messages on his PVR at home. In this > case, media > negotiations would only result in voice and not allow the caller > preference for video (or it might if ...). > > Why would media negotiations only result in voice messaging? If the > original INVITE (specifying both voice and video) is forked to the > messaging service, the messaging service would know that video was > desired. > > IMHO, the whole concept of listing messaging services separately in > Enum is ill-advised. SIP has done a great deal of work to allow > distributed selection among a dynamic, prioritized set of recipients > with varying capabilities. Trying to force that choice onto the > originating UA at the *start* of the call is just going to make it > work worse. > > Listing voice and video messaging *separately* in Enum (and so > requiring that any other type of messaging must further be listed > separately) just amplifies these failure modes. > > Dale > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 18:52:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXPNz-0002p8-Cn; Mon, 17 Sep 2007 18:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXPNy-0002p3-6g for enum@ietf.org; Mon, 17 Sep 2007 18:48:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXPNr-0004IN-Nk for enum@ietf.org; Mon, 17 Sep 2007 18:48:10 -0400 X-IronPort-AV: E=Sophos;i="4.20,266,1186383600"; d="scan'208";a="524856857" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 17 Sep 2007 15:47:39 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8HMldTx031342; Mon, 17 Sep 2007 15:47:39 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8HMlTfF012818; Mon, 17 Sep 2007 22:47:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 18:47:30 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 18:47:29 -0400 Message-ID: <46EF0401.6070608@cisco.com> Date: Mon, 17 Sep 2007 18:47:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> <200709172118.l8HLIBve026697@dragon.ariadne.com> <10DF346C-2623-4BC4-BBB6-F9D789174D4E@insensate.co.uk> In-Reply-To: <10DF346C-2623-4BC4-BBB6-F9D789174D4E@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Sep 2007 22:47:29.0682 (UTC) FILETIME=[BA192720:01C7F97C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4509; t=1190069259; x=1190933259; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20; bh=7jg8oO6xNeP/zmw/oo9kcOmfmOVCC6n0jZU+tuG5ZOs=; b=SkiWabGTTkmWOMvhmQepV4myWIPxAuWG79O+EMa+cih6uXC9cUoJiQMSEE8wvwMXjzhuUYEt spfuoz3suup6HfflDGF3r91vAJ5lI7ZP6fnDPWakpfRvRSuu//isPPymAKBAaVcBZ7jfN5kC2q w0B3KEp6NSGLKtQBd7AD28JY0=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: enum WG , Dale.Worley@comcast.net, Jason Livingood , Hadriel Kaplan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org lconroy wrote: > Hi Dale, folks, > Frankly, I have been waiting for this thread to wither so we can deal > with the few typos in the documents and get some clarification. > Just when you thought it was safe to go out on the streets... > > I understand the concerns over slopes, but this is the ENUM WG, not SIP. > Nor is it SIPPING (we have SPEERMINT for that). > > I like these drafts. > I concur that these are dead on appropriate for ENUM. > > If you want full blown IMS with all of the service features that entails, > then the SIP Enumservice is fine. You get what the IMS provider offers. > > In this case, however... > The use cases in the docs are more detailed than I think is needed, but > being able to indicate that this contact will get you to a server that > will allow you to leave a message (or to retrieve messages left for you) > is precisely what ENUM publication is about. It is a specific kind of > human interaction. > > Do I think this is a worthy service, likely to be of widespread use and > widely understood? Absolutely. I don't think this is a waste of a string > and IANA's time in making a registration. > > I for one would dearly like this service to be available - I know how to > use > it to fire up any of my minimal dumb SIP clients to do what I want to do. > If the registrant publishes the information, it's my choice whether to > use it > or another or give up and use none of them. > Oh, and I can do that right now, with pretty much any 3261 compliant UAC. > Heck, an old 2543-compliant UAC will do. I appreciate your point of view. But I'm not sure I understand your usage model. It sounds like you have UAs that are enum clients and give the user an interface to user enum - offering the choices. Is that right? It doesn't seem like something that your average UA provides. Paul > To suggest that SIP can do everything may be true. To suggest that this > means that there is no need for any indication that this particular URI > will get you to this kind of B2BUA that is providing this kind of service > is horse feathers. > > The real question for the ENUM WG is: > > Can I, as an implementer, understand what will happen if I follow this > URI? > From these drafts, do I know what kind of teleservice I will get if I > use a > NAPTR with these service fields? > > I think, for voicemsg, the answer is undoubtedly yes. The use cases > indicate > that this is going to get you to a B2BUA that provides a very specific > service. > > For videomsg, I think so (at least for videomsg:sip). > I'm not completely sure for videomsg:tel. You may notice that we left out > video:tel from the voice:tel RFC (it was there in the earlier vovi drafts) > - that was to avoid having to specify exactly WHAT kind of interface would > be used. > > However, that discussion will have to wait for the next round of the > draft(s) as a WG item. For now, we return you to your normal station. > > all the best, > Lawrence > > On 17 Sep 2007, at 22:18, Dale.Worley@comcast.net wrote: >> From: "Jean-Francois Mule" >> >> Another example is one where Alice wants to leave a video msg to >> Bob and >> Bob's mobile does not support video but he has configured his user >> profile to accept video messages on his PVR at home. In this case, >> media >> negotiations would only result in voice and not allow the caller >> preference for video (or it might if ...). >> >> Why would media negotiations only result in voice messaging? If the >> original INVITE (specifying both voice and video) is forked to the >> messaging service, the messaging service would know that video was >> desired. >> >> IMHO, the whole concept of listing messaging services separately in >> Enum is ill-advised. SIP has done a great deal of work to allow >> distributed selection among a dynamic, prioritized set of recipients >> with varying capabilities. Trying to force that choice onto the >> originating UA at the *start* of the call is just going to make it >> work worse. >> >> Listing voice and video messaging *separately* in Enum (and so >> requiring that any other type of messaging must further be listed >> separately) just amplifies these failure modes. >> >> Dale >> >> _______________________________________________ >> enum mailing list >> enum@ietf.org >> https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 20:25:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXQoY-0004e1-GM; Mon, 17 Sep 2007 20:19:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXQoX-0004dr-9R for enum@ietf.org; Mon, 17 Sep 2007 20:19:41 -0400 Received: from norman.insensate.co.uk ([213.152.49.123] helo=insensate.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXQoW-0001ki-Mk for enum@ietf.org; Mon, 17 Sep 2007 20:19:41 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 07068CAE1F; Tue, 18 Sep 2007 01:19:40 +0100 (BST) In-Reply-To: <46EF0401.6070608@cisco.com> References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> <200709172118.l8HLIBve026697@dragon.ariadne.com> <10DF346C-2623-4BC4-BBB6-F9D789174D4E@insensate.co.uk> <46EF0401.6070608@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: lconroy Subject: Re: [Enum] draft-livingood-enum-videomsg-00 Date: Tue, 18 Sep 2007 01:19:32 +0100 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: enum WG , Dale.Worley@comcast.net, Jason Livingood , Hadriel Kaplan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Hi Paul, folks, First, an admission: I hate being bounced to a voicemail service without warning. Most of my phone minutes are spent two seconds at a time clearing when I get to VM. Conversely, there are times where I WANT to leave a VM and NOT to disturb the destination/callee in a meeting or in the middle of the night. Yup - having an ENUM client that displays the choices, and that fires up comms programs as needed when a choice is selected by the user, is certainly one way to go. We have an ENUM client program on PCs, Macs, and mobile phones that does just this. In that case, the SIP UAS is just a program, as is Skype, as is ... There are other options - I would love a comms program that uses just this Enumservice to know my usual dislike of unintended VM, and never try another option if the main SIP (or voice:tel) one failed, or, as the mood takes me, go straight to leaving a VM (especially when the person I'm trying to call is asleep at 3AM their time). As a customer, I'd like an ENUM-aware comms service that did this for me (they don't, but they could). That's another option. Oh, and my head hurts trying to work out the caller/callee prefs *provisioning* and use on both sides for VM - ENUM is way easier and covers my simple needs. Beyond that, how or if this NAPTR is used is a local choice, and so out of scope for ENUM. As long as it's clear how to advertise the feature, and it's clear what is expected to happen if you select the URI, we're done. all the best, Lawrence On 17 Sep 2007, at 23:47, Paul Kyzivat wrote: > lconroy wrote: >> I for one would dearly like this service to be available - I know >> how to use >> it to fire up any of my minimal dumb SIP clients to do what I want >> to do. >> If the registrant publishes the information, it's my choice >> whether to use it >> or another or give up and use none of them. >> Oh, and I can do that right now, with pretty much any 3261 >> compliant UAC. >> Heck, an old 2543-compliant UAC will do. > > I appreciate your point of view. But I'm not sure I understand your > usage model. > It sounds like you have UAs that are enum clients and give the user > an interface to user enum - offering the choices. Is that right? It > doesn't seem like something that your average UA provides. > > Paul _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 17 23:33:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXTdc-0004lK-Qn; Mon, 17 Sep 2007 23:20:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXTdb-0004lA-5i for enum@ietf.org; Mon, 17 Sep 2007 23:20:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXTda-0005my-Gj for enum@ietf.org; Mon, 17 Sep 2007 23:20:35 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Sep 2007 23:20:34 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8I3KY81008569; Mon, 17 Sep 2007 23:20:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8I3KRci000968; Tue, 18 Sep 2007 03:20:27 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 23:20:27 -0400 Received: from [10.86.241.89] ([10.86.241.89]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 23:20:26 -0400 Message-ID: <46EF43F7.1060904@cisco.com> Date: Mon, 17 Sep 2007 23:20:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: lconroy Subject: Re: [Enum] draft-livingood-enum-videomsg-00 References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com> <46E9A23B.9060908@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com> <200709172118.l8HLIBve026697@dragon.ariadne.com> <10DF346C-2623-4BC4-BBB6-F9D789174D4E@insensate.co.uk> <46EF0401.6070608@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Sep 2007 03:20:26.0104 (UTC) FILETIME=[DB34D780:01C7F9A2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4453; t=1190085634; x=1190949634; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Enum]=20draft-livingood-enum-videomsg-00 |Sender:=20 |To:=20lconroy=20; bh=n7LmUQnxXuKzdoCG9Cqezyh/8o4bjcqJS+cItu9OXgo=; b=eqCjzm2/jA/+Y/3OThdiNUlVIpJL57UEuuXplYkOBv9gLGV8vRo+XDPWnKIHr0hdf6nF4fEU A6TbhNuR3p6rLdZL/ZnMvsc8Hrr2yWIoT6CR/ueOTSOrxb66Yl3hfQGl; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: enum WG , Dale.Worley@comcast.net, Jason Livingood , Hadriel Kaplan X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Lawrence, I also hate being bounced to VM, and conversely would sometimes like to go direct to VM. You will note that there are use cases for these in the callerprefs usecases RFC. We haven't got much dialing by SIP URI yet, at least for any signficant percentage of voice calls. But I certainly expect that to change eventually. I hope sooner rather than later. We are rapidly getting devices that are alphanumeric capable, and that generally dial from stored addresses rather than entered addresses. Mnemonic names seem far preferable in the long term. That is why I would like to see the same mechanism for alternatives regardless of whether the address is E.164 or not. More inline. lconroy wrote: > Hi Paul, folks, > First, an admission: I hate being bounced to a voicemail service > without warning. Most of my phone minutes are spent two seconds > at a time clearing when I get to VM. > Conversely, there are times where I WANT to leave a VM and NOT > to disturb the destination/callee in a meeting or in the middle > of the night. > > Yup - having an ENUM client that displays the choices, and that > fires up comms programs as needed when a choice is selected by > the user, is certainly one way to go. We have an ENUM client > program on PCs, Macs, and mobile phones that does just this. > In that case, the SIP UAS is just a program, as is Skype, as is ... > > There are other options - > I would love a comms program that uses just this Enumservice to > know my usual dislike of unintended VM, and never try another > option if the main SIP (or voice:tel) one failed, or, as the > mood takes me, go straight to leaving a VM (especially when > the person I'm trying to call is asleep at 3AM their time). This of course depends on user enum. At least you seem to have that. It seems the SPs here in +1 that will never be. (I expect SPs don't want it.) > As a customer, I'd like an ENUM-aware comms service that did > this for me (they don't, but they could). That's another option. > > Oh, and my head hurts trying to work out the caller/callee prefs > *provisioning* and use on both sides for VM - ENUM is way easier > and covers my simple needs. It is true that callerprefs is too hard for simple use. It certainly makes no sense for human callers to explicitly specify their preferences anything like callerprefs specifies it. In reality, the enum stuff is much more like presence, in that it is published by/for the UAS, and made available to the caller before he initiates a call. Presence *can* expose multiple contacts and the attributes of each. But all the details are different. I guess I can see how a UAC could hide the differences under the covers - using presence for non-e.164 addresses and for e.164 addresses that have it, and enum for e.164 addresses without presence. For this to work well it will require some notion of public presence, rather than just presence for buddies. As I have said - I recognize the problems with callerprefs, and so don't see it as a major part of a solution here. But I do think having a consistent approach for both kinds of addresses is important. It would be good to have a discussion about the role of presence here - if others see that as a solution. Thanks, Paul > Beyond that, how or if this NAPTR is used is a local choice, > and so out of scope for ENUM. As long as it's clear how to > advertise the feature, and it's clear what is expected to > happen if you select the URI, we're done. > > all the best, > Lawrence > > > On 17 Sep 2007, at 23:47, Paul Kyzivat wrote: >> lconroy wrote: >>> I for one would dearly like this service to be available - I know how >>> to use >>> it to fire up any of my minimal dumb SIP clients to do what I want to >>> do. >>> If the registrant publishes the information, it's my choice whether >>> to use it >>> or another or give up and use none of them. >>> Oh, and I can do that right now, with pretty much any 3261 compliant >>> UAC. >>> Heck, an old 2543-compliant UAC will do. >> >> I appreciate your point of view. But I'm not sure I understand your >> usage model. >> It sounds like you have UAs that are enum clients and give the user an >> interface to user enum - offering the choices. Is that right? It >> doesn't seem like something that your average UA provides. >> >> Paul > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 08:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVU-0007o5-Gw; Tue, 18 Sep 2007 08:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVP-0007Xr-Hl for enum@ietf.org; Tue, 18 Sep 2007 08:48:43 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVL-00069U-Jh for enum@ietf.org; Tue, 18 Sep 2007 08:48:43 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.37001623; Tue, 18 Sep 2007 08:48:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:48:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Sep 2007 08:48:05 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031F1@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <00a901c7f964$d5bb82b0$81328810$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg Thread-Index: Acf5OKje1Xc7+ThEQ+eGb/qPiE37EAAK0MRAAAVYdCA= References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com><0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> <46EE91BB.4040705@cisco.com> <00a901c7f964$d5bb82b0$81328810$@us> From: "Livingood, Jason" To: "Richard Shockey" , "Paul Kyzivat" , "lconroy" X-OriginalArrivalTime: 18 Sep 2007 12:48:05.0463 (UTC) FILETIME=[282A9670:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: enum@ietf.org, Dale.Worley@comcast.net, Hadriel Kaplan Subject: [Enum] RE: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thanks, these I-Ds will now be combined and we'll integrate some of the other feedback here as well. We should have a draft for review within a week or so - the co-authors just need to interate the combined document a bit. Jason=20 > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Monday, September 17, 2007 3:56 PM > To: 'Paul Kyzivat'; 'lconroy' > Cc: enum@ietf.org; Dale.Worley@comcast.net; Livingood, Jason;=20 > 'Hadriel Kaplan' > Subject: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg >=20 >=20 > Well as for the slippery slope ..I guess we will all need a=20 > toboggan. =20 >=20 > There is sufficient evidence here to have these documents=20 > ruled in scope. > Barring any further strong objections, it is the view of the=20 > chairs that there is rough consensus that these should be=20 > ENUM WG documents. I'd suggest that the two be combined into=20 > one document since the are sufficientlFrom enum-bounces@ietf.org Tue Sep 18 08:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVU-0007o5-Gw; Tue, 18 Sep 2007 08:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVP-0007Xr-Hl for enum@ietf.org; Tue, 18 Sep 2007 08:48:43 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVL-00069U-Jh for enum@ietf.org; Tue, 18 Sep 2007 08:48:43 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.37001623; Tue, 18 Sep 2007 08:48:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:48:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Sep 2007 08:48:05 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031F1@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <00a901c7f964$d5bb82b0$81328810$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg Thread-Index: Acf5OKje1Xc7+ThEQ+eGb/qPiE37EAAK0MRAAAVYdCA= References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com><0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <002a01c7f7be$e4e3f4e0$800101df@acmepacket.com> <5C43D6F5-D1FA-47E6-B575-D8C9E882B067@insensate.co.uk> <46EE91BB.4040705@cisco.com> <00a901c7f964$d5bb82b0$81328810$@us> From: "Livingood, Jason" To: "Richard Shockey" , "Paul Kyzivat" , "lconroy" X-OriginalArrivalTime: 18 Sep 2007 12:48:05.0463 (UTC) FILETIME=[282A9670:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: enum@ietf.org, Dale.Worley@comcast.net, Hadriel Kaplan Subject: [Enum] RE: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org Thanks, these I-Ds will now be combined and we'll integrate some of the other feedback here as well. We should have a draft for review within a week or so - the co-authors just need to interate the combined document a bit. Jason=20 > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us]=20 > Sent: Monday, September 17, 2007 3:56 PM > To: 'Paul Kyzivat'; 'lconroy' > Cc: enum@ietf.org; Dale.Worley@comcast.net; Livingood, Jason;=20 > 'Hadriel Kaplan' > Subject: In scope for ENUM - draft-livingood-enum-videomsg-voicemsg >=20 >=20 > Well as for the slippery slope ..I guess we will all need a=20 > toboggan. =20 >=20 > There is sufficient evidence here to have these documents=20 > ruled in scope. > Barring any further strong objections, it is the view of the=20 > chairs that there is rough consensus that these should be=20 > ENUM WG documents. I'd suggest that the two be combined into=20 > one document since the are sufficiently related. >=20 > > =20 > > I'll just warn you that having started down that path, you=20 > may find=20 > > it to be the same slippery slope that callerprefs became.=20 > The initial =20 > > draft of callerprefs was very simple - naively so. It=20 > became the mess=20 > > that it ended up by trying to remove ambiguity and cover=20 > the cases=20 > > that were thought to be within its scope. > > =20 > > Paul > > =20 > > > For the rest of this thread, I roll my eyes. > > > > > > all the best, > > > Lawrence > > > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 08:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVS-0007lx-42; Tue, 18 Sep 2007 08:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVL-0007Lu-J1 for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVF-00069U-Cw for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.37001622; Tue, 18 Sep 2007 08:48:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:48:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Tue, 18 Sep 2007 08:48:05 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031F0@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1E20@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf3IFKXm8jbVmDOTmqP0TCAtb4m7wAh+JBAAAY13T4AbgKs0A== References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <040e01c7f7a8$e9042d80$bb0c8880$@us> <32755D354E6B65498C3BD9FD496C7D466B1E20@oefeg-s04.oefeg.loc> From: "Livingood, Jason" To: "Stastny Richard" , "Richard Shockey" X-OriginalArrivalTime: 18 Sep 2007 12:48:05.0244 (UTC) FILETIME=[28092BC0:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > So we should step on or two steps back and simply allow ENUM=20 > services to be defined, they should be checked only if the=20 > are correctly defined. > The usefulness will be shown in practice Here-here, strongly agreed! :-) Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum y related. >=20 > > =20 > > I'll just warn you that having started down that path, you=20 > may find=20 > > it to be the same slippery slope that callerprefs became.=20 > The initial =20 > > draft of callerprefs was very simple - naively so. It=20 > became the mess=20 > > that it ended up by trying to remove ambiguity and cover=20 > the cases=20 > > that were thought to be within its scope. > > =20 > > Paul > > =20 > > > For the rest of this thread, I roll my eyes. > > > > > > all the best, > > > Lawrence > > > >=20 >=20 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 08:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVS-0007lx-42; Tue, 18 Sep 2007 08:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVL-0007Lu-J1 for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVF-00069U-Cw for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.37001622; Tue, 18 Sep 2007 08:48:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:48:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Tue, 18 Sep 2007 08:48:05 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031F0@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1E20@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf3IFKXm8jbVmDOTmqP0TCAtb4m7wAh+JBAAAY13T4AbgKs0A== References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> <040e01c7f7a8$e9042d80$bb0c8880$@us> <32755D354E6B65498C3BD9FD496C7D466B1E20@oefeg-s04.oefeg.loc> From: "Livingood, Jason" To: "Stastny Richard" , "Richard Shockey" X-OriginalArrivalTime: 18 Sep 2007 12:48:05.0244 (UTC) FILETIME=[28092BC0:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > So we should step on or two steps back and simply allow ENUM=20 > services to be defined, they should be checked only if the=20 > are correctly defined. > The usefulness will be shown in practice Here-here, strongly agreed! :-) Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 08:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVT-0007n2-2z; Tue, 18 Sep 2007 08:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVL-0007LW-HK for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVF-00069L-D3 for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.37001610; Tue, 18 Sep 2007 08:47:52 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:47:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Tue, 18 Sep 2007 08:47:52 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031EE@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <46EB0E05.5030405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf3IGcA67bs9yWaTcCvAFUypUrv1gCVwuRQ References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> From: "Livingood, Jason" To: "Paul Kyzivat" , "Brian Rosen" X-OriginalArrivalTime: 18 Sep 2007 12:47:52.0572 (UTC) FILETIME=[207B93C0:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: enum@ietf.org, Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > My biggest problem is that I see phone numbers and sip urls=20 > not as layers but simply as alternative forms of addressing=20 > the same pool of potential callees. So I think there should=20 > be a common mechanism for any problem that comes down to=20 > choosing among alternative targets for a given address.=20 > Whether I call sip:pkyzivat@cisco.com or tel:+19785551881 I=20 > still need to potential to fail over to voicemail if there is=20 > no answer. A different mechanism based on address type is a liability. It may also be the unavoidable reality of what is happening today (for lots of potentially good reasons), and we can choose to ignore this or not. :-) Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 08:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVV-0007q4-00; Tue, 18 Sep 2007 08:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVQ-0007cB-91 for enum@ietf.org; Tue, 18 Sep 2007 08:48:44 -0400 Received: from pacdcimo02.cable.comcast.comFrom enum-bounces@ietf.org Tue Sep 18 08:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVT-0007n2-2z; Tue, 18 Sep 2007 08:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVL-0007LW-HK for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVF-00069L-D3 for enum@ietf.org; Tue, 18 Sep 2007 08:48:39 -0400 Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.37001610; Tue, 18 Sep 2007 08:47:52 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:47:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Tue, 18 Sep 2007 08:47:52 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031EE@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <46EB0E05.5030405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf3IGcA67bs9yWaTcCvAFUypUrv1gCVwuRQ References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com> <09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com> <46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> <46EB0E05.5030405@cisco.com> From: "Livingood, Jason" To: "Paul Kyzivat" , "Brian Rosen" X-OriginalArrivalTime: 18 Sep 2007 12:47:52.0572 (UTC) FILETIME=[207B93C0:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: enum@ietf.org, Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > My biggest problem is that I see phone numbers and sip urls=20 > not as layers but simply as alternative forms of addressing=20 > the same pool of potential callees. So I think there should=20 > be a common mechanism for any problem that comes down to=20 > choosing among alternative targets for a given address.=20 > Whether I call sip:pkyzivat@cisco.com or tel:+19785551881 I=20 > still need to potential to fail over to voicemail if there is=20 > no answer. A different mechanism based on address type is a liability. It may also be the unavoidable reality of what is happening today (for lots of potentially good reasons), and we can choose to ignore this or not. :-) Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 08:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVV-0007q4-00; Tue, 18 Sep 2007 08:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcVQ-0007cB-91 for enum@ietf.org; Tue, 18 Sep 2007 08:48:44 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVK-00069S-2z for enum@ietf.org; Tue, 18 Sep 2007 08:48:44 -0400 Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.11613568; Tue, 18 Sep 2007 08:48:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:48:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Tue, 18 Sep 2007 08:48:04 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031EF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf3DHUfgLwzHBsCTAGAvghy9dcJ3wAAu+VAAJoq7LA= References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> From: "Livingood, Jason" To: "Brian Rosen" , "Paul Kyzivat" X-OriginalArrivalTime: 18 Sep 2007 12:48:05.0682 (UTC) FILETIME=[284C0120:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: enum@ietf.org, Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > Which, I think, is pretty ridiculous, but if we're going down=20 > that path, then we need one for every possible kind of media. >=20 > What do you do if you offer video+audio+real time text+im? =20 Maybe. But I think your arguement assumes that ENUM records, or the size of the data set in the servers is somehow constrained or is otherwise a scarce resource. In a small 1U server in my network today I can handle far, far, far more ENUM records than anyone has dreamed up. And by the time someone does come up with that many, software and hardware will be ahead of the problem, or creative developers and engineers will adapt and innovate. =20 I say, the more in ENUM/DNS, the better. It is an open query/response method and the servers are generally pretty open as well. The alternative has and continues to be proprietary, less open / closed, and generally more expensive (IMHO). Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcVK-00069S-2z for enum@ietf.org; Tue, 18 Sep 2007 08:48:44 -0400 Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.11613568; Tue, 18 Sep 2007 08:48:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 08:48:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Enum] draft-livingood-enum-videomsg-00 Date: Tue, 18 Sep 2007 08:48:04 -0400 Message-ID: <45AEC6EF95942140888406588E1A660202A031EF@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Enum] draft-livingood-enum-videomsg-00 Thread-Index: Acf3DHUfgLwzHBsCTAGAvghy9dcJ3wAAu+VAAJoq7LA= References: <45AEC6EF95942140888406588E1A6602026BA4D9@PACDCEXCMB04.cable.comcast.com> <200709041855.l84ItL7p022103@dragon.ariadne.com><45AEC6EF95942140888406588E1A660202A02BDF@PACDCEXCMB04.cable.comcast.com><46E9A23B.9060908@cisco.com><9AAEDF491EF7CA48AB587781B8F5D7C65E094F@srvxchg3.cablelabs.com><46E9BE95.4020007@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C65E098E@srvxchg3.cablelabs.com><09f601c7f6d6$7a558e10$640fa8c0@cis.neustar.com><46EAEC96.8000803@cisco.com> <0aaf01c7f710$0f4fbd90$640fa8c0@cis.neustar.com> From: "Livingood, Jason" To: "Brian Rosen" , "Paul Kyzivat" X-OriginalArrivalTime: 18 Sep 2007 12:48:05.0682 (UTC) FILETIME=[284C0120:01C7F9F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: enum@ietf.org, Dale.Worley@comcast.net X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org > Which, I think, is pretty ridiculous, but if we're going down=20 > that path, then we need one for every possible kind of media. >=20 > What do you do if you offer video+audio+real time text+im? =20 Maybe. But I think your arguement assumes that ENUM records, or the size of the data set in the servers is somehow constrained or is otherwise a scarce resource. In a small 1U server in my network today I can handle far, far, far more ENUM records than anyone has dreamed up. And by the time someone does come up with that many, software and hardware will be ahead of the problem, or creative developers and engineers will adapt and innovate. =20 I say, the more in ENUM/DNS, the better. It is an open query/response method and the servers are generally pretty open as well. The alternative has and continues to be proprietary, less open / closed, and generally more expensive (IMHO). Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 11:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXed0-0007bb-NP; Tue, 18 Sep 2007 11:04:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXecz-0007bR-EH; Tue, 18 Sep 2007 11:04:41 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXecy-0005GL-Ja; Tue, 18 Sep 2007 11:04:41 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1446f006f7; Tue, 18 Sep 2007 23:15:56 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb546eafb3f; Sat, 15 Sep 2007 05:14:53 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 15 Sep 2007 05:14:53 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHvb-0005L7-7h; Fri, 14 Sep 2007 16:38:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHvX-0005D8-G0; Fri, 14 Sep 2007 16:38:11 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWHvX-0003cK-71; Fri, 14 Sep 2007 16:38:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D2987175C1; Fri, 14 Sep 2007 20:37:40 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IWHv2-0004EU-AU; Fri, 14 Sep 2007 16:37:40 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 14 Sep 2007 16:37:40 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: enum mailing list , enum chair , Internet Architecture Board , RFC Editor Subject: [Enum] Document Action: 'Infrastructure ENUM Requirements' to Informational RFC X-BeenThere: enum@ietf.org List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IESG has approved the following document: - 'Infrastructure ENUM Requirements ' as an Informational RFC This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs-04.txt Technical Summary This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Because end user ENUM as defined in RFC 3761 requires end user opt-in and control of the location of the NAPTRs, it is not suitable for interconnection needs bu service providers. The requirements in the document are needed for the WG to develop a technical solution. Working Group Summary The working group reviewed this document in 2005-6 and was document NIT review preformed by Alexander Mayrhofer Protocol Quality This document was reviewed for the IESG by Jon Peterson. Gen-ART review was performed by Gonzalo Camarillo. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 18 12:10:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXfcu-0003JP-Cu; Tue, 18 Sep 2007 12:08:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXfcs-0003Iw-6u for enum@ietf.org; Tue, 18 Sep 2007 12:08:38 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXfcl-00035x-Pj for enum@ietf.org; Tue, 18 Sep 2007 12:08:38 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8IG80k1026771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Sep 2007 09:08:02 -0700 From: "Richard Shockey" To: Subject: FW: [Enum] Document Action: 'Infrastructure ENUM Requirements' to Informational RFC Date: Tue, 18 Sep 2007 12:07:49 -0400 Message-ID: <00d901c7fa0e$107074c0$31515e40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acf6BUFCuoOcMj8pSHWvZAguUdgE9gACKvhw Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org For those of you who do not subscribe to the IETF Announce List. We can presume that the other documents in the series will receive prompt attention. -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Friday, September 14, 2007 4:38 PM To: IETF-Announce Cc: enum mailing list; enum chair; Internet Architecture Board; RFC Editor Subject: [Enum] Document Action: 'Infrastructure ENUM Requirements' to Informational RFC The IESG has approved the following document: - 'Infrastructure ENUM Requirements ' as an Informational RFC This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-infrastructure-enum-reqs -04.txt Technical Summary This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP. Because end user ENUM as defined in RFC 3761 requires end user opt-in and control of the location of the NAPTRs, it is not suitable for interconnection needs bu service providers. The requirements in the document are needed for the WG to develop a technical solution. Working Group Summary The working group reviewed this document in 2005-6 and was document NIT review preformed by Alexander Mayrhofer Protocol Quality This document was reviewed for the IESG by Jon Peterson. Gen-ART review was performed by Gonzalo Camarillo. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 19 05:31:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXvpU-0000WJ-DQ; Wed, 19 Sep 2007 05:26:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXvpS-0000V6-GX; Wed, 19 Sep 2007 05:26:42 -0400 Received: from email.osc.edu ([192.232.28.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXvpS-0002Mj-6l; Wed, 19 Sep 2007 05:26:42 -0400 Received: from gw.osc.edu (gw.osc.edu [192.232.28.10]) by email.osc.edu (Postfix) with ESMTP id C9D5D27C002; Wed, 19 Sep 2007 05:26:41 -0400 (EDT) Received: from staffdom-MTA by gw.osc.edu with Novell_GroupWise; Wed, 19 Sep 2007 05:26:41 -0400 Message-Id: <46F0B2F60200007F0002A15C@gw.osc.edu> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 19 Sep 2007 05:26:14 -0400 From: "Arif Khan" To: , Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Enum] Re: confirm 79af2eb705fbbef765f41d807dac51f8afa1ab9a X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org >>> 09/18/07 9:04 PM >>> Mailing list subscription confirmation notice for mailing list enum We have received a request from akhan@osc.edu for subscription of your email address, "akhan@osc.edu", to the enum@ietf.org mailing list. To confirm that you want to be added to this mailing list, simply reply to this message, keeping the Subject: header intact. Or visit this web page: https://www1.ietf.org/mailman/confirm/enum/79af2eb705fbbef765f41d807dac= 51f8afa1ab9a Or include the following line -- and only the following line -- in a message to enum-request@ietf.org: confirm 79af2eb705fbbef765f41d807dac51f8afa1ab9a Note that simply sending a `reply' to this message should work from most mail readers, since that usually leaves the Subject: line in the right form (additional "Re:" text in the Subject: is okay). If you do not wish to be subscribed to this list, please simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, send them to enum-owner@ietf.org. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Wed Sep 19 18:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY8D6-00059T-9P; Wed, 19 Sep 2007 18:39:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY8D4-00055k-4k for enum@ietf.org; Wed, 19 Sep 2007 18:39:54 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY8D3-0000TH-KW for enum@ietf.org; Wed, 19 Sep 2007 18:39:54 -0400 Received: from rshockeyPC (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8JMdU1w004311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Sep 2007 15:39:36 -0700 From: "Richard Shockey" To: Date: Wed, 19 Sep 2007 18:39:06 -0400 Message-ID: <007901c7fb0d$e784dfa0$b68e9ee0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acf69bEw49kFPaVLQR6XlifgLwNTsQAGAzlg Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Enum] FW: Deployment of the Internet-Draft Submission Tool X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org For those of you that do not read the announce/discuss list. I strongly recommend all ENUM WG participants use this excellent tool. -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org] Sent: Wednesday, September 19, 2007 3:32 PM To: IETF Announcement list Cc: wgchairs@ietf.org; iesg@ietf.org Subject: Deployment of the Internet-Draft Submission Tool The IETF Secretariat is pleased to announce the deployment of the Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web-based application that will allow an IETF participant to submit an Internet-Draft online, obtain approval to post the draft (if necessary), and make the draft immediately available to the community on the IETF Web site without the assistance of the Secretariat (in most cases). The URL for the IDST is: https://datatracker.ietf.org/idst/upload.cgi The URL for instructions for using the IDST is: http://www.ietf.org/idsubmit_instructions.html Although it will still be possible to submit your drafts by e-mail (i.e., by sending them to internet-drafts@ietf.org), the tool is available for use effective immediately, and we encourage you to submit your drafts via the tool starting today. If you have any questions about using the tool or wish to report a bug, then please send a message to idst-developers@ietf.org. Enjoy!! The IETF Secretariat _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Mon Sep 24 20:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZy1r-0000ZX-84; Mon, 24 Sep 2007 20:11:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZy1p-0000QP-7U; Mon, 24 Sep 2007 20:11:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZy1o-0004UQ-PT; Mon, 24 Sep 2007 20:11:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A1EBB2AC83; Tue, 25 Sep 2007 00:11:52 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IZy1n-0000th-Vo; Mon, 24 Sep 2007 20:11:51 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 24 Sep 2007 20:11:51 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: enum mailing list , enum chair , Internet Architecture Board , RFC Editor Subject: [Enum] Protocol Action: 'ENUM Validation Information Mapping for the Extensible Provisioning Protocol' to Proposed Standard X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org The IESG has approved the following document: - 'ENUM Validation Information Mapping for the Extensible Provisioning Protocol ' as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-validation-epp-06.txt Technical Summary This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide additional features. Working Group Summary The ENUM working group supports the advancement of this specification. Protocol Quality This document was reviewed for the IESG by Jon Peterson. Richard Shockey is the document shepherd. Additional review of XML usage was provided by Scott Hollenbeck. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From enum-bounces@ietf.org Tue Sep 25 07:12:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8Ha-0001FQ-B1; Tue, 25 Sep 2007 07:08:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8HZ-0001FA-9s for enum@ietf.org; Tue, 25 Sep 2007 07:08:49 -0400 Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia8HW-0004d6-BA for enum@ietf.org; Tue, 25 Sep 2007 07:08:46 -0400 Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian)) id 1Ia8HT-00068F-00; Tue, 25 Sep 2007 13:08:43 +0200 Date: Tue, 25 Sep 2007 13:08:42 +0200 From: Otmar Lendl To: "Livingood, Jason" Subject: Re: [Enum] draft-livingood-enum-voicemsg-00 Message-ID: <20070925110841.GA23470@nic.at> Mail-Followup-To: Otmar Lendl , "Livingood, Jason" , enum@ietf.org References: <45AEC6EF95942140888406588E1A6602026BA4D8@PACDCEXCMB04.cable.comcast.com> <46DD9BE9.3000606@cisco.com> <45AEC6EF95942140888406588E1A6602026BA51B@PACDCEXCMB04.cable.comcast.com> <46DF3140.3050905@cisco.com> <45AEC6EF95942140888406588E1A6602026BA5FF@PACDCEXCMB04.cable.comcast.com> <46E1C920.70009@cisco.com> <45AEC6EF95942140888406588E1A6602026BA63D@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45AEC6EF95942140888406588E1A6602026BA63D@PACDCEXCMB04.cable.comcast.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: enum@ietf.org X-BeenThere: enum@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enum Discussion List List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: enum-bounces@ietf.org [I'm a bit late on this thread, but anyway ...] On 2007/09/10 04:09, "Livingood, Jason" wrote: > > 3. Distribution of Data > > The authors believe that it is more likely that these records will be > distributed on a purely private basis, but they may also be > distributed in public ENUM trees. Distribution of this NAPTR data > could be either (a) on a private basis (within a service provider's > internal network, or on a private basis between one or more parties > using a variety of security mechanisms to prohibit general public > access) or (b) openly available. >From what I get from below, your sole motivation now is internal use. Is this correct? > > For instance, a caller who wants to reach VM directly without > > ringing the callee's phone first, would use ENUM to select > > the VM if the target is a phone number. But if the target is > > a non-e.164-sip-address then the way currently defined for > > doing that is for the caller to use callerprefs. And if the > > target is an e.164 number and there is no VM entry in enum, > > callerprefs is again the best hope. > > Please explain how, when someone dials 1-215-555-1212, which is routed > to my (Cisco BTS) Call Management Server, and no one answers, I can use > callerprefs to determine which of, say 10 different voicemail pods to > send the call to. Just for clarification, to see whether I understand your motivation: Within your call routing system, whenever you need to divert the call to voicemail you need to somehow look up the correct URI for the voicemail of that user/TN. As your system is too big to handle all voicemail on a single server (which would make the rewrite trivial), you need a more dynamic, DB-driven lookup mechanism to determine the new URI. You probably don't care whether that lookup is LDAP, local DB, SIP redirect or whatever as long it's easily implemented and does not significantly change your operating costs. (For what it's worth, in http://www.at43.at/en/ we store the VM URI in the same DB which also hold the SIP registrations. We do not need to make a second query to anything if the call needs to be diverted to VM (on timeout or on user not online). ) In theory, you could just use a x-whatever service field to store your VM URI in your internal ENUM, and since these records just appear in your own private network, that's fine and dandy and nobody can stop you from doing that. Especially if you already base your local call routing on a private ENUM tree. Documenting this approach in an I-D and registering a service-type seems to have two advantages: * it's easier to say to a vendor "we need support for RFC XXX" than "we need you to implement this fancy scheme we came up with". Plus, hopefully less vendor lock-in. * if you merge with another company, chances are higher that you both use the same scheme, which lowers integration costs. That all sounds very legitimate to me. ---------- I cannot see a good motivation for a cross-operator use of this service-type. But who knows what might come up in the future. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum