From rjsparks@nostrum.com Mon May 14 11:54:51 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCC821F88E3 for ; Mon, 14 May 2012 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUaJndXy0lQ0 for ; Mon, 14 May 2012 11:54:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A58F221F88C5 for ; Mon, 14 May 2012 11:54:50 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q4EIsjP7071382 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 May 2012 13:54:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <4FB154F5.2010109@nostrum.com> Date: Mon, 14 May 2012 13:54:45 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: <4F91817F.80907@nostrum.com> In-Reply-To: <4F91817F.80907@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Ecrit] Richard Barnes is stepping down as Ecrit chair X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:54:51 -0000 The chairs have completed the transition, and Richard is stepping down. The charter page will be updated soon. Richard - Thank you for the time and effort you put into co-chairing ECRIT for the last few years! RjS From christer.holmberg@ericsson.com Tue May 15 04:05:47 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DF021F87E1 for ; Tue, 15 May 2012 04:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjrjjQ2dkbH7 for ; Tue, 15 May 2012 04:05:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC921F8816 for ; Tue, 15 May 2012 04:05:45 -0700 (PDT) X-AuditID: c1b4fb25-b7c5aae000007a47-a4-4fb2388191e6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 25.11.31303.18832BF4; Tue, 15 May 2012 13:05:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 15 May 2012 13:05:37 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Date: Tue, 15 May 2012 13:05:36 +0200 Thread-Topic: PSAP Callback - Yet Another Beginning Thread-Index: Ac0yfD7WtbImJDapTgyJ1IW9elu94A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C444A0E16ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Ecrit] PSAP Callback - Yet Another Beginning X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 11:05:47 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C444A0E16ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Once again, I would like to see whether there is a way for us to move forwa= rd on the callback indicator issue. There are two requirements: 1. Indicate the callback 2. Be able to route the callback to the user that made the emergency = call Regarding the indication, it has been suggested that the indicator value is= per user, and is provided to the user upon registration. We also discussed whether the value could change over time, but the problem= was that the emg call may be done using an old value, and the callback usi= ng a new value (because there was some time between the emg call and the ca= llback, during which the user was given a new value). To avoid that, the registrar would always provide the same value to a given= user. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C444A0E16ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Once again= , I would like to see whether there is a way for us to move forward on the = callback indicator issue.

 

There are two requirements:

 

1. =       Indicate the callbac= k

2.    &nb= sp;  Be able to route the callback to the user= that made the emergency call

 = ;

Regarding the indication, it has been sugge= sted that the indicator value is per user, and is provided to the user upon= registration.

 

We also discussed whether the value could change over time= , but the problem was that the emg call may be done using an old value, and= the callback using a new value (because there was some time between the em= g call and the callback, during which the user was given a new value).=

 

To= avoid that, the registrar would always provide the same value to a given u= ser.

 

Regards,

 

Christer

= --_000_7F2072F1E0DE894DA4B517B93C6A05852C444A0E16ESESSCMS0356e_-- From pkyzivat@alum.mit.edu Tue May 15 08:19:09 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA9221F86EC for ; Tue, 15 May 2012 08:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-D+CZCp0Brt for ; Tue, 15 May 2012 08:19:09 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE121F85B9 for ; Tue, 15 May 2012 08:19:08 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id AC7K1j00F1ZXKqc53FK98k; Tue, 15 May 2012 15:19:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id AFK91j00S07duvL3hFK94w; Tue, 15 May 2012 15:19:09 +0000 Message-ID: <4FB273EB.2080802@alum.mit.edu> Date: Tue, 15 May 2012 11:19:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:19:10 -0000 I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: - the UA, when placing an emergency call, can use a temp gruu. Its possible to get as many temp gruus as you like, so the UA can reserve one for this purpose. This doesn't require any new capabilities in registrars. - when the UA receives a call addressed to a temp gruu that it had previously used for an emergency call, it can give it special treatment as an emergency callback. It can decide how long after the emergency call to grant this special treatment as a matter of policy. The special treatment can include dropping existing calls, special alerting, etc. - the PSAP, when placing the emergency callback, can indicate that *it* considers this call important using the Priority:emergency. If appropriate it can also use other existing headers, such as Resource-Priority. It call also use callerprefs to indicate that it prefers the real UA and does not wish an automaton. - middleboxes in the path of the callback can choose to honor the Priority:emergency, and use that to condition their behavior. For instance, a home proxy could decide that an emergency call to a temp gruu should not be diverted. (Though the fact that it is to a gruu should typically bypass that anyway.) - abuses of Priority:emergency by callers can be dealt with by the called UA, because it can reject such calls if not to a temp gruu previously used for an emergency call. This can cause *some* disruption, but only to the extent of handling an incoming INVITE and rejecting it. If the frequency of that rises to a level where it becomes a problem then it should be dealt with as a DOS attack. Thanks, Paul On 5/15/12 7:05 AM, Christer Holmberg wrote: > Hi, > > Once again, I would like to see whether there is a way for us to move > forward on the callback indicator issue. > > There are two requirements: > > 1.Indicate the callback > > 2.Be able to route the callback to the user that made the emergency call > > Regarding the indication, it has been suggested that the indicator value > is per user, and is provided to the user upon registration. > > We also discussed whether the value could change over time, but the > problem was that the emg call may be done using an old value, and the > callback using a new value (because there was some time between the emg > call and the callback, during which the user was given a new value). > > To avoid that, the registrar would always provide the same value to a > given user. > > Regards, > > Christer > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From prvs=3482ab5b84=jbakker@rim.com Tue May 15 09:13:01 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AF621F8828 for ; Tue, 15 May 2012 09:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SddD5LlbxzPX for ; Tue, 15 May 2012 09:13:00 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id E315621F87E2 for ; Tue, 15 May 2012 09:12:59 -0700 (PDT) X-AuditID: 0a412830-b7f0e6d000004648-ba-4fb28088231b Received: from XCT102CNC.rim.net (xct102cnc.rim.net [10.65.161.202]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id E7.3D.17992.88082BF4; Tue, 15 May 2012 16:12:56 +0000 (GMT) Received: from XCT105ADS.rim.net (10.67.111.46) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 15 May 2012 12:12:55 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.01.0339.001; Tue, 15 May 2012 11:12:55 -0500 From: John-Luc Bakker To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac0yfD7WtbImJDapTgyJ1IW9elu94AAW7vuAAAki5SA= Date: Tue, 15 May 2012 16:12:54 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA3516D71B@XMB104ADS.rim.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> In-Reply-To: <4FB273EB.2080802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsXC5bjwlG5HwyZ/g0uXNC0aFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAU1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvkk5qemKMQUJRZ lphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLz kvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5MvbdectecFuxYl5PH1sD4xOpLkZODgkBE4llmx8w QdhiEhfurWfrYuTiEBLoY5L49/0mC4SzglFiU9MEJghnM6PEhkd7GEFa2ATUJbau2M4MYosI eEv8+f2NDcQWFrCSuPLyGDtE3Fri6Y2VULaVxP2jX8FsFgFViWMn94Gt5hVwk7j0fh4riC0k UClxfvdNMJtTQEfi96o1YPMZgc77fmoNWD2zgLjErSfzoc4WkFiy5zwzhC0q8fLxP1YIW1Fi xp75rBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywQe2UkWtt2sU1gFJ+FZMUsJO2zkLTPQtK+ gJFlFaNgbkaxgZlhcl6yXlFmrl5easkmRnAK0TDYwThhr9YhRgEORiUeXta0Tf5CrIllxZW5 hxglOJiVRHjFzIBCvCmJlVWpRfnxRaU5qcWHGC2AITSRWYo7OR+Y3vJK4o0NDFA4SuK80SZL /IUE0oFpKTs1tSC1CKaViYMTZDSXlEgxMLmkFiWWlmTEg1JgfDEwCUo1MEZXXFrdbGR79jJD RLVjzgL51wF1lx/Z/fnWfFLJSTi4rInrg2Sc3UQtNQmP5q/GdyRkjY1iTzjuY1O8YjdjstdL g+QfWX/8rZjdd1/daMVr/u3sUqvnDUEefhuaHzRddah2FOLdErJVIf1GodmVKAXV/Q33HVQO 3Mg4q/4gIZFv3c13e5YmKrEUZyQaajEXFScCAI3PAeFVAwAA Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:13:01 -0000 Hi Paul, The solution below relies on temporary GRUUs. The UA needs to select a tempo= rary GRUU that is persisted at the PSAP (or CS - PS network entity between U= E and PSAP), at the REGISTRAR and at the UE. Note that the cause of a prematurely dropped emergency call (i.e. one that r= equires a call back) may also cause registration information to be removed i= n the network. Alternatively, the UE may have rebooted causing the premature= ly dropped emergency call. Persistence issues can be addressed. If there is a solution for persistence, a solution requiring less state to b= e maintained by UE and (home) network in the eventually of an emergency call= back (which is not a regularly happening event) can also be considered. Add= itionally, some "home" networks do not require support for emergency call ba= cks. Keeping the requirements (i.e. for maintaining state) for emergency cal= l back support in the "serving" network may be preferable. Kind regards, John-Luc -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat Sent: Tuesday, May 15, 2012 10:19 AM To: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning I'll repeat my earlier arguments. Maybe I can make them more explicit this t= ime. I think we have sufficient mechanism already defined, if it is used app= ropriately. Specifically: - the UA, when placing an emergency call, can use a temp gruu. Its possible to get as many temp gruus as you like, so the UA can reserve one for this purpose. This doesn't require any new capabilities in registrars. - when the UA receives a call addressed to a temp gruu that it had previously used for an emergency call, it can give it special treatment as an emergency callback. It can decide how long after the emergency call to grant this special treatment as a matter of policy. The special treatment can include dropping existing calls, special alerting, etc. - the PSAP, when placing the emergency callback, can indicate that *it* considers this call important using the Priority:emergency. If appropriate it can also use other existing headers, such as Resource-Priority. It call also use callerprefs to indicate that it prefers the real UA and does not wish an automaton. - middleboxes in the path of the callback can choose to honor the Priority:emergency, and use that to condition their behavior. For instance, a home proxy could decide that an emergency call to a temp gruu should not be diverted. (Though the fact that it is to a gruu should typically bypass that anyway.) - abuses of Priority:emergency by callers can be dealt with by the called UA, because it can reject such calls if not to a temp gruu previously used for an emergency call. This can cause *some* disruption, but only to the extent of handling an incoming INVITE and rejecting it. If the frequency of that rises to a level where it becomes a problem then it should be dealt with as a DOS attack. Thanks, Paul On 5/15/12 7:05 AM, Christer Holmberg wrote: > Hi, > > Once again, I would like to see whether there is a way for us to move > forward on the callback indicator issue. > > There are two requirements: > > 1.Indicate the callback > > 2.Be able to route the callback to the user that made the emergency > call > > Regarding the indication, it has been suggested that the indicator > value is per user, and is provided to the user upon registration. > > We also discussed whether the value could change over time, but the > problem was that the emg call may be done using an old value, and the > callback using a new value (because there was some time between the > emg call and the callback, during which the user was given a new value). > > To avoid that, the registrar would always provide the same value to a > given user. > > Regards, > > Christer > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Tue May 15 09:53:10 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D402321F8809 for ; Tue, 15 May 2012 09:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ntwN6zlbiZ for ; Tue, 15 May 2012 09:53:09 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id A358F21F87FC for ; Tue, 15 May 2012 09:53:09 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id AGt41j00517dt5G55GtAYW; Tue, 15 May 2012 16:53:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id AGt91j00r07duvL3ZGt9Gb; Tue, 15 May 2012 16:53:09 +0000 Message-ID: <4FB289F4.7080003@alum.mit.edu> Date: Tue, 15 May 2012 12:53:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: John-Luc Bakker References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <155970D1DA8E174F9E46039E10E2AA3516D71B@XMB104ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA3516D71B@XMB104ADS.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:53:11 -0000 On 5/15/12 12:12 PM, John-Luc Bakker wrote: > Hi Paul, > > The solution below relies on temporary GRUUs. The UA needs to select a temporary GRUU that is persisted at the PSAP (or CS - PS network entity between UE and PSAP), at the REGISTRAR and at the UE. Note that the temp gruu mechanism was specified in such a way that the registrar need not persist specific temp gruus. > Note that the cause of a prematurely dropped emergency call (i.e. one that requires a call back) may also cause registration information to be removed in the network. Alternatively, the UE may have rebooted causing the prematurely dropped emergency call. You are right that expiration (or removal) of the registration will invalidate any temp gruus that have been assigned. A possible way to address that would be for the PSAP to first try the temp gruu, and if that fails, then retry using the permanent gruu. This of course has more potential for abuse. (But still limited, because the UA can limit special behavior to a time window after an emergency call.) In this case the UA might be more hesitant to expedite the call. But it could still alert the user, ask the user if he wants to accept this as an emergency call, etc. (The middleboxes could still skip special handling in this case - leaving the decision to the UA.) If its unacceptable to raise the bar for answering when the temp gruu doesn't work, then forget the temp gruu and use only the permanent gruu. Grant emergency behavior at the UA for any incoming call based on Priority:emergency and being in a time window following origination of an emergency call. That is not a perfect solution. But I'm not aware of any perfect solutions having been proposed. > Persistence issues can be addressed. > > If there is a solution for persistence, a solution requiring less state to be maintained by UE and (home) network in the eventually of an emergency call back (which is not a regularly happening event) can also be considered. Additionally, some "home" networks do not require support for emergency call backs. Keeping the requirements (i.e. for maintaining state) for emergency call back support in the "serving" network may be preferable. AFAIK state in the PSAP is an acceptable limitation. And IMO state in the UE is also reasonable, and much more dependable and resistant to abuse than mechanisms that don't require state in the UE. I'm interested in hearing more about situations where the home network doesn't have any support for emergency calls but the "serving" network does. In that case how do you propose to have the home network avoid applying inappropriate services to the callback? Thanks, Paul > Kind regards, > > John-Luc > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, May 15, 2012 10:19 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: > > - the UA, when placing an emergency call, can use a temp gruu. > Its possible to get as many temp gruus as you like, so the UA > can reserve one for this purpose. This doesn't require any > new capabilities in registrars. > > - when the UA receives a call addressed to a temp gruu that it > had previously used for an emergency call, it can give it > special treatment as an emergency callback. It can decide how > long after the emergency call to grant this special treatment > as a matter of policy. The special treatment can include dropping > existing calls, special alerting, etc. > > - the PSAP, when placing the emergency callback, can indicate that > *it* considers this call important using the Priority:emergency. > If appropriate it can also use other existing headers, such as > Resource-Priority. It call also use callerprefs to indicate that > it prefers the real UA and does not wish an automaton. > > - middleboxes in the path of the callback can choose to honor the > Priority:emergency, and use that to condition their behavior. > For instance, a home proxy could decide that an emergency call > to a temp gruu should not be diverted. (Though the fact that it is > to a gruu should typically bypass that anyway.) > > - abuses of Priority:emergency by callers can be dealt with by the > called UA, because it can reject such calls if not to a temp > gruu previously used for an emergency call. This can cause *some* > disruption, but only to the extent of handling an incoming INVITE > and rejecting it. If the frequency of that rises to a level where > it becomes a problem then it should be dealt with as a DOS attack. > > Thanks, > Paul > > On 5/15/12 7:05 AM, Christer Holmberg wrote: >> Hi, >> >> Once again, I would like to see whether there is a way for us to move >> forward on the callback indicator issue. >> >> There are two requirements: >> >> 1.Indicate the callback >> >> 2.Be able to route the callback to the user that made the emergency >> call >> >> Regarding the indication, it has been suggested that the indicator >> value is per user, and is provided to the user upon registration. >> >> We also discussed whether the value could change over time, but the >> problem was that the emg call may be done using an old value, and the >> callback using a new value (because there was some time between the >> emg call and the callback, during which the user was given a new value). >> >> To avoid that, the registrar would always provide the same value to a >> given user. >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > From brian.rosen@neustar.biz Mon May 21 14:49:58 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D915F21F84D9 for ; Mon, 21 May 2012 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVq-xE1KFoOa for ; Mon, 21 May 2012 14:49:58 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1BF21F84B3 for ; Mon, 21 May 2012 14:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1337637223; x=1652989163; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=3HovS7MRyXYFlZCqF5Ixu Y9c698TUChoJDY10i/BCdA=; b=mOFgfULO/btr+SOTHeLHv1BSIGP57YeoLKN1t Pm+e1NBxHBYYGySeFfGJnTm9JZK6gQ4PuSFZkw0MIBSNkRXGQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.9834605; Mon, 21 May 2012 17:53:42 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 21 May 2012 17:49:54 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Mon, 21 May 2012 17:49:38 -0400 Thread-Topic: Additional Data by value from more than one source Thread-Index: Ac03m6eOiKdshoFlQV+L1TDcK7J5Ig== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /fA+aLItk1/Vn1bOcivrgg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 21:49:59 -0000 Suppose two service providers are in the call path. Both of them should ad= d Additional Call Data. Suppose they both do it by value. Since we broke up the data structure into separate MIME types, there could = be two blocks of the same type. How do we know which belongs with which? F= or example, you can have two data provider blocks and two call service bloc= ks. How would you know which pair went together? Best I can come up with is force separate Call-Info headers and assume all = the blocks from one header come from the same provider. Yuck. Can't nest mime/multipart, so no way to actually structure the data. I'm rethinking what the mime envelope of each block gets us. Not clear its= worth it over an XML object with optional elements. If you had one mime t= ype that was a top level Additional Call Data type, which contained a compl= ex type with several optional subelements, each of which were the blocks, y= ou could have more than one of them pointed to by the CIDs. Brian From martin.thomson@gmail.com Mon May 21 15:16:28 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB6D21F8540 for ; Mon, 21 May 2012 15:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwNrOq3svJXP for ; Mon, 21 May 2012 15:16:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20BC521F8535 for ; Mon, 21 May 2012 15:16:26 -0700 (PDT) Received: by bkty8 with SMTP id y8so5311634bkt.31 for ; Mon, 21 May 2012 15:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5K/uN6bWceEAn8lX17sPqrEtMis06eL4eem3QngrMgg=; b=an0bs35ICyAX22dpwRRRAJeNnYHEJRosBed0zcWoA+7zZIiNLj2ChzFWLe3JDhpr8k i+OV2E0qCnsYKhZt/0MLHDKeYV4cX86pZ0cxuShbI85L786cfLZqoMabH3bP+liO+56b ynwF+s6hhfiGPdEe67QkPOVR/QMQmML14shKEyf/uVgHujN8GVln8jjvDI49NLKajDye 4jQ7ZIr3uxv4tKSGbsmwgvA6jGk3ZiVKW2QynmwoE6FtroNc/b4yCJdKM8UK7qhpAQME EdvJx9RzDpyboQlMtBxiYOB1bMLoyPFbmD1yDNhGUqByJH/R7VPjmI2O8P1uwBEG1Pia 8iqg== MIME-Version: 1.0 Received: by 10.204.152.195 with SMTP id h3mr8723570bkw.119.1337638586092; Mon, 21 May 2012 15:16:26 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Mon, 21 May 2012 15:16:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 May 2012 15:16:26 -0700 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:16:28 -0000 What's wrong with a pointer from the content to the data provider? Link: ; rel=3Dvia See RFC 5988. ("via" seemed the most appropriate from skimming through the registry, but you could use another if you find a better fit on semantics. I couldn't see a link relation for the reverse link, but it doesn't seem as useful.) On 21 May 2012 14:49, Rosen, Brian wrote: > Suppose two service providers are in the call path. =C2=A0Both of them sh= ould add Additional Call Data. =C2=A0Suppose they both do it by value. > > Since we broke up the data structure into separate MIME types, there coul= d be two blocks of the same type. =C2=A0How do we know which belongs with w= hich? For example, you can have two data provider blocks and two call servi= ce blocks. =C2=A0How would you know which pair went together? > > Best I can come up with is force separate Call-Info headers and assume al= l the blocks from one header come from the same provider. =C2=A0Yuck. > > Can't nest mime/multipart, so no way to actually structure the data. > > I'm rethinking what the mime envelope of each block gets us. =C2=A0Not cl= ear its worth it over an XML object with optional elements. =C2=A0If you ha= d one mime type that was a top level Additional Call Data type, which conta= ined a complex type with several optional subelements, each of which were t= he blocks, you could have more than one of them pointed to by the CIDs. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Mon May 21 15:17:53 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C129A21F8540 for ; Mon, 21 May 2012 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOhSaNfdkfmY for ; Mon, 21 May 2012 15:17:53 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 33DAE21F8541 for ; Mon, 21 May 2012 15:17:53 -0700 (PDT) X-AuditID: 0a0404e8-b7cc5ae000005049-6f-4fbabf10f8fb Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id A3.92.20553.01FBABF4; Mon, 21 May 2012 17:17:52 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 21 May 2012 17:17:52 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 22 May 2012 06:17:49 +0800 From: "Winterbottom, James" To: "Rosen, Brian" , "ecrit@ietf.org Org" Date: Tue, 22 May 2012 06:17:46 +0800 Thread-Topic: Additional Data by value from more than one source Thread-Index: Ac03m6eOiKdshoFlQV+L1TDcK7J5IgAAdvDA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012121C9B835@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:17:53 -0000 Brian, Each data-blob seems to have provider information in it anyway, so doesn't = this allow the data to be aligned as you require? The alternative would be to include a correlation-id in data elements that = allows them to be linked. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Rosen, Brian > Sent: Tuesday, 22 May 2012 7:50 AM > To: ecrit@ietf.org Org > Subject: [Ecrit] Additional Data by value from more than one source >=20 > Suppose two service providers are in the call path. Both of them should > add Additional Call Data. Suppose they both do it by value. >=20 > Since we broke up the data structure into separate MIME types, there coul= d > be two blocks of the same type. How do we know which belongs with which? > For example, you can have two data provider blocks and two call service > blocks. How would you know which pair went together? >=20 > Best I can come up with is force separate Call-Info headers and assume al= l > the blocks from one header come from the same provider. Yuck. >=20 > Can't nest mime/multipart, so no way to actually structure the data. >=20 > I'm rethinking what the mime envelope of each block gets us. Not clear > its worth it over an XML object with optional elements. If you had one > mime type that was a top level Additional Call Data type, which contained > a complex type with several optional subelements, each of which were the > blocks, you could have more than one of them pointed to by the CIDs. >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Tue May 22 06:08:32 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F8421F861A for ; Tue, 22 May 2012 06:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.723 X-Spam-Level: X-Spam-Status: No, score=-4.723 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDj+Ju+ATmxW for ; Tue, 22 May 2012 06:08:31 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 55C2221F84D9 for ; Tue, 22 May 2012 06:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1337692227; x=1653042984; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=oIyPMmn+Ewqv+HoGEyK8b YcT2kpdyDlnICQP/o7INv4=; b=lJ+ElubQwmOPIemwy4jmivaTZDN0+5CkPZpze HqZS0TbJ2Ab1asY6XamcPmMLWthmg4T8rZOciG341sQgp0nfw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.9343039; Tue, 22 May 2012 09:10:25 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 22 May 2012 09:08:27 -0400 From: "Rosen, Brian" To: Martin Thomson Date: Tue, 22 May 2012 09:08:23 -0400 Thread-Topic: [Ecrit] Additional Data by value from more than one source Thread-Index: Ac04G/l5Z3KFViFKQ1agR6/FwTM2gg== Message-ID: <8FFAD831-723C-4C1F-8019-B99A62815AF2@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: NcGDxJjEXeguj45SNPwoFA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 13:08:32 -0000 "Link" isn't a sip header is it? Can we answer the question of what having multiple MIME types buys us? I n= ote that the normal case will be that the Call-Info has to have multiple CI= Ds, one for each block. What do we get out of the MIME type itself over a single MIME type for Addi= tionalCallData, and an XML structure for the blocks? The only advantage I can think of is a more natural extension point, but th= at seems to be a very small positive with several negatives offsetting it. Brian On May 21, 2012, at 6:16 PM, Martin Thomson wrote: > What's wrong with a pointer from the content to the data provider? >=20 > Link: ; rel=3Dvia >=20 > See RFC 5988. ("via" seemed the most appropriate from skimming > through the registry, but you could use another if you find a better > fit on semantics. I couldn't see a link relation for the reverse > link, but it doesn't seem as useful.) >=20 > On 21 May 2012 14:49, Rosen, Brian wrote: >> Suppose two service providers are in the call path. Both of them should= add Additional Call Data. Suppose they both do it by value. >>=20 >> Since we broke up the data structure into separate MIME types, there cou= ld be two blocks of the same type. How do we know which belongs with which= ? For example, you can have two data provider blocks and two call service b= locks. How would you know which pair went together? >>=20 >> Best I can come up with is force separate Call-Info headers and assume a= ll the blocks from one header come from the same provider. Yuck. >>=20 >> Can't nest mime/multipart, so no way to actually structure the data. >>=20 >> I'm rethinking what the mime envelope of each block gets us. Not clear = its worth it over an XML object with optional elements. If you had one mim= e type that was a top level Additional Call Data type, which contained a co= mplex type with several optional subelements, each of which were the blocks= , you could have more than one of them pointed to by the CIDs. >>=20 >> Brian >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Tue May 22 06:17:46 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F068B21F8585 for ; Tue, 22 May 2012 06:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhCiG1gB6XHM for ; Tue, 22 May 2012 06:17:46 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E0D0C21F857F for ; Tue, 22 May 2012 06:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1337692781; x=1653042984; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ceEFjLicLv7gh6tokD1z/ FTdrbmc9k1zExiLcUSCA6w=; b=nsaNg+KBgSW4rOn7OwWmNSTy+4P3rL2uAYUEU AVRnEilmbo091QfXgInbIMt/SESJlNiEpT+oG5ViuYphe6p7A== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.9343371; Tue, 22 May 2012 09:19:40 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 22 May 2012 09:17:42 -0400 From: "Rosen, Brian" Date: Tue, 22 May 2012 09:17:41 -0400 Thread-Topic: [Ecrit] Additional Data by value from more than one source Thread-Index: Ac04HUQ96vaxIUwmTaOq+DQadeaHzw== Message-ID: References: <5A55A45AE77F5941B18E5457ECAC8188012121C9B835@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012121C9B835@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: B3mrTGSlmUnZW3aQAjVFoQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "Winterbottom, James" Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 13:17:47 -0000 Yeah, we could specify that the CID have a domain that is the same for all = of the blocks from a given provider. That's probably the simplest answer. I still would like to make sure separate MIME types has enough advantages t= o overcome this and the issue that the Call-Info header has to have multipl= e CIDs, one for each block. Brian On May 21, 2012, at 6:17 PM, Winterbottom, James wrote: > Brian, >=20 > Each data-blob seems to have provider information in it anyway, so doesn'= t this allow the data to be aligned as you require? >=20 > The alternative would be to include a correlation-id in data elements tha= t allows them to be linked. >=20 > Cheers > James >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f >> Rosen, Brian >> Sent: Tuesday, 22 May 2012 7:50 AM >> To: ecrit@ietf.org Org >> Subject: [Ecrit] Additional Data by value from more than one source >>=20 >> Suppose two service providers are in the call path. Both of them should >> add Additional Call Data. Suppose they both do it by value. >>=20 >> Since we broke up the data structure into separate MIME types, there cou= ld >> be two blocks of the same type. How do we know which belongs with which= ? >> For example, you can have two data provider blocks and two call service >> blocks. How would you know which pair went together? >>=20 >> Best I can come up with is force separate Call-Info headers and assume a= ll >> the blocks from one header come from the same provider. Yuck. >>=20 >> Can't nest mime/multipart, so no way to actually structure the data. >>=20 >> I'm rethinking what the mime envelope of each block gets us. Not clear >> its worth it over an XML object with optional elements. If you had one >> mime type that was a top level Additional Call Data type, which containe= d >> a complex type with several optional subelements, each of which were the >> blocks, you could have more than one of them pointed to by the CIDs. >>=20 >> Brian >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Tue May 22 08:48:06 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2CF21F8637 for ; Tue, 22 May 2012 08:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6Oq+0DoQRSH for ; Tue, 22 May 2012 08:48:05 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18ABF21F8628 for ; Tue, 22 May 2012 08:48:02 -0700 (PDT) Received: by bkty8 with SMTP id y8so6170484bkt.31 for ; Tue, 22 May 2012 08:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QMlUvHkZ5uWKvr0Uy+xIJpiPwD2MHYeIB9A3LQfPl2A=; b=KjX7dursbUEXYgAomtwCpY3LqbkJduPYLmUg0WwilxBhDYlkKkMM1VcB6PwOwRK+wZ lMzIatIBECRmlddLR6wSjvYkMv811Aj29wsRfOV47kT8tS0oxNtJ1WcTCVdwbVcfYx+c rhKlbO/bO6pDHbn1cgi7+ZBgGqn+2J8l0JoZhp/UqzlfNh0qM5ph1Ti7uZhQLP6NGthJ dtjj9AmMFdWIJDoTsMF9b6ZDc0Ck6c/O49caMUjUAOOnv2KM9bpg1YmH7B26/Sdfqvrl LbXrSbeh8HwozZOY4rtOZ1YRcRZft++hoPxnE+qkjJL5Uln96c4jgN7JzIgnxxhmEHZN 4RDQ== MIME-Version: 1.0 Received: by 10.204.152.13 with SMTP id e13mr10402256bkw.46.1337701682037; Tue, 22 May 2012 08:48:02 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 22 May 2012 08:48:01 -0700 (PDT) In-Reply-To: <8FFAD831-723C-4C1F-8019-B99A62815AF2@neustar.biz> References: <8FFAD831-723C-4C1F-8019-B99A62815AF2@neustar.biz> Date: Tue, 22 May 2012 08:48:01 -0700 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:48:06 -0000 On 22 May 2012 06:08, Rosen, Brian wrote: > "Link" isn't a sip header is it? and? If you don't like it, an explicit link in content requires a little specification effort, but it is less implicit. That is rather than: Call-Info -> info Call-Info -> info provider info You can have: Call-Info -> info -> info provider info Which is arguably cleaner semantically. > Can we answer the question of what having multiple MIME types buys us? Not having to define "an XML structure for the blocks?" > The only advantage I can think of is a more natural extension point, but that seems to be a very small positive with several negatives offsetting it. Several? Or just one: clearer linkage between units of information. Not having to implement XML vCard seems like an advantage in favour of separate blocks. --Martin From brian.rosen@neustar.biz Tue May 22 09:28:35 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C676621F860D for ; Tue, 22 May 2012 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIH63oxxIxgo for ; Tue, 22 May 2012 09:28:35 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 18B9621F8606 for ; Tue, 22 May 2012 09:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1337704231; x=1653060761; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=7NVG3ax/KSPm1mghnOVQH ayc32UnP0FQ/fp+XUQQnZk=; b=pKSu6ZT4mdApIXhQU1hKSDfz+1Cj+5e+aZ09i eutff04zPW81WurX0pO5+puXiLtvvtVer5Ap+p5pTmyldGndA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.9353769; Tue, 22 May 2012 12:30:30 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 22 May 2012 12:28:31 -0400 From: "Rosen, Brian" To: Martin Thomson Date: Tue, 22 May 2012 12:28:30 -0400 Thread-Topic: [Ecrit] Additional Data by value from more than one source Thread-Index: Ac04N+zySmP6vLSjQ/KLVfHgR+Rm8Q== Message-ID: References: <8FFAD831-723C-4C1F-8019-B99A62815AF2@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: q5hJtKO/OEjUq0S5qDleVQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 16:28:35 -0000 On May 22, 2012, at 11:48 AM, Martin Thomson wrote: > On 22 May 2012 06:08, Rosen, Brian wrote: >> "Link" isn't a sip header is it? >=20 > and? Can't use it. >=20 > If you don't like it, an explicit link in content requires a little > specification effort, but it is less implicit. That is rather than: >=20 > Call-Info -> info > Call-Info -> info provider info >=20 > You can have: >=20 > Call-Info -> info -> info provider info >=20 > Which is arguably cleaner semantically. Not sure how this would work. One CID in Call Info points to the first blo= ck, with that block having a CID to another block? >=20 >> Can we answer the question of what having multiple MIME types buys us? >=20 > Not having to define "an XML structure for the blocks?" You mean one complex type with an extensible list of blocks? >=20 >> The only advantage I can think of is a more natural extension point, but= that seems to be a very small positive with several negatives offsetting i= t. >=20 > Several? Or just one: clearer linkage between units of information. No, the XML also means the Call Info is crowded. Instead of one URI per Ad= ditionalCallData, there is one per block. >=20 > Not having to implement XML vCard seems like an advantage in favour of > separate blocks. It's defined as using the XML vCARD, which is now a standard. Among other = things, the vCard is not the only element in the block, and there are vCard= s that represent more than one entity (subscriber, service provider, device= owner, =85) >=20 > --Martin > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Tue May 22 13:55:59 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258E821F8681 for ; Tue, 22 May 2012 13:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYXPEEjJF+x9 for ; Tue, 22 May 2012 13:55:58 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6474A21F8680 for ; Tue, 22 May 2012 13:55:58 -0700 (PDT) Received: by bkty8 with SMTP id y8so6462480bkt.31 for ; Tue, 22 May 2012 13:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jAWdwDSpYE8iDNDpPCgmTJ81RWSXFQZviLJ6hBUR4sA=; b=SEgAMFqvI7zMDuixffiR39UhVPjPKHLd/IlZTpBWVWhdfWakWtzhd8PdrsK2ZW2f7x n8mp8m+N4o9wZ2NB9q4+LaFRsRfYYOLyrJaEH6gaDsQfKB88xI6OFd6pNHfn6+6iVRz0 Mkp5B0FOpG8sbr2IgOhFwAmyd25Tvwy7x/fSojR6DhFJF6VGbr4HqoNa4IYvKNfGC8YG 8h7jb+Sh8PxwK3/3sUfpEv3RhcMGfV2M+t3JVPx41FH90HO5GMNNXeBWv/ZtVs/G94WE rU7B9VaA8rbTuPrNDpzbxJrduvSYwtTtUxOWb+sMqvqFIQcyvodRzJKZHuFSwESAJtoK q8+A== MIME-Version: 1.0 Received: by 10.204.152.73 with SMTP id f9mr10688163bkw.3.1337720157440; Tue, 22 May 2012 13:55:57 -0700 (PDT) Received: by 10.204.66.4 with HTTP; Tue, 22 May 2012 13:55:57 -0700 (PDT) In-Reply-To: References: <8FFAD831-723C-4C1F-8019-B99A62815AF2@neustar.biz> Date: Tue, 22 May 2012 13:55:57 -0700 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data by value from more than one source X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 20:55:59 -0000 On 22 May 2012 09:28, Rosen, Brian wrote: > > On May 22, 2012, at 11:48 AM, Martin Thomson wrote: > >> On 22 May 2012 06:08, Rosen, Brian wrote: >>> "Link" isn't a sip header is it? >> >> and? > Can't use it. We sit at the cusp of what can and can't be used. If we decide we need it - and agree - we can use it. It was simply a suggestion, my preference is for explicit links from content, which offer clearer semantics. > Not sure how this would work. =C2=A0One CID in Call Info points to the fi= rst block, with that block having a CID to another block? That's the basic idea. >>> Can we answer the question of what having multiple MIME types buys us? >> Not having to define "an XML structure for the blocks?" > You mean one complex type with an extensible list of blocks? That's pretty much useless once you hit unique particle attribution: you end up with the same sort of generic container that...multipart MIME provides. And then you have to uses XPointer to get your references right, which isn't great. >> Several? =C2=A0Or just one: clearer linkage between units of information= . > No, the XML also means the Call Info is crowded. =C2=A0Instead of one URI= per AdditionalCallData, there is one per block. Unless you do as I suggest above. --Martin From mlinsner@cisco.com Wed May 30 10:15:34 2012 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310C11E8086 for ; Wed, 30 May 2012 10:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCP271FBhDm2 for ; Wed, 30 May 2012 10:15:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6196E21F8633 for ; Wed, 30 May 2012 10:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=2569; q=dns/txt; s=iport; t=1338398128; x=1339607728; h=date:subject:from:to:message-id:mime-version; bh=XLe5XkhT1ViUbtkL/NivSvJdVUFxtyzoX9u/4kxweXo=; b=av0xQZ2fnyieLPZc25iFlj7/HSFOgDfydS12WSFnT4X4/GtXeVMqFJmF jizS/VkGPYw/XzqOfQ4HhKZa4xrhU3PDJjBRn/BLg4x+yPVkU/vRWSPEP 3yl1zIfRGw0rRw/fmD3lNUw5q78VxDcu9lPsttw/6N9wKfZMtGIuoZnEI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAEBVxk+tJXHB/2dsb2JhbABEgkVYqAEBh2qBCIEHgh4SASpPDAGBHhwZh2kLl3aBKKADix+FKAOVGIEPhECIPoFmgnyBQw X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208,217";a="87993168" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 30 May 2012 17:15:27 +0000 Received: from [10.116.195.114] (rtp-mlinsner-8711.cisco.com [10.116.195.114]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q4UHFOWK018369 for ; Wed, 30 May 2012 17:15:27 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 30 May 2012 13:15:22 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: Adding top-level service labels Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3421228527_1143033" Subject: [Ecrit] Adding top-level service labels X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:15:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3421228527_1143033 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, In an effort to clean-up some old work, we've reviewed the list discussion around changing the process for adding top-level service labels. See the list discussion thread starting at: http://www.ietf.org/mail-archive/web/ecrit/current/msg07888.html Although the discussion didn't end with a clear consensus on how to deal with this issue, we (the chairs) believe there is enough interest to forge ahead with a milestone and work on this issue. Our plan is to ask Andrea/Henning to revive draft (http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00) and use that a the starting point for the work. If you disagree that the WG should take on this work or start with an update of this draft, please send your comments to the list by June 6th. Roger and Marc --B_3421228527_1143033 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
All,

In an effort to clean-up some old work, we've reviewed the list discussion= around changing the process for adding top-level service labels.  See = the list discussion thread starting at:


Although the discussion didn't end with a clear consensus on how to de= al with this issue, we (the chairs) believe there is enough interest to forg= e ahead with a milestone and work on this issue.

Ou= r plan is to ask Andrea/Henning to revive draft (http://tools.ietf.org/html= /draft-forte-ecrit-service-urn-policy-00) and use that a the starting po= int for the work.

If you disagree that the WG shoul= d take on this work or start with an update of this draft, please send your = comments to the list by June 6th.

Roger and Marc --B_3421228527_1143033--