From mailman-bounces@core3.amsl.com Fri Feb 1 06:10:23 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C487F28E50E for ; Fri, 1 Feb 2008 06:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAILKIAAkn3J for ; Fri, 1 Feb 2008 06:06:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070EB293058 for ; Fri, 1 Feb 2008 05:42:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ecrit-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:49 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ecrit/ecrit-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:10:38 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8DF3A6979 for ; Fri, 1 Feb 2008 06:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks88nNZjtNFj for ; Fri, 1 Feb 2008 06:05:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A85295E5F for ; Fri, 1 Feb 2008 05:42:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ecrit-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:48 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/ecrit/ecrit-archive%40megatron.ietf.org From ecrit-bounces@ietf.org Fri Feb 1 06:38:55 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C4529399D; Fri, 1 Feb 2008 06:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8JB3uk6HyNz; Fri, 1 Feb 2008 06:38:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1BD2A2F22; Fri, 1 Feb 2008 06:15:29 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A507C294293; Fri, 1 Feb 2008 05:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKxnDkug8L+3; Fri, 1 Feb 2008 05:51:07 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id AE75F28CBA4; Fri, 1 Feb 2008 05:26:41 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKvwB-00040Z-0R; Fri, 01 Feb 2008 07:28:11 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> Date: Fri, 1 Feb 2008 08:28:11 -0500 Message-ID: <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcAADVkgIAAdh5Wg 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 Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have some conflicting thoughts on this. It should be possible for a phone to send the call itself direct to the PSAP URI. The emergency call system should be able to handle that. On the other hand, carriers are generally thought of as useful partners by the emergency call system, and a recommendation that they be bypassed won't be appreciated by those folks even if there is an engineering argument that it's more efficient. Part of the reason is track and trace. Part of the reason is subscriber name and address. The big one is identity. Carriers provide reasonably verified identity. So, on balance, I think phonebcp should say, as it does now, that phones pass emergency calls to wherever they normally pass outbound calls. Frankly, the number of special processing steps we're asking phones to do for emergency calls is getting too high. I'd rather figure out ways to remove some special processing, not add more. Presently phones have to: *Get location and do LoST lookups *Watch for emergency dial strings *Add Geolocation headers, PSAP URIs and service urns *Disable some features *Not send bye If anything, that list is too long. As with most things like it, the more special stuff you do for emergencies, the less likely it is to actually work in an emergency. Generally, I think phones knowing where they are is a good thing in the big picture, and having the phone do all dial plan interpretation is the right thing also. So the real special processing is the last three. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, January 31, 2008 11:31 PM > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > We need to note the points where we are actually in agreement. Perhaps > there was an inference that we weren't with respect to the following: > > 1. The access network provider (the one that gets you onto the Internet) > should not be responsible for providing any kind of emergency call > processing. > > 2. The access network provider does need to provide a location service > that can be used for emergency call processing > > 3. The LoST service with the translations for that point of access needs > to be available from that point of access. Somebody is actually > responsible for the physical infrastructure that supports it but it > doesn't have to be the access provider - just so long as it's > discoverable from the access. > > I am in agreement with these principles - nothing I said below was > inconsistent with them. > > Direct to PSAP-URI calling is a supported mode of operation, yes? What > distinguishes between the circumstance where a device does this versus > trying to send the call through its VSP? It may be because the specific > implementation of the VoIP client that the caller is using simply > decides to do that. This includes the possibility that the client > doesn't know its actually an emergency call and leaves it up to the VSP > to do the digit analysis. It includes the case where the VoIP client > doesn't know anything about ECRIT and just sends all calls to the VSP. > > I don't think in this decision that's governed by the nature of the > access is there? If not, discussion about NATs etc seem irrelevant to > me. In fact, my standard "nomadic" VoIP service is Skype. In my office, > our IS masters don't let Skype work. It's very difficult to guarantee > that arbitrary VSP access is going to work from arbitrary access points. > It's much simpler to guarantee that SIP calling directly to the relevant > PSAP URIs for those points of access will always work. I think details > such as whether an enterprise VoIP server is the thing that makes the > PSAP call is just that - a detail. In such an environment, the clients > and the server are part of the same package anyway. It's not at all the > same situation as bringing Vonage, for example, into the picture when an > emergency call is made. > > When it comes to phone BCP, it should be quite possible to say that the > phone client should always work to the local network and direct the call > directly to the PSAP. This, in my view, is what pure-ECRIT should be > about. It should also be possible to say that if the phone can only dial > digits that are processed by the VSP, then subsequent behaviour is out > of scope (but here's some suggestions). The NENA i2 architecture already > has this covered and it's being picked up internationally anyway. It's > an interim architecture; it'll go away as jurisdictions implement LoST > and IP PSAP services and VoIP clients learn to use those functions. It > would be preferable that, when the interim solution does disappear, that > VSPs no longer need to have a role or responsibility for providing > emergency access. It would be better for all concerned if they did not. > > Here's the logic: > > 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke > i2. > 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 > 3.Phone can find LIS and LoST - call PSAP directly > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 1 February 2008 3:56 AM > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > First my response to the original question: > > IMS is special because the visited network is in the call path. When > the > visited network has active elements in the call path, it makes sense to > have > the visited network handle emergency calls. Note that there are lots > and > lots of complications with this. Take for example, call back. What you > want is to have both a Contact URI that will route back to the device > that > placed the call, and you need a real AoR you can use to reach the caller > later on. The visited network would have to provide both. > > When the visited network is not in the call path, you have to use the > VSP. > > > Then my response to Martin: > > It's been said that the emergency service wants the subscriber details > > from the VSP. A caller can have subscriptions to lots of Internet > > services that also don't need to be involved in the call. Should we > also > > make emergency calling dependent on them? > No. However, involving the actual carrier that provides the service > that is > placing the call is essential. Bypassing the carrier that provides the > service that places the call is pretty tough, except in unusual > circumstances. IMS is an example of an unusual circumstance because > they > put the visited network in the call path. Very few other systems do > that. > > I'm very conscious of what we must ask the access network to provide. > This > has lots of implications on engineering as well as cost and liability. > Unless the device itself can locate itself without assistance of the > access > network, we ask the access network to provide location (or at least > location > assistance). We ask them to provide access to a LoST server. I want to > stop there. That's all they have to do. > > > > > I don't think it has to be the same as IMS. IMS requires a > co-operative > > E-CSCF that is actually part of the access network. With LoST and a > > suitable emergency proxy, there doesn't have to be any dependency on > the > > access network to also provide call processing. > IMS is different as discussed above. > > > > > Not involving the VSP in the call does not mean that the caller cannot > > provide callback details (in principle, they could provide multiple > > callback options). I'd also be interested in a discussion around > > providing an automatic presence subscription from the emergency > network > > itself - with a temporary callback number. As long as the emergency > > calling device is attached to the Internet, it should be able to stay > > registered with that temporary subscription and also do regular > location > > updates to it. > I think the notion that we can define the characteristics of an > emergency > proxy that works for all devices is not feasible. Let me cite a few > examples: > > Emergency call from AOL/MSN/Yahoo. We would have to require the device > to > implement SIP/SIMPLE. > > Emergency call from OnStar. Who is the emergency proxy provider? > > Emergency call from "Help I've fallen and I can't get up" buttons with > two > way audio. They would have to meet all of the phonebcp requirements. > > Call backs are an issue. You can get a contact URI, but you can't get > an > AoR you have any trust in for any call. > > But the biggest problem is that I think any attempt to give the access > network the obligation and the liability to totally handle emergency > calls > will not fly. > > > > > > Many of the most convoluted issues that have arisen in this forum have > > been around the challenges that having the VSP involved in call > routing > > introduces (the need for forest guides etc). Since direct-calling is a > > valid option, I know I'd prefer an emergency calling client that > always > > worked that way. > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 4 05:54:50 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0483A6F71; Mon, 4 Feb 2008 05:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZaaRuXOk5gx; Mon, 4 Feb 2008 05:54:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905EC3A6F5D; Mon, 4 Feb 2008 05:54:47 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA47A3A6D81; Mon, 4 Feb 2008 05:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUDxGcVI0AEj; Mon, 4 Feb 2008 05:54:43 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B147A3A6F4F; Mon, 4 Feb 2008 05:54:43 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JM1nu-0007mS-Oo; Mon, 04 Feb 2008 07:56:11 -0600 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> Date: Mon, 4 Feb 2008 08:56:11 -0500 Message-ID: <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcAADVkgIAAdh5WgAIFfjJAAFyluAA== 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 Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think we will have to agree to disagree. I noticed you ignored identity. Anyone else think the only way emergency calls should (normally) work is to have all devices place emergency calls direct to PSAPs with (normally) no proxies? Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Sunday, February 03, 2008 10:20 PM > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > Hi Brian, > > This seems to suggest that there's a complexity argument for saying > phones should pass emergency calls however they "normally" make calls. > > If we have a precept that says it must always be possible to make a call > directly to the PSAP URI from a given point of access, then also > supporting call routing via the VSP can only add complexity. Issues such > as how do VSPs that don't use SIP work, or recognizing dial strings when > the VSP doesn't know what the intent and regional conventions are, or > the VSP finding the right LoST server when it's not in a position to > perform local discovery are all complexities that arise by not sending > the call directly to the PSAP URI. They are all things that make the > handling of an emergency call more brittle. > > The question of what is "normal" can only become more fuzzy over time as > well. Increasingly we just have IP-enabled multimedia devices that can > have an arbitrary number of service clients/subscriptions hosted on > them. I think this is really the environment that ECRIT should be > focussed on. It's the device that should know how to initiate and > support emergency calling - not the potential multitude of other service > clients hosted on that device. > > Ideally, all devices should have practically the same implementation > that knows how to do local location and LoST service discovery and to > subsequently contact the local emergency service. Dedicated VSP client > devices could integrate such a reference implementation, provide a > mechanism to call it, and only invoke VSP-specific emergency handling if > (as I described below) the local network does not appear to support the > necessary ECRIT functions. This should result in less complexity over > time with more and more consistent implementations from the device > perspective as well as the network perspective. As long as the reference > client works, then the network is doing the right thing. > > "Track and trace" become Internet access issues. We get to the point > where we have optimal assurance that the access is local to the > emergency jurisdiction and we have all the same wherewithal with respect > to this function as we do with the PSTN - without needing to think that > VSPs are important to it. > > I think everything that ECRIT has is just about right. I just think that > the mantra about "normal call processing" has things the wrong way > around. i.e I have the opposite view to what you expressed, Brian. > Ultimately, I think VSP involvement should go away - and not actually be > the recommended approach in perpetuity. The VSP considerations should > become recommendations that are ultimately deprecated. > > Note - I understand very well that redoing documentation and recanting > on policy is a demotivator. However, now is always the best time to > change if we don't have things quite right. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Saturday, 2 February 2008 12:28 AM > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Ecrit] Emergency Calls & VoIP Peering > > I have some conflicting thoughts on this. It should be possible for a > phone > to send the call itself direct to the PSAP URI. The emergency call > system > should be able to handle that. > > On the other hand, carriers are generally thought of as useful partners > by > the emergency call system, and a recommendation that they be bypassed > won't > be appreciated by those folks even if there is an engineering argument > that > it's more efficient. > > Part of the reason is track and trace. Part of the reason is subscriber > name and address. The big one is identity. Carriers provide reasonably > verified identity. > > So, on balance, I think phonebcp should say, as it does now, that phones > pass emergency calls to wherever they normally pass outbound calls. > Frankly, the number of special processing steps we're asking phones to > do > for emergency calls is getting too high. I'd rather figure out ways to > remove some special processing, not add more. > > Presently phones have to: > *Get location and do LoST lookups > *Watch for emergency dial strings > *Add Geolocation headers, PSAP URIs and service urns > *Disable some features > *Not send bye > > If anything, that list is too long. As with most things like it, the > more > special stuff you do for emergencies, the less likely it is to actually > work > in an emergency. > > Generally, I think phones knowing where they are is a good thing in the > big > picture, and having the phone do all dial plan interpretation is the > right > thing also. So the real special processing is the last three. > > Brian > > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Thursday, January 31, 2008 11:31 PM > > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > We need to note the points where we are actually in agreement. Perhaps > > there was an inference that we weren't with respect to the following: > > > > 1. The access network provider (the one that gets you onto the > Internet) > > should not be responsible for providing any kind of emergency call > > processing. > > > > 2. The access network provider does need to provide a location service > > that can be used for emergency call processing > > > > 3. The LoST service with the translations for that point of access > needs > > to be available from that point of access. Somebody is actually > > responsible for the physical infrastructure that supports it but it > > doesn't have to be the access provider - just so long as it's > > discoverable from the access. > > > > I am in agreement with these principles - nothing I said below was > > inconsistent with them. > > > > Direct to PSAP-URI calling is a supported mode of operation, yes? What > > distinguishes between the circumstance where a device does this versus > > trying to send the call through its VSP? It may be because the > specific > > implementation of the VoIP client that the caller is using simply > > decides to do that. This includes the possibility that the client > > doesn't know its actually an emergency call and leaves it up to the > VSP > > to do the digit analysis. It includes the case where the VoIP client > > doesn't know anything about ECRIT and just sends all calls to the VSP. > > > > I don't think in this decision that's governed by the nature of the > > access is there? If not, discussion about NATs etc seem irrelevant to > > me. In fact, my standard "nomadic" VoIP service is Skype. In my > office, > > our IS masters don't let Skype work. It's very difficult to guarantee > > that arbitrary VSP access is going to work from arbitrary access > points. > > It's much simpler to guarantee that SIP calling directly to the > relevant > > PSAP URIs for those points of access will always work. I think details > > such as whether an enterprise VoIP server is the thing that makes the > > PSAP call is just that - a detail. In such an environment, the clients > > and the server are part of the same package anyway. It's not at all > the > > same situation as bringing Vonage, for example, into the picture when > an > > emergency call is made. > > > > When it comes to phone BCP, it should be quite possible to say that > the > > phone client should always work to the local network and direct the > call > > directly to the PSAP. This, in my view, is what pure-ECRIT should be > > about. It should also be possible to say that if the phone can only > dial > > digits that are processed by the VSP, then subsequent behaviour is out > > of scope (but here's some suggestions). The NENA i2 architecture > already > > has this covered and it's being picked up internationally anyway. It's > > an interim architecture; it'll go away as jurisdictions implement LoST > > and IP PSAP services and VoIP clients learn to use those functions. It > > would be preferable that, when the interim solution does disappear, > that > > VSPs no longer need to have a role or responsibility for providing > > emergency access. It would be better for all concerned if they did > not. > > > > Here's the logic: > > > > 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke > > i2. > > 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 > > 3.Phone can find LIS and LoST - call PSAP directly > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 1 February 2008 3:56 AM > > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > First my response to the original question: > > > > IMS is special because the visited network is in the call path. When > > the > > visited network has active elements in the call path, it makes sense > to > > have > > the visited network handle emergency calls. Note that there are lots > > and > > lots of complications with this. Take for example, call back. What > you > > want is to have both a Contact URI that will route back to the device > > that > > placed the call, and you need a real AoR you can use to reach the > caller > > later on. The visited network would have to provide both. > > > > When the visited network is not in the call path, you have to use the > > VSP. > > > > > > Then my response to Martin: > > > It's been said that the emergency service wants the subscriber > details > > > from the VSP. A caller can have subscriptions to lots of Internet > > > services that also don't need to be involved in the call. Should we > > also > > > make emergency calling dependent on them? > > No. However, involving the actual carrier that provides the service > > that is > > placing the call is essential. Bypassing the carrier that provides > the > > service that places the call is pretty tough, except in unusual > > circumstances. IMS is an example of an unusual circumstance because > > they > > put the visited network in the call path. Very few other systems do > > that. > > > > I'm very conscious of what we must ask the access network to provide. > > This > > has lots of implications on engineering as well as cost and liability. > > Unless the device itself can locate itself without assistance of the > > access > > network, we ask the access network to provide location (or at least > > location > > assistance). We ask them to provide access to a LoST server. I want > to > > stop there. That's all they have to do. > > > > > > > > I don't think it has to be the same as IMS. IMS requires a > > co-operative > > > E-CSCF that is actually part of the access network. With LoST and a > > > suitable emergency proxy, there doesn't have to be any dependency on > > the > > > access network to also provide call processing. > > IMS is different as discussed above. > > > > > > > > Not involving the VSP in the call does not mean that the caller > cannot > > > provide callback details (in principle, they could provide multiple > > > callback options). I'd also be interested in a discussion around > > > providing an automatic presence subscription from the emergency > > network > > > itself - with a temporary callback number. As long as the emergency > > > calling device is attached to the Internet, it should be able to > stay > > > registered with that temporary subscription and also do regular > > location > > > updates to it. > > I think the notion that we can define the characteristics of an > > emergency > > proxy that works for all devices is not feasible. Let me cite a few > > examples: > > > > Emergency call from AOL/MSN/Yahoo. We would have to require the > device > > to > > implement SIP/SIMPLE. > > > > Emergency call from OnStar. Who is the emergency proxy provider? > > > > Emergency call from "Help I've fallen and I can't get up" buttons with > > two > > way audio. They would have to meet all of the phonebcp requirements. > > > > Call backs are an issue. You can get a contact URI, but you can't get > > an > > AoR you have any trust in for any call. > > > > But the biggest problem is that I think any attempt to give the access > > network the obligation and the liability to totally handle emergency > > calls > > will not fly. > > > > > > > > > > Many of the most convoluted issues that have arisen in this forum > have > > > been around the challenges that having the VSP involved in call > > routing > > > introduces (the need for forest guides etc). Since direct-calling is > a > > > valid option, I know I'd prefer an emergency calling client that > > always > > > worked that way. > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 4 08:39:21 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C38F3A700F; Mon, 4 Feb 2008 08:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, SARE_HIRISK_FORGED_ATT=0.184, USER_IN_WHITELIST=-100] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8W4FiGe+AYK; Mon, 4 Feb 2008 08:39:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0793A6FF8; Mon, 4 Feb 2008 08:39:15 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BC53A6FB3; Mon, 4 Feb 2008 08:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfROC3H4lHrv; Mon, 4 Feb 2008 08:39:08 -0800 (PST) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id E874D3A6FB9; Mon, 4 Feb 2008 08:39:07 -0800 (PST) Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.194350375; Mon, 04 Feb 2008 11:40:12 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 Feb 2008 11:40:12 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 Feb 2008 11:40:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 11:40:11 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0741F1FF@crexc41p> In-Reply-To: <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcAADVkgIAAdh5WgAIFfjJAAFyluAAAEN9sQ References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com><015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Dawson, Martin" , "Hannes Tschofenig" , , "ECRIT" X-OriginalArrivalTime: 04 Feb 2008 16:40:12.0565 (UTC) FILETIME=[9CC8F450:01C8674C] Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that for many years to come, the "PSAP URI" will be some sort of "tel uri", which will require the call to be sent to a PSTN gateway. Currently, there is no way for a SIP client to get a call to the PSTN, without going through some sort of VSP with a PSTN gateway. PSAP providers who don't immediately move over to VoIP, should not be expected to incur the cost of having/maintaining VoIP infrastructure (i.e., a PSTN gateway) in order for the ecrit architecture to work properly. Under no circumstances, should the access network be expected to provide a PSTN gateway. If the device has all the information needed to properly route the call to a PSAP, then I don't understand what it is that might break, if a VSP is asked to route the call. I'm looking at Martin's list of potential issues, and I don't really see how they apply: > how do VSPs that don't use SIP work Presumably, if the VSP doesn't do SIP, then the client associated with that VSP isn't a SIP client. It's highly likely that some random visited region will only support SIP, so it's unlikely that non-SIP clients will be supported, with or without the VSP. I don't understand this issue. If the device does have a SIP client, and that SIP client isn't registered with any SIP proxy, then I'm fine with saying it's ok for the device to try to route the call directly. > recognizing dial strings when > the VSP doesn't know what the intent and regional conventions are Direct routing can only work if the device is able to recognize dial strings. So, if a device recognizes dial strings, and properly forms the SIP messages (per phonebcp), it's not clear to me why sending the well-formed SIP message to the VSP (vs. directly) would force the VSP to have to recognize the original dial string. If the device doesn't recognize the dial string, then it won't be doing direct routing, in any case. > the VSP finding the right LoST server when it's not in a position to > perform local discovery Again, we need to only compare the cases of "send call to VSP" vs. "direct route call" when the device recognizes an emergency call and knows the route. If the device knows the route, then it shouldn't matter whether or not the VSP can get to or discover the LoST server. If the device doesn't know the route, then direct routing won't work, either. I don't see that any of these potential issues are real issues. Going back to my original point about needing access to a PSTN gateway in the foreseeable future, I think it's critical that "initialized" devices send emergency calls to their configured proxy, as they would with any other call. I'm happy to suggest that uninitialized devices with Internet access SHOULD directly route calls. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, February 04, 2008 8:56 AM To: 'Dawson, Martin'; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' Subject: Re: [Ecrit] Emergency Calls & VoIP Peering I think we will have to agree to disagree. I noticed you ignored identity. Anyone else think the only way emergency calls should (normally) work is to have all devices place emergency calls direct to PSAPs with (normally) no proxies? Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Sunday, February 03, 2008 10:20 PM > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > Hi Brian, > > This seems to suggest that there's a complexity argument for saying > phones should pass emergency calls however they "normally" make calls. > > If we have a precept that says it must always be possible to make a call > directly to the PSAP URI from a given point of access, then also > supporting call routing via the VSP can only add complexity. Issues such > as how do VSPs that don't use SIP work, or recognizing dial strings when > the VSP doesn't know what the intent and regional conventions are, or > the VSP finding the right LoST server when it's not in a position to > perform local discovery are all complexities that arise by not sending > the call directly to the PSAP URI. They are all things that make the > handling of an emergency call more brittle. > > The question of what is "normal" can only become more fuzzy over time as > well. Increasingly we just have IP-enabled multimedia devices that can > have an arbitrary number of service clients/subscriptions hosted on > them. I think this is really the environment that ECRIT should be > focussed on. It's the device that should know how to initiate and > support emergency calling - not the potential multitude of other service > clients hosted on that device. > > Ideally, all devices should have practically the same implementation > that knows how to do local location and LoST service discovery and to > subsequently contact the local emergency service. Dedicated VSP client > devices could integrate such a reference implementation, provide a > mechanism to call it, and only invoke VSP-specific emergency handling if > (as I described below) the local network does not appear to support the > necessary ECRIT functions. This should result in less complexity over > time with more and more consistent implementations from the device > perspective as well as the network perspective. As long as the reference > client works, then the network is doing the right thing. > > "Track and trace" become Internet access issues. We get to the point > where we have optimal assurance that the access is local to the > emergency jurisdiction and we have all the same wherewithal with respect > to this function as we do with the PSTN - without needing to think that > VSPs are important to it. > > I think everything that ECRIT has is just about right. I just think that > the mantra about "normal call processing" has things the wrong way > around. i.e I have the opposite view to what you expressed, Brian. > Ultimately, I think VSP involvement should go away - and not actually be > the recommended approach in perpetuity. The VSP considerations should > become recommendations that are ultimately deprecated. > > Note - I understand very well that redoing documentation and recanting > on policy is a demotivator. However, now is always the best time to > change if we don't have things quite right. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Saturday, 2 February 2008 12:28 AM > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Ecrit] Emergency Calls & VoIP Peering > > I have some conflicting thoughts on this. It should be possible for a > phone > to send the call itself direct to the PSAP URI. The emergency call > system > should be able to handle that. > > On the other hand, carriers are generally thought of as useful partners > by > the emergency call system, and a recommendation that they be bypassed > won't > be appreciated by those folks even if there is an engineering argument > that > it's more efficient. > > Part of the reason is track and trace. Part of the reason is subscriber > name and address. The big one is identity. Carriers provide reasonably > verified identity. > > So, on balance, I think phonebcp should say, as it does now, that phones > pass emergency calls to wherever they normally pass outbound calls. > Frankly, the number of special processing steps we're asking phones to > do > for emergency calls is getting too high. I'd rather figure out ways to > remove some special processing, not add more. > > Presently phones have to: > *Get location and do LoST lookups > *Watch for emergency dial strings > *Add Geolocation headers, PSAP URIs and service urns > *Disable some features > *Not send bye > > If anything, that list is too long. As with most things like it, the > more > special stuff you do for emergencies, the less likely it is to actually > work > in an emergency. > > Generally, I think phones knowing where they are is a good thing in the > big > picture, and having the phone do all dial plan interpretation is the > right > thing also. So the real special processing is the last three. > > Brian > > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Thursday, January 31, 2008 11:31 PM > > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > We need to note the points where we are actually in agreement. Perhaps > > there was an inference that we weren't with respect to the following: > > > > 1. The access network provider (the one that gets you onto the > Internet) > > should not be responsible for providing any kind of emergency call > > processing. > > > > 2. The access network provider does need to provide a location service > > that can be used for emergency call processing > > > > 3. The LoST service with the translations for that point of access > needs > > to be available from that point of access. Somebody is actually > > responsible for the physical infrastructure that supports it but it > > doesn't have to be the access provider - just so long as it's > > discoverable from the access. > > > > I am in agreement with these principles - nothing I said below was > > inconsistent with them. > > > > Direct to PSAP-URI calling is a supported mode of operation, yes? What > > distinguishes between the circumstance where a device does this versus > > trying to send the call through its VSP? It may be because the > specific > > implementation of the VoIP client that the caller is using simply > > decides to do that. This includes the possibility that the client > > doesn't know its actually an emergency call and leaves it up to the > VSP > > to do the digit analysis. It includes the case where the VoIP client > > doesn't know anything about ECRIT and just sends all calls to the VSP. > > > > I don't think in this decision that's governed by the nature of the > > access is there? If not, discussion about NATs etc seem irrelevant to > > me. In fact, my standard "nomadic" VoIP service is Skype. In my > office, > > our IS masters don't let Skype work. It's very difficult to guarantee > > that arbitrary VSP access is going to work from arbitrary access > points. > > It's much simpler to guarantee that SIP calling directly to the > relevant > > PSAP URIs for those points of access will always work. I think details > > such as whether an enterprise VoIP server is the thing that makes the > > PSAP call is just that - a detail. In such an environment, the clients > > and the server are part of the same package anyway. It's not at all > the > > same situation as bringing Vonage, for example, into the picture when > an > > emergency call is made. > > > > When it comes to phone BCP, it should be quite possible to say that > the > > phone client should always work to the local network and direct the > call > > directly to the PSAP. This, in my view, is what pure-ECRIT should be > > about. It should also be possible to say that if the phone can only > dial > > digits that are processed by the VSP, then subsequent behaviour is out > > of scope (but here's some suggestions). The NENA i2 architecture > already > > has this covered and it's being picked up internationally anyway. It's > > an interim architecture; it'll go away as jurisdictions implement LoST > > and IP PSAP services and VoIP clients learn to use those functions. It > > would be preferable that, when the interim solution does disappear, > that > > VSPs no longer need to have a role or responsibility for providing > > emergency access. It would be better for all concerned if they did > not. > > > > Here's the logic: > > > > 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke > > i2. > > 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 > > 3.Phone can find LIS and LoST - call PSAP directly > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 1 February 2008 3:56 AM > > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > First my response to the original question: > > > > IMS is special because the visited network is in the call path. When > > the > > visited network has active elements in the call path, it makes sense > to > > have > > the visited network handle emergency calls. Note that there are lots > > and > > lots of complications with this. Take for example, call back. What > you > > want is to have both a Contact URI that will route back to the device > > that > > placed the call, and you need a real AoR you can use to reach the > caller > > later on. The visited network would have to provide both. > > > > When the visited network is not in the call path, you have to use the > > VSP. > > > > > > Then my response to Martin: > > > It's been said that the emergency service wants the subscriber > details > > > from the VSP. A caller can have subscriptions to lots of Internet > > > services that also don't need to be involved in the call. Should we > > also > > > make emergency calling dependent on them? > > No. However, involving the actual carrier that provides the service > > that is > > placing the call is essential. Bypassing the carrier that provides > the > > service that places the call is pretty tough, except in unusual > > circumstances. IMS is an example of an unusual circumstance because > > they > > put the visited network in the call path. Very few other systems do > > that. > > > > I'm very conscious of what we must ask the access network to provide. > > This > > has lots of implications on engineering as well as cost and liability. > > Unless the device itself can locate itself without assistance of the > > access > > network, we ask the access network to provide location (or at least > > location > > assistance). We ask them to provide access to a LoST server. I want > to > > stop there. That's all they have to do. > > > > > > > > I don't think it has to be the same as IMS. IMS requires a > > co-operative > > > E-CSCF that is actually part of the access network. With LoST and a > > > suitable emergency proxy, there doesn't have to be any dependency on > > the > > > access network to also provide call processing. > > IMS is different as discussed above. > > > > > > > > Not involving the VSP in the call does not mean that the caller > cannot > > > provide callback details (in principle, they could provide multiple > > > callback options). I'd also be interested in a discussion around > > > providing an automatic presence subscription from the emergency > > network > > > itself - with a temporary callback number. As long as the emergency > > > calling device is attached to the Internet, it should be able to > stay > > > registered with that temporary subscription and also do regular > > location > > > updates to it. > > I think the notion that we can define the characteristics of an > > emergency > > proxy that works for all devices is not feasible. Let me cite a few > > examples: > > > > Emergency call from AOL/MSN/Yahoo. We would have to require the > device > > to > > implement SIP/SIMPLE. > > > > Emergency call from OnStar. Who is the emergency proxy provider? > > > > Emergency call from "Help I've fallen and I can't get up" buttons with > > two > > way audio. They would have to meet all of the phonebcp requirements. > > > > Call backs are an issue. You can get a contact URI, but you can't get > > an > > AoR you have any trust in for any call. > > > > But the biggest problem is that I think any attempt to give the access > > network the obligation and the liability to totally handle emergency > > calls > > will not fly. > > > > > > > > > > Many of the most convoluted issues that have arisen in this forum > have > > > been around the challenges that having the VSP involved in call > > routing > > > introduces (the need for forest guides etc). Since direct-calling is > a > > > valid option, I know I'd prefer an emergency calling client that > > always > > > worked that way. > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 4 09:06:54 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D773F3A6F59; Mon, 4 Feb 2008 09:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.667 X-Spam-Level: ** X-Spam-Status: No, score=2.667 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S6cLTjzlr4F; Mon, 4 Feb 2008 09:06:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E172D3A6EB0; Mon, 4 Feb 2008 09:06:50 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59DC3A6EA9 for ; Mon, 4 Feb 2008 09:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAY77SgtmkaI for ; Mon, 4 Feb 2008 09:06:48 -0800 (PST) Received: from zeke.ecotroph.net (zeke.hxr.us [69.31.8.124]) by core3.amsl.com (Postfix) with ESMTP id B5C1A3A6DF7 for ; Mon, 4 Feb 2008 09:06:48 -0800 (PST) Received: from [192.136.136.45] ([::ffff:192.136.136.45]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 04 Feb 2008 12:08:22 -0500 id 0158870D.47A74686.00005350 Message-Id: From: Andrew Newton To: "Thomson, Martin" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 4 Feb 2008 12:08:21 -0500 References: X-Mailer: Apple Mail (2.915) Cc: ECRIT Subject: Re: [Ecrit] LoST schema omission X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jan 7, 2008, at 11:52 PM, Thomson, Martin wrote: > The problem is that the "locationUsed" element (and all that is > related to its use) is not defined in the schema. Yup. That's a problem. > div { > findServiceResponse = > element findServiceResponse { > + mapping+, locationValidation?, commonResponsePattern, > locationUsed? > - mapping+, locationValidation?, commonResponsePattern > } > listServicesResponse = > element listServicesResponse { serviceList, commonResponsePattern } > listServicesByLocationResponse = > element listServicesByLocationResponse { > + serviceList, commonResponsePattern, locationUsed? > - serviceList, commonResponsePattern > } > getServiceBoundaryResponse = > element getServiceBoundaryResponse { > serviceBoundary, commonResponsePattern > } > } > > Then add the following: > > ## The location information used to generate the response > div { > locationUsed = element locationUsed { > attribute id { xsd:NCName } | locationInformation > } > } Done, except: I placed the cardinality in the locationUsed pattern. Though Relax NG is powerful and can do the loc info echo, I don't think we should complicate things to that degree. The ID is enough. > div { > findService = > element findService { > + requestLocation, > - element location { locationInformation }+, > commonRequestPattern, > attribute validateLocation { > xsd:boolean >> a:defaultValue [ "false" ] > }?, > attribute serviceBoundary { > ("reference" | "value") >> a:defaultValue [ "reference" ] > }?, > attribute recursive { xsd:boolean >> a:defaultValue > [ "false" ] }? > } > listServices = element listServices { commonRequestPattern } > listServicesByLocation = > element listServicesByLocation { > + requestLocation, > - element location { locationInformation }*, > commonRequestPattern, > attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? > } > getServiceBoundary = > element getServiceBoundary { serviceBoundaryKey, extensionPoint } > } > > Then add the definition as so: > > ## Location, used by findService and listServicesByLocation > div { > requestLocation = element location { > attribute id { xsd:NCName }?, locationInformation > }+ > } Done. > (Note: It seems that you intended to have the cardinality of the > location element in "listServicesByLocation" as 1..n, rather than > 0..n. The text in Section 11 states "one or more > elements". I've assumed that here, if not, then add a trailing "?" > to the line in "listServicesByLocation".) Nope, looks like you found a mistake. Henning owes you a beer. > I haven't used xsd:ID. It might be more appropriate to use the ID > type defined in "http://relaxng.org/ns/compatibility/datatypes/0.9", > but that seems a little under-defined based on what I'm reading > right now. Given that the URL returns 404, I'd say yes to "underdefined". I think your definition is good. > I also recommend changing the type of the service number to be based > on xsd:token to allow for non-meaningful whitespace. Based on the > given pattern, whitespace is illegal ( 911 serviceNumber> == bad, for more than one reason). That is > unintuitive, so a small change is appropriate: > > element serviceNumber { > xsd:string { pattern = "[0-9*#]+" } > }?, > -> > element serviceNumber { > xsd:token { pattern = "[0-9*#]+" } > }?, Agreed. Done. > The same goes for "message" and maybe "appUniqueString". xsd:string > should be used rarely, unless you particularly like whitespace > nightmares (see [1]). Given that message is essentially free form text, I don't see how it makes a difference. But I see no harm. Done. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 4 10:19:19 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCCB3A7009; Mon, 4 Feb 2008 10:19:19 -0800 (PST) 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 core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo2+W90i+Xnw; Mon, 4 Feb 2008 10:19:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4546F3A6F90; Mon, 4 Feb 2008 10:19:18 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754123A6FF5; Mon, 4 Feb 2008 10:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcJ8eXAHFJnu; Mon, 4 Feb 2008 10:19:15 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 800EB3A6DF7; Mon, 4 Feb 2008 10:19:14 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m14IJGKF000270; Mon, 4 Feb 2008 12:20:30 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 12:20:24 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Feb 2008 19:20:21 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Feb 2008 19:20:21 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> In-Reply-To: <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEAA/tIiw References: <47A186C1.7080004@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> From: "DRAGE, Keith \(Keith\)" To: "Brian Rosen" , "Stark, Barbara" , "Dawson, Martin" , "Hannes Tschofenig" , , "ECRIT" X-OriginalArrivalTime: 04 Feb 2008 18:20:21.0735 (UTC) FILETIME=[9A878770:01C8675A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The access network in 3GPP is the part of the network that provides the radio access and the first level of mobility management. From there you have the access network and part of the core network providing IP connectivity to the first element that appears at the SIP layer. That IP connectivity can end you up in the local network or the home network. I would suggest you are probably looking for something like IMS local network. Regards Keith > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, January 31, 2008 5:10 PM > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; > speermint@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > I made the same assumption, which I know to be wrong. Thank > you for correcting us. Is "3GPP Access Network" the right > terminology for the kind of network where the visited network > provides the E-CSCF? > > Brian > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, January 31, 2008 12:05 PM > > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > snip... > > > IMS requires a co-operative > > > E-CSCF that is actually part of the access network. > > > > This is not true. Please don't confuse "IMS" with "3GPP > Access Network" > > and early 3GPP IMS definitions. They aren't the same. It's > absolutely > > possible to have an IMS core that exists only on the Internet, and > > that makes no assumptions about access networks. > > Barbara > > > > ***** > > > > The information transmitted is intended only for the person > or entity > > to which it is addressed and may contain confidential, proprietary, > > and/or privileged material. Any review, retransmission, > dissemination > > or other use of, or taking of any action in reliance upon this > > information by persons or entities other than the intended > recipient > > is prohibited. If you received this in error, please contact the > > sender and delete the material from all computers. GA622 > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 4 10:33:41 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6D83A6E43; Mon, 4 Feb 2008 10:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBG7j-MGK5EX; Mon, 4 Feb 2008 10:33:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83A03A6EDF; Mon, 4 Feb 2008 10:33:40 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A727D3A6EDF; Mon, 4 Feb 2008 10:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNnhao3qyX3F; Mon, 4 Feb 2008 10:33:38 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B7F7C3A6E43; Mon, 4 Feb 2008 10:33:38 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JM69n-0006yl-0R; Mon, 04 Feb 2008 12:35:03 -0600 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Stark, Barbara'" , "'Dawson, Martin'" , "'Hannes Tschofenig'" , , "'ECRIT'" References: <47A186C1.7080004@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> Date: Mon, 4 Feb 2008 13:35:05 -0500 Message-ID: <050b01c8675c$ab529f70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEAA/tIiwAIxm8LA= 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 Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm looking for a term of art when a local access network is IMS aware, and the local network provides the E-CSCF. Not all IMS systems do that, right? Is "IMS local network" a known term of art where I can expect an E-CSCF to handle emergency calls rather than forwarding to the home domain? Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Monday, February 04, 2008 1:20 PM > To: Brian Rosen; Stark, Barbara; Dawson, Martin; Hannes Tschofenig; > speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > The access network in 3GPP is the part of the network that provides the > radio access and the first level of mobility management. > > From there you have the access network and part of the core network > providing IP connectivity to the first element that appears at the SIP > layer. That IP connectivity can end you up in the local network or the > home network. > > I would suggest you are probably looking for something like IMS local > network. > > Regards > > Keith > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, January 31, 2008 5:10 PM > > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; > > speermint@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > I made the same assumption, which I know to be wrong. Thank > > you for correcting us. Is "3GPP Access Network" the right > > terminology for the kind of network where the visited network > > provides the E-CSCF? > > > > Brian > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, January 31, 2008 12:05 PM > > > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > > > snip... > > > > IMS requires a co-operative > > > > E-CSCF that is actually part of the access network. > > > > > > This is not true. Please don't confuse "IMS" with "3GPP > > Access Network" > > > and early 3GPP IMS definitions. They aren't the same. It's > > absolutely > > > possible to have an IMS core that exists only on the Internet, and > > > that makes no assumptions about access networks. > > > Barbara > > > > > > ***** > > > > > > The information transmitted is intended only for the person > > or entity > > > to which it is addressed and may contain confidential, proprietary, > > > and/or privileged material. Any review, retransmission, > > dissemination > > > or other use of, or taking of any action in reliance upon this > > > information by persons or entities other than the intended > > recipient > > > is prohibited. If you received this in error, please contact the > > > sender and delete the material from all computers. GA622 > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 4 11:39:34 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6639C3A7138; Mon, 4 Feb 2008 11:39:34 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csOm17aF66+G; Mon, 4 Feb 2008 11:39:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51763A7120; Mon, 4 Feb 2008 11:39:30 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377323A70C2; Mon, 4 Feb 2008 11:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckwbotJbtAMQ; Mon, 4 Feb 2008 11:39:28 -0800 (PST) Received: from pmesmtp01.mci.com (pmesmtp01.wcom.com [199.249.20.1]) by core3.amsl.com (Postfix) with ESMTP id 80DE23A70B2; Mon, 4 Feb 2008 11:39:20 -0800 (PST) Received: from pmismtp01.mcilink.com ([166.37.158.161]) by firewall.verizonbusiness.com (Iplanet MTA 5.2) with ESMTP id <0JVQ00432BZOTU@firewall.verizonbusiness.com>; Mon, 04 Feb 2008 19:40:53 +0000 (GMT) Received: from pmismtp01.mcilink.com ([127.0.0.1]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JVQ008FQC00BW@pmismtp01.mcilink.com>; Mon, 04 Feb 2008 19:40:48 +0000 (GMT) Received: from ASHSRV139.mcilink.com ([153.39.68.165]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JVQ0090FBZE67@pmismtp01.mcilink.com>; Mon, 04 Feb 2008 19:40:48 +0000 (GMT) Received: from ASHEVS002.mcilink.com ([153.39.71.1]) by ASHSRV139.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 04 Feb 2008 19:39:52 +0000 Date: Mon, 04 Feb 2008 19:39:51 +0000 From: "Dwight, Timothy M (Tim)" In-reply-to: <050b01c8675c$ab529f70$640fa8c0@cis.neustar.com> To: Brian Rosen , "DRAGE, Keith (Keith)" , "Stark, Barbara" , "Dawson, Martin" , Hannes Tschofenig , speermint@ietf.org, ECRIT Message-id: <092B2658AAB56A4D80836399A4C470310350E677@ASHEVS002.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [Ecrit] Emergency Calls & VoIP Peering Thread-index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAmQvbAAAGCaEAA/tIiwAIxm8LAAAUApcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <47A186C1.7080004@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA0741EDAA@crexc41p> <006601c8642c$25402ac0$640fa8c0@cis.neustar.com> <5D1A7985295922448D5550C94DE2918001BB864E@DEEXC1U01.de.lucent.com> <050b01c8675c$ab529f70$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 04 Feb 2008 19:39:52.0432 (UTC) FILETIME=[B6161F00:01C86765] Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org My assumption is that "local network" is fairly well understood to mean "the network with which the IP-CAN to which the user is currently attached, is associated". In other words the local network is the visited network if you're roaming, your home network otherwise. Do all IMS networks provide an E-CSCF? I doubt any do at the moment, because the standards are pretty new and not all details are resolved. If there were an E-CSCF in the "IMS local network" I would expect it to behave per TS 24.229, which indicates that the call is directed to the PSAP by the E-CSCF and is NOT forwarded to the home network. Tim > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Monday, February 04, 2008 12:35 PM > To: 'DRAGE, Keith (Keith)'; 'Stark, Barbara'; 'Dawson, > Martin'; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Ecrit] Emergency Calls & VoIP Peering > > I'm looking for a term of art when a local access network is > IMS aware, and > the local network provides the E-CSCF. Not all IMS systems > do that, right? > > Is "IMS local network" a known term of art where I can expect > an E-CSCF to > handle emergency calls rather than forwarding to the home domain? > > Brian > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Monday, February 04, 2008 1:20 PM > > To: Brian Rosen; Stark, Barbara; Dawson, Martin; Hannes Tschofenig; > > speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > The access network in 3GPP is the part of the network that > provides the > > radio access and the first level of mobility management. > > > > From there you have the access network and part of the core network > > providing IP connectivity to the first element that appears > at the SIP > > layer. That IP connectivity can end you up in the local > network or the > > home network. > > > > I would suggest you are probably looking for something like > IMS local > > network. > > > > Regards > > > > Keith > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, January 31, 2008 5:10 PM > > > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Hannes Tschofenig'; > > > speermint@ietf.org; 'ECRIT' > > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > > > I made the same assumption, which I know to be wrong. Thank > > > you for correcting us. Is "3GPP Access Network" the right > > > terminology for the kind of network where the visited network > > > provides the E-CSCF? > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, January 31, 2008 12:05 PM > > > > To: Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT > > > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > > > > > snip... > > > > > IMS requires a co-operative > > > > > E-CSCF that is actually part of the access network. > > > > > > > > This is not true. Please don't confuse "IMS" with "3GPP > > > Access Network" > > > > and early 3GPP IMS definitions. They aren't the same. It's > > > absolutely > > > > possible to have an IMS core that exists only on the > Internet, and > > > > that makes no assumptions about access networks. > > > > Barbara > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person > > > or entity > > > > to which it is addressed and may contain confidential, > proprietary, > > > > and/or privileged material. Any review, retransmission, > > > dissemination > > > > or other use of, or taking of any action in reliance upon this > > > > information by persons or entities other than the intended > > > recipient > > > > is prohibited. If you received this in error, please contact the > > > > sender and delete the material from all computers. GA622 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 6 15:46:50 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D573A7186; Wed, 6 Feb 2008 15:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4tQyKSExRlF; Wed, 6 Feb 2008 15:46:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616A53A6D5F; Wed, 6 Feb 2008 15:46:48 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F943A6D5F; Wed, 6 Feb 2008 15:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpdkyTJT3aJc; Wed, 6 Feb 2008 15:46:45 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 185263A6B2B; Wed, 6 Feb 2008 15:46:44 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_02_06_18_00_24 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 06 Feb 2008 18:00:24 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 17:48:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 17:48:13 -0600 Message-ID: In-Reply-To: <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcAADVkgIAAdh5WgAIFfjJA= References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: , "ECRIT" X-OriginalArrivalTime: 06 Feb 2008 23:48:15.0586 (UTC) FILETIME=[BDE27420:01C8691A] Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, This seems to suggest that there's a complexity argument for saying phones should pass emergency calls however they "normally" make calls. If we have a precept that says it must always be possible to make a call directly to the PSAP URI from a given point of access, then also supporting call routing via the VSP can only add complexity. Issues such as how do VSPs that don't use SIP work, or recognizing dial strings when the VSP doesn't know what the intent and regional conventions are, or the VSP finding the right LoST server when it's not in a position to perform local discovery are all complexities that arise by not sending the call directly to the PSAP URI. They are all things that make the handling of an emergency call more brittle. The question of what is "normal" can only become more fuzzy over time as well. Increasingly we just have IP-enabled multimedia devices that can have an arbitrary number of service clients/subscriptions hosted on them. I think this is really the environment that ECRIT should be focussed on. It's the device that should know how to initiate and support emergency calling - not the potential multitude of other service clients hosted on that device. Ideally, all devices should have practically the same implementation that knows how to do local location and LoST service discovery and to subsequently contact the local emergency service. Dedicated VSP client devices could integrate such a reference implementation, provide a mechanism to call it, and only invoke VSP-specific emergency handling if (as I described below) the local network does not appear to support the necessary ECRIT functions. This should result in less complexity over time with more and more consistent implementations from the device perspective as well as the network perspective. As long as the reference client works, then the network is doing the right thing. "Track and trace" become Internet access issues. We get to the point where we have optimal assurance that the access is local to the emergency jurisdiction and we have all the same wherewithal with respect to this function as we do with the PSTN - without needing to think that VSPs are important to it. I think everything that ECRIT has is just about right. I just think that the mantra about "normal call processing" has things the wrong way around. i.e I have the opposite view to what you expressed, Brian. Ultimately, I think VSP involvement should go away - and not actually be the recommended approach in perpetuity. The VSP considerations should become recommendations that are ultimately deprecated. Note - I understand very well that redoing documentation and recanting on policy is a demotivator. However, now is always the best time to change if we don't have things quite right. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Saturday, 2 February 2008 12:28 AM To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' Subject: Re: [Ecrit] Emergency Calls & VoIP Peering I have some conflicting thoughts on this. It should be possible for a phone to send the call itself direct to the PSAP URI. The emergency call system should be able to handle that. On the other hand, carriers are generally thought of as useful partners by the emergency call system, and a recommendation that they be bypassed won't be appreciated by those folks even if there is an engineering argument that it's more efficient. Part of the reason is track and trace. Part of the reason is subscriber name and address. The big one is identity. Carriers provide reasonably verified identity. So, on balance, I think phonebcp should say, as it does now, that phones pass emergency calls to wherever they normally pass outbound calls. Frankly, the number of special processing steps we're asking phones to do for emergency calls is getting too high. I'd rather figure out ways to remove some special processing, not add more. Presently phones have to: *Get location and do LoST lookups *Watch for emergency dial strings *Add Geolocation headers, PSAP URIs and service urns *Disable some features *Not send bye If anything, that list is too long. As with most things like it, the more special stuff you do for emergencies, the less likely it is to actually work in an emergency. Generally, I think phones knowing where they are is a good thing in the big picture, and having the phone do all dial plan interpretation is the right thing also. So the real special processing is the last three. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, January 31, 2008 11:31 PM > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > We need to note the points where we are actually in agreement. Perhaps > there was an inference that we weren't with respect to the following: > > 1. The access network provider (the one that gets you onto the Internet) > should not be responsible for providing any kind of emergency call > processing. > > 2. The access network provider does need to provide a location service > that can be used for emergency call processing > > 3. The LoST service with the translations for that point of access needs > to be available from that point of access. Somebody is actually > responsible for the physical infrastructure that supports it but it > doesn't have to be the access provider - just so long as it's > discoverable from the access. > > I am in agreement with these principles - nothing I said below was > inconsistent with them. > > Direct to PSAP-URI calling is a supported mode of operation, yes? What > distinguishes between the circumstance where a device does this versus > trying to send the call through its VSP? It may be because the specific > implementation of the VoIP client that the caller is using simply > decides to do that. This includes the possibility that the client > doesn't know its actually an emergency call and leaves it up to the VSP > to do the digit analysis. It includes the case where the VoIP client > doesn't know anything about ECRIT and just sends all calls to the VSP. > > I don't think in this decision that's governed by the nature of the > access is there? If not, discussion about NATs etc seem irrelevant to > me. In fact, my standard "nomadic" VoIP service is Skype. In my office, > our IS masters don't let Skype work. It's very difficult to guarantee > that arbitrary VSP access is going to work from arbitrary access points. > It's much simpler to guarantee that SIP calling directly to the relevant > PSAP URIs for those points of access will always work. I think details > such as whether an enterprise VoIP server is the thing that makes the > PSAP call is just that - a detail. In such an environment, the clients > and the server are part of the same package anyway. It's not at all the > same situation as bringing Vonage, for example, into the picture when an > emergency call is made. > > When it comes to phone BCP, it should be quite possible to say that the > phone client should always work to the local network and direct the call > directly to the PSAP. This, in my view, is what pure-ECRIT should be > about. It should also be possible to say that if the phone can only dial > digits that are processed by the VSP, then subsequent behaviour is out > of scope (but here's some suggestions). The NENA i2 architecture already > has this covered and it's being picked up internationally anyway. It's > an interim architecture; it'll go away as jurisdictions implement LoST > and IP PSAP services and VoIP clients learn to use those functions. It > would be preferable that, when the interim solution does disappear, that > VSPs no longer need to have a role or responsibility for providing > emergency access. It would be better for all concerned if they did not. > > Here's the logic: > > 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke > i2. > 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 > 3.Phone can find LIS and LoST - call PSAP directly > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 1 February 2008 3:56 AM > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > First my response to the original question: > > IMS is special because the visited network is in the call path. When > the > visited network has active elements in the call path, it makes sense to > have > the visited network handle emergency calls. Note that there are lots > and > lots of complications with this. Take for example, call back. What you > want is to have both a Contact URI that will route back to the device > that > placed the call, and you need a real AoR you can use to reach the caller > later on. The visited network would have to provide both. > > When the visited network is not in the call path, you have to use the > VSP. > > > Then my response to Martin: > > It's been said that the emergency service wants the subscriber details > > from the VSP. A caller can have subscriptions to lots of Internet > > services that also don't need to be involved in the call. Should we > also > > make emergency calling dependent on them? > No. However, involving the actual carrier that provides the service > that is > placing the call is essential. Bypassing the carrier that provides the > service that places the call is pretty tough, except in unusual > circumstances. IMS is an example of an unusual circumstance because > they > put the visited network in the call path. Very few other systems do > that. > > I'm very conscious of what we must ask the access network to provide. > This > has lots of implications on engineering as well as cost and liability. > Unless the device itself can locate itself without assistance of the > access > network, we ask the access network to provide location (or at least > location > assistance). We ask them to provide access to a LoST server. I want to > stop there. That's all they have to do. > > > > > I don't think it has to be the same as IMS. IMS requires a > co-operative > > E-CSCF that is actually part of the access network. With LoST and a > > suitable emergency proxy, there doesn't have to be any dependency on > the > > access network to also provide call processing. > IMS is different as discussed above. > > > > > Not involving the VSP in the call does not mean that the caller cannot > > provide callback details (in principle, they could provide multiple > > callback options). I'd also be interested in a discussion around > > providing an automatic presence subscription from the emergency > network > > itself - with a temporary callback number. As long as the emergency > > calling device is attached to the Internet, it should be able to stay > > registered with that temporary subscription and also do regular > location > > updates to it. > I think the notion that we can define the characteristics of an > emergency > proxy that works for all devices is not feasible. Let me cite a few > examples: > > Emergency call from AOL/MSN/Yahoo. We would have to require the device > to > implement SIP/SIMPLE. > > Emergency call from OnStar. Who is the emergency proxy provider? > > Emergency call from "Help I've fallen and I can't get up" buttons with > two > way audio. They would have to meet all of the phonebcp requirements. > > Call backs are an issue. You can get a contact URI, but you can't get > an > AoR you have any trust in for any call. > > But the biggest problem is that I think any attempt to give the access > network the obligation and the liability to totally handle emergency > calls > will not fly. > > > > > > Many of the most convoluted issues that have arisen in this forum have > > been around the challenges that having the VSP involved in call > routing > > introduces (the need for forest guides etc). Since direct-calling is a > > valid option, I know I'd prefer an emergency calling client that > always > > worked that way. > > > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 6 15:47:10 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD6E3A7412; Wed, 6 Feb 2008 15:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6oGx4ak+tus; Wed, 6 Feb 2008 15:47:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65D43A7254; Wed, 6 Feb 2008 15:47:08 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BEE3A7254; Wed, 6 Feb 2008 15:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAfpM4WVXLk1; Wed, 6 Feb 2008 15:47:05 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B5F8D3A7229; Wed, 6 Feb 2008 15:47:04 -0800 (PST) X-SEF-Processed: 5_0_0_910__2008_02_06_18_00_44 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 06 Feb 2008 18:00:44 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Feb 2008 17:48:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 17:48:32 -0600 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0741F1FF@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency Calls & VoIP Peering Thread-Index: Achj41fJlc/+aXoHTkupZiCqYqN7/AAIOEQgAAjcGcAADVkgIAAdh5WgAIFfjJAAFyluAAAEN9sQABKLliA= References: <47A186C1.7080004@gmx.net><005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com><015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA0741F1FF@crexc41p> From: "Dawson, Martin" To: , "ECRIT" X-OriginalArrivalTime: 06 Feb 2008 23:48:36.0055 (UTC) FILETIME=[CA15C670:01C8691A] Subject: Re: [Ecrit] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Barbara, I certainly agree with the "years to come" sentiment. Some jurisdictions may provide genuine PSAP URIs quite quickly; others may find it quite difficult to migrate away from legacy infrastructure. My sentiment in this thread, however, is focussed on the long term and what policy should be in the long term. Given the future scenario: 1. I am in Lithuania (Sierra Leone has gotten too crowded) where they have implemented a national LoST service and PSAP URI(s). 2. I have a device with a number of service clients - including a VSP in the USA 3. I am using a WiMAX service in Lithuania that is a roaming partner of my broadband wireless provider in the USA I authenticated with the WiMAX provider using EAP and based on my home wireless provider credentials. So, I'm already on the Internet and the device has already discovered the local LoST service for that point of access, established a context with the LIS in that access, and cached the emergency service URI(s). I need to make an emergency call. Now - is it more reliable to initiate a SIP session directly to the URI which is just the other side of the access network or is it better to send an approximate location to the US VSP (depending on both how the location-hiding is done in that jurisdiction and how location is conveyed in the VSP's VoIP protocol) have the VSP recognize it's an emergency calling situation, try to find the correct LoST server, re-determine the PSAP URI and proxy the call to the Lithuanian PSAP (while deciding whether to charge the subscriber for the call)? The interim situation where PSTN (or general circuit service tandeming) is required is exactly what i2 tackled. Indeed, the US VSP will probably have i2 support implemented and use a VPC (or v4/5 redirect/proxy) to handle the call anyway. This is just to emphasise that once call handling is given to the VSP, then it all becomes quite VSP-specific in terms of how the rest of the processing is done. I don't see how ECRIT can say much about that in the short term (apart from some recommendations) - and I don't see why VSPs need to be involved in the long term. Hence my objection to a perpetual policy that says "always use the VSP if you can". Brian is wrong when he says I ignored the "identity" issue. I said earlier in the thread that it's the access that's important for this. The really important identity information to the jurisdiction accepting the emergency call is the one associated with my Internet access. In my example, identity is the WiMAX subscription information. What is needed is a way to get this information to the PSAP. ECRIT needs this mechanism anyway - because non-VSP proxied calls (perhaps what you mean by uninitialized) are definitely in scope and this source of identity information cannot be ignored. I argue it's actually the most important piece of identity information because it is actually jurisdictionally relevant. Indeed the URI associated with a location reference is a good start for making this information available. It provides a callback to the access network. All that's necessary is the semantics to request associated identity information by authorized requestors (PSAPs). Cheers, Martin -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Tuesday, 5 February 2008 3:40 AM To: Brian Rosen; Dawson, Martin; Hannes Tschofenig; speermint@ietf.org; ECRIT Subject: RE: [Ecrit] Emergency Calls & VoIP Peering I think that for many years to come, the "PSAP URI" will be some sort of "tel uri", which will require the call to be sent to a PSTN gateway. Currently, there is no way for a SIP client to get a call to the PSTN, without going through some sort of VSP with a PSTN gateway. PSAP providers who don't immediately move over to VoIP, should not be expected to incur the cost of having/maintaining VoIP infrastructure (i.e., a PSTN gateway) in order for the ecrit architecture to work properly. Under no circumstances, should the access network be expected to provide a PSTN gateway. If the device has all the information needed to properly route the call to a PSAP, then I don't understand what it is that might break, if a VSP is asked to route the call. I'm looking at Martin's list of potential issues, and I don't really see how they apply: > how do VSPs that don't use SIP work Presumably, if the VSP doesn't do SIP, then the client associated with that VSP isn't a SIP client. It's highly likely that some random visited region will only support SIP, so it's unlikely that non-SIP clients will be supported, with or without the VSP. I don't understand this issue. If the device does have a SIP client, and that SIP client isn't registered with any SIP proxy, then I'm fine with saying it's ok for the device to try to route the call directly. > recognizing dial strings when > the VSP doesn't know what the intent and regional conventions are Direct routing can only work if the device is able to recognize dial strings. So, if a device recognizes dial strings, and properly forms the SIP messages (per phonebcp), it's not clear to me why sending the well-formed SIP message to the VSP (vs. directly) would force the VSP to have to recognize the original dial string. If the device doesn't recognize the dial string, then it won't be doing direct routing, in any case. > the VSP finding the right LoST server when it's not in a position to > perform local discovery Again, we need to only compare the cases of "send call to VSP" vs. "direct route call" when the device recognizes an emergency call and knows the route. If the device knows the route, then it shouldn't matter whether or not the VSP can get to or discover the LoST server. If the device doesn't know the route, then direct routing won't work, either. I don't see that any of these potential issues are real issues. Going back to my original point about needing access to a PSTN gateway in the foreseeable future, I think it's critical that "initialized" devices send emergency calls to their configured proxy, as they would with any other call. I'm happy to suggest that uninitialized devices with Internet access SHOULD directly route calls. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, February 04, 2008 8:56 AM To: 'Dawson, Martin'; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' Subject: Re: [Ecrit] Emergency Calls & VoIP Peering I think we will have to agree to disagree. I noticed you ignored identity. Anyone else think the only way emergency calls should (normally) work is to have all devices place emergency calls direct to PSAPs with (normally) no proxies? Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Sunday, February 03, 2008 10:20 PM > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > Hi Brian, > > This seems to suggest that there's a complexity argument for saying > phones should pass emergency calls however they "normally" make calls. > > If we have a precept that says it must always be possible to make a call > directly to the PSAP URI from a given point of access, then also > supporting call routing via the VSP can only add complexity. Issues such > as how do VSPs that don't use SIP work, or recognizing dial strings when > the VSP doesn't know what the intent and regional conventions are, or > the VSP finding the right LoST server when it's not in a position to > perform local discovery are all complexities that arise by not sending > the call directly to the PSAP URI. They are all things that make the > handling of an emergency call more brittle. > > The question of what is "normal" can only become more fuzzy over time as > well. Increasingly we just have IP-enabled multimedia devices that can > have an arbitrary number of service clients/subscriptions hosted on > them. I think this is really the environment that ECRIT should be > focussed on. It's the device that should know how to initiate and > support emergency calling - not the potential multitude of other service > clients hosted on that device. > > Ideally, all devices should have practically the same implementation > that knows how to do local location and LoST service discovery and to > subsequently contact the local emergency service. Dedicated VSP client > devices could integrate such a reference implementation, provide a > mechanism to call it, and only invoke VSP-specific emergency handling if > (as I described below) the local network does not appear to support the > necessary ECRIT functions. This should result in less complexity over > time with more and more consistent implementations from the device > perspective as well as the network perspective. As long as the reference > client works, then the network is doing the right thing. > > "Track and trace" become Internet access issues. We get to the point > where we have optimal assurance that the access is local to the > emergency jurisdiction and we have all the same wherewithal with respect > to this function as we do with the PSTN - without needing to think that > VSPs are important to it. > > I think everything that ECRIT has is just about right. I just think that > the mantra about "normal call processing" has things the wrong way > around. i.e I have the opposite view to what you expressed, Brian. > Ultimately, I think VSP involvement should go away - and not actually be > the recommended approach in perpetuity. The VSP considerations should > become recommendations that are ultimately deprecated. > > Note - I understand very well that redoing documentation and recanting > on policy is a demotivator. However, now is always the best time to > change if we don't have things quite right. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Brian Rosen > Sent: Saturday, 2 February 2008 12:28 AM > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > Subject: Re: [Ecrit] Emergency Calls & VoIP Peering > > I have some conflicting thoughts on this. It should be possible for a > phone > to send the call itself direct to the PSAP URI. The emergency call > system > should be able to handle that. > > On the other hand, carriers are generally thought of as useful partners > by > the emergency call system, and a recommendation that they be bypassed > won't > be appreciated by those folks even if there is an engineering argument > that > it's more efficient. > > Part of the reason is track and trace. Part of the reason is subscriber > name and address. The big one is identity. Carriers provide reasonably > verified identity. > > So, on balance, I think phonebcp should say, as it does now, that phones > pass emergency calls to wherever they normally pass outbound calls. > Frankly, the number of special processing steps we're asking phones to > do > for emergency calls is getting too high. I'd rather figure out ways to > remove some special processing, not add more. > > Presently phones have to: > *Get location and do LoST lookups > *Watch for emergency dial strings > *Add Geolocation headers, PSAP URIs and service urns > *Disable some features > *Not send bye > > If anything, that list is too long. As with most things like it, the > more > special stuff you do for emergencies, the less likely it is to actually > work > in an emergency. > > Generally, I think phones knowing where they are is a good thing in the > big > picture, and having the phone do all dial plan interpretation is the > right > thing also. So the real special processing is the last three. > > Brian > > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Thursday, January 31, 2008 11:31 PM > > To: Brian Rosen; Hannes Tschofenig; speermint@ietf.org; ECRIT > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > We need to note the points where we are actually in agreement. Perhaps > > there was an inference that we weren't with respect to the following: > > > > 1. The access network provider (the one that gets you onto the > Internet) > > should not be responsible for providing any kind of emergency call > > processing. > > > > 2. The access network provider does need to provide a location service > > that can be used for emergency call processing > > > > 3. The LoST service with the translations for that point of access > needs > > to be available from that point of access. Somebody is actually > > responsible for the physical infrastructure that supports it but it > > doesn't have to be the access provider - just so long as it's > > discoverable from the access. > > > > I am in agreement with these principles - nothing I said below was > > inconsistent with them. > > > > Direct to PSAP-URI calling is a supported mode of operation, yes? What > > distinguishes between the circumstance where a device does this versus > > trying to send the call through its VSP? It may be because the > specific > > implementation of the VoIP client that the caller is using simply > > decides to do that. This includes the possibility that the client > > doesn't know its actually an emergency call and leaves it up to the > VSP > > to do the digit analysis. It includes the case where the VoIP client > > doesn't know anything about ECRIT and just sends all calls to the VSP. > > > > I don't think in this decision that's governed by the nature of the > > access is there? If not, discussion about NATs etc seem irrelevant to > > me. In fact, my standard "nomadic" VoIP service is Skype. In my > office, > > our IS masters don't let Skype work. It's very difficult to guarantee > > that arbitrary VSP access is going to work from arbitrary access > points. > > It's much simpler to guarantee that SIP calling directly to the > relevant > > PSAP URIs for those points of access will always work. I think details > > such as whether an enterprise VoIP server is the thing that makes the > > PSAP call is just that - a detail. In such an environment, the clients > > and the server are part of the same package anyway. It's not at all > the > > same situation as bringing Vonage, for example, into the picture when > an > > emergency call is made. > > > > When it comes to phone BCP, it should be quite possible to say that > the > > phone client should always work to the local network and direct the > call > > directly to the PSAP. This, in my view, is what pure-ECRIT should be > > about. It should also be possible to say that if the phone can only > dial > > digits that are processed by the VSP, then subsequent behaviour is out > > of scope (but here's some suggestions). The NENA i2 architecture > already > > has this covered and it's being picked up internationally anyway. It's > > an interim architecture; it'll go away as jurisdictions implement LoST > > and IP PSAP services and VoIP clients learn to use those functions. It > > would be preferable that, when the interim solution does disappear, > that > > VSPs no longer need to have a role or responsibility for providing > > emergency access. It would be better for all concerned if they did > not. > > > > Here's the logic: > > > > 1 Phone can't do genuine ECRIT (LoST discovery etc.) call VSP - invoke > > i2. > > 2.Phone does ECRIT but can't find LIS and/or LoST - invoke i2 > > 3.Phone can find LIS and LoST - call PSAP directly > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 1 February 2008 3:56 AM > > To: Dawson, Martin; 'Hannes Tschofenig'; speermint@ietf.org; 'ECRIT' > > Subject: RE: [Ecrit] Emergency Calls & VoIP Peering > > > > First my response to the original question: > > > > IMS is special because the visited network is in the call path. When > > the > > visited network has active elements in the call path, it makes sense > to > > have > > the visited network handle emergency calls. Note that there are lots > > and > > lots of complications with this. Take for example, call back. What > you > > want is to have both a Contact URI that will route back to the device > > that > > placed the call, and you need a real AoR you can use to reach the > caller > > later on. The visited network would have to provide both. > > > > When the visited network is not in the call path, you have to use the > > VSP. > > > > > > Then my response to Martin: > > > It's been said that the emergency service wants the subscriber > details > > > from the VSP. A caller can have subscriptions to lots of Internet > > > services that also don't need to be involved in the call. Should we > > also > > > make emergency calling dependent on them? > > No. However, involving the actual carrier that provides the service > > that is > > placing the call is essential. Bypassing the carrier that provides > the > > service that places the call is pretty tough, except in unusual > > circumstances. IMS is an example of an unusual circumstance because > > they > > put the visited network in the call path. Very few other systems do > > that. > > > > I'm very conscious of what we must ask the access network to provide. > > This > > has lots of implications on engineering as well as cost and liability. > > Unless the device itself can locate itself without assistance of the > > access > > network, we ask the access network to provide location (or at least > > location > > assistance). We ask them to provide access to a LoST server. I want > to > > stop there. That's all they have to do. > > > > > > > > I don't think it has to be the same as IMS. IMS requires a > > co-operative > > > E-CSCF that is actually part of the access network. With LoST and a > > > suitable emergency proxy, there doesn't have to be any dependency on > > the > > > access network to also provide call processing. > > IMS is different as discussed above. > > > > > > > > Not involving the VSP in the call does not mean that the caller > cannot > > > provide callback details (in principle, they could provide multiple > > > callback options). I'd also be interested in a discussion around > > > providing an automatic presence subscription from the emergency > > network > > > itself - with a temporary callback number. As long as the emergency > > > calling device is attached to the Internet, it should be able to > stay > > > registered with that temporary subscription and also do regular > > location > > > updates to it. > > I think the notion that we can define the characteristics of an > > emergency > > proxy that works for all devices is not feasible. Let me cite a few > > examples: > > > > Emergency call from AOL/MSN/Yahoo. We would have to require the > device > > to > > implement SIP/SIMPLE. > > > > Emergency call from OnStar. Who is the emergency proxy provider? > > > > Emergency call from "Help I've fallen and I can't get up" buttons with > > two > > way audio. They would have to meet all of the phonebcp requirements. > > > > Call backs are an issue. You can get a contact URI, but you can't get > > an > > AoR you have any trust in for any call. > > > > But the biggest problem is that I think any attempt to give the access > > network the obligation and the liability to totally handle emergency > > calls > > will not fly. > > > > > > > > > > Many of the most convoluted issues that have arisen in this forum > have > > > been around the challenges that having the VSP involved in call > > routing > > > introduces (the need for forest guides etc). Since direct-calling is > a > > > valid option, I know I'd prefer an emergency calling client that > > always > > > worked that way. > > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 7 16:45:06 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608F13A7DBF; Thu, 7 Feb 2008 16:45:06 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw17XviNvlGr; Thu, 7 Feb 2008 16:45:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747BB3A7D7B; Thu, 7 Feb 2008 16:45:05 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4BE123A7AA3; Thu, 7 Feb 2008 16:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080208004501.4BE123A7AA3@core3.amsl.com> Date: Thu, 7 Feb 2008 16:45:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-07.txt Pages : 77 Date : 2008-02-07 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-lost-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-lost-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-07164301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-lost-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-07164301.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Tue Feb 12 12:51:47 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C7628C4CA; Tue, 12 Feb 2008 12:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=-2.396, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSh+8Ybyp2g2; Tue, 12 Feb 2008 12:51:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9AF28C583; Tue, 12 Feb 2008 12:51:44 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCBE28C3DF for ; Tue, 12 Feb 2008 12:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFub8398jC64 for ; Tue, 12 Feb 2008 12:51:42 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5C1D628C5EB for ; Tue, 12 Feb 2008 12:51:08 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2008 12:52:32 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1CKqWSQ004134 for ; Tue, 12 Feb 2008 12:52:32 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1CKpuJw003507 for ; Tue, 12 Feb 2008 20:52:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 12:52:01 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.87.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 12:52:01 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Feb 2008 14:51:15 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 Feb 2008 20:52:01.0324 (UTC) FILETIME=[1D9C9EC0:01C86DB9] Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Ecrit] Fwd: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org forwarding for those of us who want to know of anything related to emergency calling, this ID has a relevant abstract for you... >To: i-d-announce@ietf.org >Cc: >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >Date: Tue, 12 Feb 2008 10:45:02 -0800 (PST) > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Specification of 3GPP IM CN Subsystem XML > body handling > Author(s) : J. Bakker > Filename : > draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt > Pages : 8 > Date : 2008-2-12 > >This document registers new disposition-types for the Content- > Disposition header that apply to the application/3gpp-ims+xml body > used by 3GPP, since Release 5. The applicability of these content- > disposition values are limited to 3GPP IMS. The application/ > 3gpp-ims+xml body has the following two distinct uses: (1) for > redirecting the emergency session to use a different domain (e.g. > using a Circuit Switched call), and (2) for delivering user profile > specific information from the SIP registrar to an Application Server. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login with the >username "anonymous" and a password of your e-mail address. After >logging in, type "cd internet-drafts" and then >"get draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE > /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2008-2-12103140.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >http://www.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 12 12:59:18 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDFAC28C530; Tue, 12 Feb 2008 12:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNg-kfZIcV2Q; Tue, 12 Feb 2008 12:59:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38EE28C47B; Tue, 12 Feb 2008 12:59:17 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE7928C47B for ; Tue, 12 Feb 2008 12:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCmJqRMV9c6h for ; Tue, 12 Feb 2008 12:59:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8D41128C216 for ; Tue, 12 Feb 2008 12:58:46 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2008 21:00:10 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.5]) [91.154.103.163] by mail.gmx.net (mp038) with SMTP; 12 Feb 2008 22:00:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/WoMwBAYLWaLAlIHXzN3hlKhqvUlkbJ4CwoP5tgP 0qPBcbD25hiznX Message-ID: <47B208D8.4050907@gmx.net> Date: Tue, 12 Feb 2008 23:00:08 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "James M. Polk" References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: "'ecrit@ietf.org'" Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi James, Thanks for pointing me to this document since I was not aware of this work. Tomorrow is the 3GPP - IETF conference call. I will try to learn a bit about the history of it. Ciao Hannes James M. Polk wrote: > forwarding for those of us who want to know of anything related to > emergency calling, this ID has a relevant abstract for you... > > >> To: i-d-announce@ietf.org >> Cc: >> From: Internet-Drafts@ietf.org >> Subject: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >> Date: Tue, 12 Feb 2008 10:45:02 -0800 (PST) >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Specification of 3GPP IM CN Subsystem XML >> body handling >> Author(s) : J. Bakker >> Filename : >> draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >> Pages : 8 >> Date : 2008-2-12 >> >> This document registers new disposition-types for the Content- >> Disposition header that apply to the application/3gpp-ims+xml body >> used by 3GPP, since Release 5. The applicability of these content- >> disposition values are limited to 3GPP IMS. The application/ >> 3gpp-ims+xml body has the following two distinct uses: (1) for >> redirecting the emergency session to use a different domain (e.g. >> using a Circuit Switched call), and (2) for delivering user profile >> specific information from the SIP registrar to an Application Server. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE >> /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> Content-Type: text/plain >> Content-ID: <2008-2-12103140.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >> >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> http://www.ietf.org/mailman/listinfo/i-d-announce >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 12 13:04:59 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B64428C5FB; Tue, 12 Feb 2008 13:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x69VnCEaqrUN; Tue, 12 Feb 2008 13:04:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A9128C4D1; Tue, 12 Feb 2008 13:04:55 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCC628C4D1 for ; Tue, 12 Feb 2008 13:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfSmkaUqv3gF for ; Tue, 12 Feb 2008 13:04:52 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C7B6E28C4C8 for ; Tue, 12 Feb 2008 13:03:52 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2008 13:05:16 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1CL5Emf027677; Tue, 12 Feb 2008 13:05:14 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1CL5EnY003962; Tue, 12 Feb 2008 21:05:14 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 13:05:11 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.87.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Feb 2008 13:05:11 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Feb 2008 15:05:10 -0600 To: Hannes.Tschofenig@gmx.net From: "James M. Polk" In-Reply-To: <47B208D8.4050907@gmx.net> References: <47B208D8.4050907@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 Feb 2008 21:05:11.0340 (UTC) FILETIME=[F47F7EC0:01C86DBA] Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "'ecrit@ietf.org'" Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:00 PM 2/12/2008, Hannes Tschofenig wrote: >Hi James, > >Thanks for pointing me to this document since I was not aware of this work. >Tomorrow is the 3GPP - IETF conference call. good timing then -- excellent! >I will try to learn a bit about the history of it. cool, since this seems to be a little different than most things out there, can you provide a note to the WG (or just to me) with what you find out? >Ciao >Hannes > >James M. Polk wrote: >>forwarding for those of us who want to know of anything related to >>emergency calling, this ID has a relevant abstract for you... >> >> >>>To: i-d-announce@ietf.org >>>Cc: >>>From: Internet-Drafts@ietf.org >>>Subject: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>Date: Tue, 12 Feb 2008 10:45:02 -0800 (PST) >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> Title : Specification of 3GPP IM CN Subsystem >>> XML body handling >>> Author(s) : J. Bakker >>> Filename : >>> draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>> Pages : 8 >>> Date : 2008-2-12 >>> >>>This document registers new disposition-types for the Content- >>> Disposition header that apply to the application/3gpp-ims+xml body >>> used by 3GPP, since Release 5. The applicability of these content- >>> disposition values are limited to 3GPP IMS. The application/ >>> 3gpp-ims+xml body has the following two distinct uses: (1) for >>> redirecting the emergency session to use a different domain (e.g. >>> using a Circuit Switched call), and (2) for delivering user profile >>> specific information from the SIP registrar to an Application Server. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>> >>>To remove yourself from the I-D Announcement list, send a message to >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of >>>the message. >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>to change your subscription settings. >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the >>>username "anonymous" and a password of your e-mail address. After >>>logging in, type "cd internet-drafts" and then >>>"get draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE >>> /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant >>> mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>>Content-Type: text/plain >>>Content-ID: <2008-2-12103140.I-D@ietf.org> >>> >>>ENCODING mime >>>FILE /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>> >>> >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>http://www.ietf.org/mailman/listinfo/i-d-announce >>> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>http://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 12 13:07:32 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC69228C5C5; Tue, 12 Feb 2008 13:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYQipZ-3XKoy; Tue, 12 Feb 2008 13:07:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99A528C56E; Tue, 12 Feb 2008 13:07:31 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1672928C56E for ; Tue, 12 Feb 2008 13:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnTjfm2i6eg5 for ; Tue, 12 Feb 2008 13:07:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A6F1028C575 for ; Tue, 12 Feb 2008 13:07:28 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2008 21:08:51 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.5]) [91.154.103.163] by mail.gmx.net (mp020) with SMTP; 12 Feb 2008 22:08:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+7VBBLXo676KVB3Cytuo6WLMFwIQnd2PnL1NfQSC TYwZWatsNlcqtg Message-ID: <47B20AE1.3050200@gmx.net> Date: Tue, 12 Feb 2008 23:08:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "James M. Polk" References: <47B208D8.4050907@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: "'ecrit@ietf.org'" Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sure. I will post my summary of the chat since emergency calling is again on the agenda for tomorrows call. Ciao Hannes James M. Polk wrote: > At 03:00 PM 2/12/2008, Hannes Tschofenig wrote: >> Hi James, >> >> Thanks for pointing me to this document since I was not aware of this >> work. >> Tomorrow is the 3GPP - IETF conference call. > > good timing then -- excellent! > >> I will try to learn a bit about the history of it. > > cool, since this seems to be a little different than most things out > there, can you provide a note to the WG (or just to me) with what you > find out? > > >> Ciao >> Hannes >> >> James M. Polk wrote: >>> forwarding for those of us who want to know of anything related to >>> emergency calling, this ID has a relevant abstract for you... >>> >>> >>>> To: i-d-announce@ietf.org >>>> Cc: >>>> From: Internet-Drafts@ietf.org >>>> Subject: I-D >>>> ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> Date: Tue, 12 Feb 2008 10:45:02 -0800 (PST) >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Specification of 3GPP IM CN Subsystem XML >>>> body handling >>>> Author(s) : J. Bakker >>>> Filename : >>>> draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> Pages : 8 >>>> Date : 2008-2-12 >>>> >>>> This document registers new disposition-types for the Content- >>>> Disposition header that apply to the application/3gpp-ims+xml body >>>> used by 3GPP, since Release 5. The applicability of these content- >>>> disposition values are limited to 3GPP IMS. The application/ >>>> 3gpp-ims+xml body has the following two distinct uses: (1) for >>>> redirecting the emergency session to use a different domain (e.g. >>>> using a Circuit Switched call), and (2) for delivering user profile >>>> specific information from the SIP registrar to an Application >>>> Server. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body of >>>> the message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then >>>> "get draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE >>>> /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >>>> >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need >>>> "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant >>>> mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been >>>> split >>>> up into multiple messages), so check your local >>>> documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> Content-Type: text/plain >>>> Content-ID: <2008-2-12103140.I-D@ietf.org> >>>> >>>> ENCODING mime >>>> FILE >>>> /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> http://www.ietf.org/mailman/listinfo/i-d-announce >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> http://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 14 01:44:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F43D28CDA4; Thu, 14 Feb 2008 01:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyYe25l7A2SB; Thu, 14 Feb 2008 01:44:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101B828CDA7; Thu, 14 Feb 2008 01:44:32 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B600D28C2F8 for ; Thu, 14 Feb 2008 01:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXjqB27XcyVw for ; Thu, 14 Feb 2008 01:44:29 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 39D7428CDA4 for ; Thu, 14 Feb 2008 01:44:29 -0800 (PST) Received: (qmail invoked by alias); 14 Feb 2008 09:45:51 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp031) with SMTP; 14 Feb 2008 10:45:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ICZAPOu+I0SLddp+jO70y8rlzo1yRpeUnt4X5Ew v/q7iGGRNEFUTk Message-ID: <47B40DCD.8090602@gmx.net> Date: Thu, 14 Feb 2008 11:45:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "James M. Polk" References: <47B208D8.4050907@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: "'ecrit@ietf.org'" Subject: Re: [Ecrit] Fwd: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So, I got some information regarding this document. In early work on IMS emergency services (Release 5) the 3GPP decided to use a Circuit Switched call for their emergency calls. However, there are failure cases where the call is still placed on the packet based IMS and the proxy indicates that the mobile phone has to use CS instead. As such, this is somewhat old work done by the 3GPP (and even implemented) but they forgot to make the IANA registration. Hence, this document makes this IANA registration. Ciao Hannes James M. Polk wrote: > At 03:00 PM 2/12/2008, Hannes Tschofenig wrote: >> Hi James, >> >> Thanks for pointing me to this document since I was not aware of this >> work. >> Tomorrow is the 3GPP - IETF conference call. > > good timing then -- excellent! > >> I will try to learn a bit about the history of it. > > cool, since this seems to be a little different than most things out > there, can you provide a note to the WG (or just to me) with what you > find out? > > >> Ciao >> Hannes >> >> James M. Polk wrote: >>> forwarding for those of us who want to know of anything related to >>> emergency calling, this ID has a relevant abstract for you... >>> >>> >>>> To: i-d-announce@ietf.org >>>> Cc: >>>> From: Internet-Drafts@ietf.org >>>> Subject: I-D >>>> ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> Date: Tue, 12 Feb 2008 10:45:02 -0800 (PST) >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Specification of 3GPP IM CN Subsystem XML >>>> body handling >>>> Author(s) : J. Bakker >>>> Filename : >>>> draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> Pages : 8 >>>> Date : 2008-2-12 >>>> >>>> This document registers new disposition-types for the Content- >>>> Disposition header that apply to the application/3gpp-ims+xml body >>>> used by 3GPP, since Release 5. The applicability of these content- >>>> disposition values are limited to 3GPP IMS. The application/ >>>> 3gpp-ims+xml body has the following two distinct uses: (1) for >>>> redirecting the emergency session to use a different domain (e.g. >>>> using a Circuit Switched call), and (2) for delivering user profile >>>> specific information from the SIP registrar to an Application >>>> Server. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body of >>>> the message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then >>>> "get draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE >>>> /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt". >>>> >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need >>>> "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant >>>> mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been >>>> split >>>> up into multiple messages), so check your local >>>> documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> Content-Type: text/plain >>>> Content-ID: <2008-2-12103140.I-D@ietf.org> >>>> >>>> ENCODING mime >>>> FILE >>>> /internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> http://www.ietf.org/mailman/listinfo/i-d-announce >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> http://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Feb 18 07:48:13 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973AB28C58B; Mon, 18 Feb 2008 07:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+mCgK3mHRdP; Mon, 18 Feb 2008 07:48:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88AE028C4B8; Mon, 18 Feb 2008 07:48:00 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B26C28C43E for ; Mon, 18 Feb 2008 07:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaFvT3QrDF8m for ; Mon, 18 Feb 2008 07:47:58 -0800 (PST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 6019828C48B for ; Mon, 18 Feb 2008 07:47:47 -0800 (PST) Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JR8DY-0004Us-6J; Mon, 18 Feb 2008 10:47:45 -0500 Received: from [128.89.253.105] (helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1JR8DY-00080q-Mw; Mon, 18 Feb 2008 10:47:44 -0500 Message-ID: <47B9A89C.2020704@bbn.com> Date: Mon, 18 Feb 2008 10:47:40 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT Subject: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-rough-loc-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We have posted a draft that explains how imprecise location can be used for emergency context resolution within the ECRIT framework. Specifically, we describe how a location provider can determine when a position is sufficiently precise for emergency call routing, and how emergency and non-emergency services are delivered in this context. While this document may enable a solution to the location-hiding problem, it can also be useful when a location provider is using positioning mechanisms that are capable of returning location at various granularities, with finer-grained location taking more time or resources to compute. --Richard -------- Original Message -------- Subject: New Version Notification for draft-barnes-ecrit-rough-loc-00 Date: Mon, 18 Feb 2008 07:35:55 -0800 (PST) From: IETF I-D Submission Tool To: rbarnes@bbn.com CC: mlepinski@bbn.com A new version of I-D, draft-barnes-ecrit-rough-loc-00.txt has been successfuly submitted by Richard Barnes and posted to the IETF repository. Filename: draft-barnes-ecrit-rough-loc Revision: 00 Title: Using Imprecise Location for Emergency Context Resolution Creation_date: 2008-02-18 WG ID: Independent Submission Number_of_pages: 12 Abstract: Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. The IETF Secretariat. _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 19 23:00:17 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2A728C421; Tue, 19 Feb 2008 23:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-8+LZjupt8D; Tue, 19 Feb 2008 23:00:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDD43A6E26; Tue, 19 Feb 2008 23:00:16 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99E83A6E26 for ; Tue, 19 Feb 2008 23:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsVIaeqsWUbV for ; Tue, 19 Feb 2008 23:00:14 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E82EF3A6860 for ; Tue, 19 Feb 2008 23:00:13 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1K7085C013519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2008 08:00:08 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1K707p1006898 for ; Wed, 20 Feb 2008 08:00:08 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 08:00:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 08:00:10 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB7987E9@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-ecrit-lost Thread-Index: AchzUDJQexEbo3faRNWq91iplpvz1gAPf+jQ From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 20 Feb 2008 07:00:07.0731 (UTC) FILETIME=[3A18C030:01C8738E] Subject: [Ecrit] WG: DISCUSS and COMMENT: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -----Urspr=FCngliche Nachricht----- Von: ext Russ Housley [mailto:housley@vigilsec.com] = Gesendet: Mittwoch, 20. Februar 2008 01:36 An: iesg@ietf.org Cc: ben@estacado.net; ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-lost@to= ols.ietf.org Betreff: DISCUSS and COMMENT: draft-ietf-ecrit-lost = Discuss: Based on the Gen-ART Review by Ben Campbell. In Section 12, first paragraph, it says: "To achieve interoperability, this document defines two mandatory-to-implement baseline location profiles to define the manner in which location information is transmitted. It is possible to standardize other profiles in the future. The three baseline profiles are:" Are there really three baseline profiles and two of them are mandatory-to-implement? Comment: As pointed out by Ben Campbell in his Gen-ART Review, these things should probably be reworded as normative statements: = - Section 5.2, last paragraph: "... it is the responsibility of the client to check the 'expires' attribute... " - Section 6, paragraph 3: "If a query is answered iteratively, the querier includes all servers that it has already contacted." - Section 8.3.1: "The order of location elements is significant; the server uses the first location element where it understands the location profile." _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 19 23:00:39 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E1F28C30A; Tue, 19 Feb 2008 23:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VpXIKz6KtC4; Tue, 19 Feb 2008 23:00:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDE928C281; Tue, 19 Feb 2008 23:00:37 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E905C28C281 for ; Tue, 19 Feb 2008 23:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vnd2uzpuPjG for ; Tue, 19 Feb 2008 23:00:35 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B83273A6860 for ; Tue, 19 Feb 2008 23:00:34 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1K70TC2017097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2008 08:00:29 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1K70TCq006756 for ; Wed, 20 Feb 2008 08:00:29 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Feb 2008 08:00:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Feb 2008 08:00:31 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB7987EA@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-ecrit-lost Thread-Index: AchzWZo+uCfYVePzTUyf9hJIW0H2zQANKcBQ From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 20 Feb 2008 07:00:29.0495 (UTC) FILETIME=[4711AC70:01C8738E] Subject: [Ecrit] WG: DISCUSS and COMMENT: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI = -----Urspr=FCngliche Nachricht----- Von: ext Ted Hardie [mailto:hardie@qualcomm.com] = Gesendet: Mittwoch, 20. Februar 2008 02:43 An: Russ Housley; iesg@ietf.org Cc: ben@estacado.net; ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-lost@to= ols.ietf.org Betreff: Re: DISCUSS and COMMENT: draft-ietf-ecrit-lost At 3:35 PM -0800 2/19/08, Russ Housley wrote: >Discuss: > > Based on the Gen-ART Review by Ben Campbell. > > In Section 12, first paragraph, it says: "To achieve interoperability, > this document defines two mandatory-to-implement baseline location > profiles to define the manner in which location information is > transmitted. It is possible to standardize other profiles in the > future. The three baseline profiles are:" Are there really three > baseline profiles and two of them are mandatory-to-implement? Are you sure you're reviewing the right version? The current text for the first paragraph is: LoST uses location information in elements in requests and elements in responses. Such location information may be expressed in a variety of ways. This variety can cause interoperability problems where a request or response contains location information in a format not understood by the server or the client, respectively. To achieve interoperability, this document defines two mandatory-to-implement baseline location profiles to define the manner in which location information is transmitted. It is possible to standardize other profiles in the future. The baseline profiles are: A -07 was issued in response to Last Call comments, and this is among the c= hanges. regards, Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 20 23:25:47 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD40B28C972; Wed, 20 Feb 2008 23:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+KLwD2UBl65; Wed, 20 Feb 2008 23:25:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7819228C971; Wed, 20 Feb 2008 23:25:46 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C0228C964 for ; Wed, 20 Feb 2008 23:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48JrU9ASGVLi for ; Wed, 20 Feb 2008 23:25:44 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 088D728C7DF for ; Wed, 20 Feb 2008 23:25:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1L7PcmQ015741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2008 08:25:38 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1L7Pc9T029617 for ; Thu, 21 Feb 2008 08:25:38 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 08:25:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 08:25:38 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB798A59@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-ecrit-lost Thread-Index: Achz2DzMTi9MfGr9QlyRFrf0LWl9SAAgrUfQ From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 21 Feb 2008 07:25:38.0310 (UTC) FILETIME=[F4CE5260:01C8745A] Subject: [Ecrit] WG: DISCUSS and COMMENT: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI = -----Urspr=FCngliche Nachricht----- Von: ext Russ Housley [mailto:housley@vigilsec.com] = Gesendet: Mittwoch, 20. Februar 2008 16:55 An: Ted Hardie; iesg@ietf.org Cc: ben@estacado.net; ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-lost@to= ols.ietf.org Betreff: Re: DISCUSS and COMMENT: draft-ietf-ecrit-lost Thanks. I'll clear. Russ At 07:42 PM 2/19/2008, Ted Hardie wrote: >At 3:35 PM -0800 2/19/08, Russ Housley wrote: > >Discuss: > > > > Based on the Gen-ART Review by Ben Campbell. > > > > In Section 12, first paragraph, it says: "To achieve interoperability, > > this document defines two mandatory-to-implement baseline location > > profiles to define the manner in which location information is > > transmitted. It is possible to standardize other profiles in the > > future. The three baseline profiles are:" Are there really three > > baseline profiles and two of them are mandatory-to-implement? > >Are you sure you're reviewing the right version? The current text for >the first paragraph is: > > LoST uses location information in elements in requests and > elements in responses. Such location information > may be expressed in a variety of ways. This variety can cause > interoperability problems where a request or response contains > location information in a format not understood by the server or the > client, respectively. To achieve interoperability, this document > defines two mandatory-to-implement baseline location profiles to > define the manner in which location information is transmitted. It > is possible to standardize other profiles in the future. The > baseline profiles are: > >A -07 was issued in response to Last Call comments, and this is = >among the changes. > regards, > Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 20 23:26:04 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD6828C981; Wed, 20 Feb 2008 23:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfnW1V6fxX0r; Wed, 20 Feb 2008 23:26:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D169D28C96F; Wed, 20 Feb 2008 23:26:03 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B778B28C964 for ; Wed, 20 Feb 2008 23:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OSaDM3zAW8B for ; Wed, 20 Feb 2008 23:26:01 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7296D28C98A for ; Wed, 20 Feb 2008 23:26:01 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1L7PujQ011748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2008 08:25:56 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1L7Pu8e027072 for ; Thu, 21 Feb 2008 08:25:56 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 08:25:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 08:25:56 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB798A5A@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-ecrit-lost Thread-Index: Ach0CoSHcw0IsIvRT5qaHVE97yh1pgAUHf6Q From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 21 Feb 2008 07:25:56.0022 (UTC) FILETIME=[FF5CF560:01C8745A] Subject: [Ecrit] WG: DISCUSS: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI = -----Urspr=FCngliche Nachricht----- Von: ext Lisa Dusseault [mailto:lisa@osafoundation.org] = Gesendet: Mittwoch, 20. Februar 2008 23:49 An: iesg@ietf.org Cc: hardie@qualcomm.com; ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-lost= @tools.ietf.org Betreff: DISCUSS: draft-ietf-ecrit-lost = Discuss: 1. Redirects The section on redirect (13.3) is shockingly short. Are redirects permane= nt or temporary? Should other servers change their listings when seeing a = redirect? Redirects have caused interoperability problems in HTTP; perhaps= a little deeper review of the need for the functionality would help here. I'm inferring from section 14. that HTTP redirects MUST be supported by cli= ents as well as LoST redirects. Can that be made a normative requirement? 2a. Open-ended URI types I'd like to see more guidance on what URIs are returned. The risk that the= LoST server will return a URI that can't be used by the seeker is a bad ri= sk to take when it comes to emergency services. - Add "tel" URI examples to the examples; Explain that in the worst case o= f not being able to use the URI types presented, seekers that have user int= erfaces should present the telephone number to the user; recommend that pho= ne numbers be provided this way as fallbacks for emergency services - limit the types used: no data or mailto URIs; better yet have a registry= of types that *can* be used - In the case of SIP URIs, what kind of contact can be made? Can this URI= get a human voice, a voice mailbox, a presentity or other? = - Differentiate between contact and resource URIs? A resource URI obtains= something static, a contact URI may be able to begin a conversation... I'd like a little discussion of the requirement that each URI scheme may ap= pear only once. That seems to prevent some fairly common use cases like pr= oviding one number for voice mail and one number to reach an operator. The= proliferation of http URIs makes this even worse -- many different kinds o= f services can be hosted on http URIs. The Atom link rel provides an examp= le of how one might deal with this problem. 2b. IRIs Is support for IRIs explicitly not desired? 2c. URI security/privacy I assume both LoST URIs (found in NAPTR) and service URIs can contain anyth= ing allowed by the URI scheme; long paths, query elements, anchor points. I= can see a slight privacy issue here, because the URIs can contain tokens a= llowing communication from the LoST server that provided the URI to the ser= vice hosting that URI. This document doesn't talk about preserving URIs end-to-end. What if a LoS= T resolver were to "helpfully" try to change URIs before passing them on to= seekers? Is there some other document that covers this? 3. Overlooked HTTP features. A number of features that are commonly overlooked when using HTTP this way = are not mentioned. I like that HTTP caching is disabled but it looks like = there's a cut-and-paste error in that part of the spec: The HTTP request MUST use the Cache-Control response directive "no-cache" to HTTP-level "caching even by caches that have been configured to return stale responses to client requests." For the rest I suggest adding: = "LoST servers MUST handle the Expect header, conditional headers and Conten= t-* headers on requests according to HTTP requirements (possibly by failing= the request). They MUST also handle OPTIONS and HEAD and GET requests eve= n if it's by responding with canned 200 responses. = "LoST clients MUST include a Host header and MUST handle all possible HTTP = response codes. = "Both LoST clients and servers MUST handle chunked transfer-encoded message= bodies." _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Feb 20 23:26:14 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66CF528C967; Wed, 20 Feb 2008 23:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 475eA37oaqtV; Wed, 20 Feb 2008 23:26:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7A228C97D; Wed, 20 Feb 2008 23:26:13 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA6C28C97D for ; Wed, 20 Feb 2008 23:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q8cq5ttwqir for ; Wed, 20 Feb 2008 23:26:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id DB46228C967 for ; Wed, 20 Feb 2008 23:26:10 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1L7Q6XB011798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2008 08:26:06 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1L7Q6HD027188 for ; Thu, 21 Feb 2008 08:26:06 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 08:26:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Feb 2008 08:26:06 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB798A5B@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-ecrit-lost Thread-Index: Ach0E+b8hG+PtGOhQZqh4zwcWbZhvAARxs3w From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 21 Feb 2008 07:26:05.0960 (UTC) FILETIME=[05496080:01C8745B] Subject: [Ecrit] WG: DISCUSS: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI = -----Urspr=FCngliche Nachricht----- Von: ext Ted Hardie [mailto:hardie@qualcomm.com] = Gesendet: Donnerstag, 21. Februar 2008 00:56 An: Lisa Dusseault; iesg@ietf.org Cc: ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-lost@tools.ietf.org Betreff: Re: DISCUSS: draft-ietf-ecrit-lost At 1:49 PM -0800 2/20/08, Lisa Dusseault wrote: >Discuss: > >1. Redirects > >The section on redirect (13.3) is shockingly short. Are redirects perman= ent or temporary? Should other servers change their listings when seeing a= redirect? Redirects have caused interoperability problems in HTTP; perhap= s a little deeper review of the need for the functionality would help here. Redirects at the LoST layer are responses to a specific query. Once an ans= wer has been received from the server to which the query was redirected, it will have an "expires" attribute. The same query can be retried after that poin= t to the original server. Other queries may be sent to the LoST redirecting ser= ver at any point; they may also be redirected, but since the LoST client will n= ot know what application logic is being applied for the LoST redirection, this= is the correct behavior for a LoST server that has followed its normal process for identifying which LoST server to talk to for that service. The current text in 13.3 is: A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. During a recursive query, a server receiving a response can decide whether it wants to follow the redirection or simply return the response to its upstream querier. Would adding the following change meet the need: A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. During a recursive query, a server receiving a response can decide whether it wants to follow the redirection or simply return the response to its upstream querier. The "expires" value in the response returned by the server handling the redirected query indicates the earliest time at which a new query might be needed (see section 5.2). The same query SHOULD NOT be directed to the server which gave redirect prior to that time. If a redirect is intend to move the entire service, rather than be limited = to queries (moving all response formerly served from lost.example.com to lost.example.net), then the HTTP-level redirects should be used and the permanent 301 code should be used. >I'm inferring from section 14. that HTTP redirects MUST be supported by cl= ients as well as LoST redirects. Can that be made a normative requirement? The document refers to RFC 2616, which gives these as SHOULD requirements in 10.3.X. I do not believe it is appropriate to shift the requirement from t= he SHOULD in HTTP to a MUST here. Can you describe any reason why this should be str= onger? >2a. Open-ended URI types >I'd like to see more guidance on what URIs are returned. The risk that th= e LoST server will return a URI that can't be used by the seeker is a bad r= isk to take when it comes to emergency services. I think we have to be careful about this. The base aim here is to make sur= e that the contact URIs returned are those provisioned by those responsible for the ju= risdiction. We can provide advice on that, but it is ultimately up to those with the le= gal responsibility to provide the records. The working group chose to split the advice (which is in draft-ietf-ecrit-phonebcp) from the protocol semantics = exactly because some jurisdiction may choose to use URIs that are specific to their conditions. Mailto may be reasonable in the eyes of some jurisdiction, in = other words, and the protocol should not eliminate it as a possibility. = > - Add "tel" URI examples to the examples; Explain that in the worst case = of not being able to use the URI types presented, seekers that have user in= terfaces should present the telephone number to the user; recommend that ph= one numbers be provided this way as fallbacks for emergency services This is the serviceNumber element; please see Section 5.7. > - limit the types used: no data or mailto URIs; better yet have a registr= y of types that *can* be used > - In the case of SIP URIs, what kind of contact can be made? Can this UR= I get a human voice, a voice mailbox, a presentity or other? Can you rephrase this question? I do not understand how the URI will deter= mine the method, which it sounds like is the root of the question. Can you give= a further example here? > - Differentiate between contact and resource URIs? A resource URI obtain= s something static, a contact URI may be able to begin a conversation... This service returns contact URIs, as the abstract and Overview of Protocol= usage (section 3) make clear. = >I'd like a little discussion of the requirement that each URI scheme may a= ppear only once. That seems to prevent some fairly common use cases like p= roviding one number for voice mail and one number to reach an operator. Th= e proliferation of http URIs makes this even worse -- many different kinds = of services can be hosted on http URIs. The Atom link rel provides an exam= ple of how one might deal with this problem. This was discussed extensively in the working group. The aim here is to av= oid the end user having to select among choices which are equivalent at the protoco= l level while they have an emergency. If the system returns 5 sip contact URIs, th= e user should not have to select among them while simultaneously beating back the flames in their car. If a jurisdiction needs to arrange failover, it shoul= d do that using a URI to a system capable of dispatch or failover (the NENA and ETSI = folks have a whole set of models of how that works using Emergency Service Routing Proxies (ESRPs) ) >2b. IRIs > >Is support for IRIs explicitly not desired? As the Internationalization Considerations notes, this is primarily intended for machine-to-machine communications. The URI form of IRIs is preferred for this purpose in general, and it specifically preferred. We did include complex types for displayName and message, since those are not machine-to-machine. >2c. URI security/privacy > >I assume both LoST URIs (found in NAPTR) and service URIs can contain anyt= hing allowed by the URI scheme; long paths, query elements, anchor points. = I can see a slight privacy issue here, because the URIs can contain tokens = allowing communication from the LoST server that provided the URI to the se= rvice hosting that URI. This question is not clear to me. There are no tokens that allow communica= tion from the LoST server; there are tokens like the "sourceId", which identifies a p= articular mapping? Are you concerned that the requirement that it be unique has some privacy consequence? The current text there is: The 'sourceId' attribute identifies a particular mapping and contains an opaque token that MUST be unique among all different mappings maintained by the authoritative source for that particular service. For example, a Universally Unique Identifier (UUID) is a suitable format. Do you wish to suggest additional text here? >This document doesn't talk about preserving URIs end-to-end. What if a Lo= ST resolver were to "helpfully" try to change URIs before passing them on t= o seekers? Is there some other document that covers this? The LoST resolver returns whatever was provisioned; if it changes the URIs = that were provisioned, it is not behaving according to the spec. > >3. Overlooked HTTP features. > >A number of features that are commonly overlooked when using HTTP this way= are not mentioned. I like that HTTP caching is disabled but it looks like= there's a cut-and-paste error in that part of the spec: > > The HTTP request MUST use the Cache-Control response > directive "no-cache" to HTTP-level "caching even by caches that have > been configured to return stale responses to client requests." You are right; sorry about the error. I suggest the following RFC Editor n= ote: OLD The HTTP request MUST use the Cache-Control response directive "no-cache" to HTTP-level "caching even by caches that have been configured to return stale responses to client requests." NEW The HTTP request MUST use the Cache-Control response directive "no-cache" to disable HTTP-level caching even by caches that h= ave been configured to return stale responses to client requests. >For the rest I suggest adding: > >"LoST servers MUST handle the Expect header, conditional headers and Conte= nt-* headers on requests according to HTTP requirements (possibly by failin= g the request). They MUST also handle OPTIONS and HEAD and GET requests ev= en if it's by responding with canned 200 responses. > >"LoST clients MUST include a Host header and MUST handle all possible HTTP= response codes. > >"Both LoST clients and servers MUST handle chunked transfer-encoded messag= e bodies." My personal preference is to retain the reference to 2616 and assume that t= he LoST server and client will use the available HTTP servers and clients as source= s. My concern is that buy calling out these, the casual reader may assume that other HTTP requirements do not apply. I would be more supportive of language like "Client and server developers are reminded that full support of RFC 2616 HTTP facilities is expected. Am= ong those commonly missed are X, Y, Z. If LoST Client or Servers re-implement HTTP, rather using available servers or client code as a base, careful atte= ntion must be paid to full interoperability". Would that work for you? Thanks for the review, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 00:53:34 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A0028C9EF; Thu, 21 Feb 2008 00:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F5ZvrOuafQp; Thu, 21 Feb 2008 00:53:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD3A28C9CB; Thu, 21 Feb 2008 00:53:32 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB69628C9C5 for ; Thu, 21 Feb 2008 00:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIl6rskaSZxv for ; Thu, 21 Feb 2008 00:53:31 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 938C928C9C2 for ; Thu, 21 Feb 2008 00:53:30 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 08:53:26 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp041) with SMTP; 21 Feb 2008 09:53:26 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ShgloHQDSpiFZr7T06JdTyTlXCDYWoN6nlVxXGz yS0fQT+UWDd4ol Message-ID: <47BD3C03.9040504@gmx.net> Date: Thu, 21 Feb 2008 10:53:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: DISCUSS: draft-ietf-ecrit-mapping-arch] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org -------- Original Message -------- Subject: DISCUSS: draft-ietf-ecrit-mapping-arch Date: Wed, 20 Feb 2008 22:14:25 -0800 (PST) From: Cullen Jennings To: iesg@ietf.org CC: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-mapping-arch@tools.ietf.org Discuss: These are two pretty easy to fix issues: We need to have this document in sync with LOST about what shapes are allowed in a location. Right now Lost seems to allow Point, Polygon, Circle, Ellipse, ArcBand. Coverage regions are described by sets of polygons enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs a point- in-polygon operation to find the polygon that contains the query point. (More complicated geometric matching algorithms may be added in the future.) The forest guides need to decide which coverage region the query is in. I think the FG need to use the same algorithm that the LOST servers use or it is possible to miss the correct tree. _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 01:04:51 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113C528CA20; Thu, 21 Feb 2008 01:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoaF+ss3sgKI; Thu, 21 Feb 2008 01:04:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2303028C9C6; Thu, 21 Feb 2008 01:04:50 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D9028C9A9 for ; Thu, 21 Feb 2008 01:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfaatJceBNDF for ; Thu, 21 Feb 2008 01:04:46 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 41C4528C9FE for ; Thu, 21 Feb 2008 01:04:46 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 09:04:41 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp025) with SMTP; 21 Feb 2008 10:04:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19aehRGXJFacu3uS46fqVk8wubjsntYCUjuPeVc31 0wXQmvRTV6IRlV Message-ID: <47BD3EA7.4050109@gmx.net> Date: Thu, 21 Feb 2008 11:04:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-dhc-lost-discovery: DISCUSS by Jari Arkko X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org *Document:* draft-ietf-ecrit-dhc-lost-discovery *Version:* 02 *Commented by:* Jari Arkko *Comment:* First, a process problem: We have had a model for DHCP option development that involves an effort in the WG that is interested in the functionality (in this case ECRIT) but also review by DHC WG. This is accomplished through simultaneous WGLCs in both WGs. In my search of DHC WG archives, there's nothing on this document. We need that review, and I would suggest starting a WGLC in the DHC WG now, followed possibly by discussion in Philadelphia meeting (if needed) so that we can get the review done but do not lose much time. I apologize for not catching this earlier. The DHC chairs and me try to remind WG chairs and the iesg of this policy on a regular basis, maybe we should send another reminder. The DHC WG also has an early warning system review team, not sure if this caught their attention. Or have I missed some discussion? If review has happened, I have no problem. Technical content: Section 5 (DHCPv6) talks about how DHCPv4 clients can request options. Is this text in the right place? https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-dhc-lost-discovery/comment/77909/? *Document:* draft-ietf-ecrit-dhc-lost-discovery *Version:* 02 *Commented by:* Jari Arkko *Comment:* Like David Hankins, I wondered about the expression "Only onee domain name MUST be present ...". I would suggest a rewrite to "Exactly one domain MUST be present ...", possibly followed by the explanation that anything after the last zero by should be ignored. By the way, I was confused about the level of DHC WG review, because (a) the writeup did not say anything about it and (2) the mails about the WGLC on DHC WG did not have the draft or even WG name on the title. https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-dhc-lost-discovery/comment/77912/? *Document:* draft-ietf-ecrit-dhc-lost-discovery *Version:* 02 *Commented by:* Jari Arkko *Comment:* Section 5 (DHCPv6) talks about how DHCPv4 clients can request options. Is this text in the right place? Section 4 seems the correct place. David Hankins' comments on Section 3 limit "254" have not been addressed. David sent his comments on the DHC WG list on April 27, 2007. https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-dhc-lost-discovery/comment/77911/? _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 01:05:00 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF8228CA1D; Thu, 21 Feb 2008 01:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI2WBcYL6Yg3; Thu, 21 Feb 2008 01:04:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEB828CA06; Thu, 21 Feb 2008 01:04:56 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D724728CA06 for ; Thu, 21 Feb 2008 01:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znJcml2LmsE4 for ; Thu, 21 Feb 2008 01:04:55 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AC4CD28C9FA for ; Thu, 21 Feb 2008 01:04:54 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 09:04:50 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp022) with SMTP; 21 Feb 2008 10:04:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/GVqNFuTPG9pD48oaIG7IYZRPncFfowX4Bne4bUO 3LNdRKmZzBcr1Q Message-ID: <47BD3EB0.1000404@gmx.net> Date: Thu, 21 Feb 2008 11:04:48 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-dhc-lost-discovery: DISCUSS by Tim Polk X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org *Document:* draft-ietf-ecrit-dhc-lost-discovery *Version:* 02 *Commented by:* Tim Polk *Comment:* This mechanism does not seem to support internationalized domain names. First, there is no discussion about converting IDNs to and from ACE format. Secondly, the size limitations (consistent with RFC 1035) seem inadequate for IDNs. 63 octets doesn't seem like enough for a typical label ACE-encoded label. I also worry about the 255 octet limit for the domain name. https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-dhc-lost-discovery/comment/77897/? _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 01:05:02 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67CB028CA4E; Thu, 21 Feb 2008 01:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CZ8P+W2ANyl; Thu, 21 Feb 2008 01:05:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03B528CA1D; Thu, 21 Feb 2008 01:05:01 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8737428CA09 for ; Thu, 21 Feb 2008 01:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MI6XuzSIF7E for ; Thu, 21 Feb 2008 01:04:59 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 49F4328C9FA for ; Thu, 21 Feb 2008 01:04:59 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 09:04:55 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp019) with SMTP; 21 Feb 2008 10:04:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX186CZhTQuM6eXH4WiOWv76JRKJ+TWAFjM6DCu82YN AC610m3+3tdhKJ Message-ID: <47BD3EB5.50104@gmx.net> Date: Thu, 21 Feb 2008 11:04:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-dhc-lost-discovery: DISCUSS by Russ Housley X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org *Document:* draft-ietf-ecrit-dhc-lost-discovery *Version:* 02 *Commented by:* Russ Housley *Comment:* There are values that need to be assigned by IANA, but it appears that the document is not consistent about about the manner in which the assigned values should be inserted in the document. For example, as pointd out in the Gen-ART Review by Vijay Gurbani, the code in Figure 1 is "TBD", but the text right underneath the figure refers to the code as "(TBD1)". Consistent symbolic substitution is needed to avoid errors. https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-dhc-lost-discovery/comment/77839/? _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 01:52:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C03428CA86; Thu, 21 Feb 2008 01:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1FZlDXaAEnH; Thu, 21 Feb 2008 01:52:47 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F50328CA26; Thu, 21 Feb 2008 01:52:47 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7C728C9AE for ; Thu, 21 Feb 2008 01:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwBi81YwnRx0 for ; Thu, 21 Feb 2008 01:52:46 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6227728CA86 for ; Thu, 21 Feb 2008 01:52:14 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 09:52:08 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp031) with SMTP; 21 Feb 2008 10:52:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wxD0MRzKwaJdw5NlnCzCMSuTIytyHdgvSqmx48h aLggr/NspNrIQu Message-ID: <47BD49C0.9000009@gmx.net> Date: Thu, 21 Feb 2008 11:52:00 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: COMMENT: draft-ietf-ecrit-mapping-arch] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: COMMENT: draft-ietf-ecrit-mapping-arch Date: Thu, 21 Feb 2008 01:12:41 -0800 (PST) From: Chris Newman To: iesg@ietf.org CC: ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-mapping-arch@tools.ietf.org Comment: TLS and XML digital signatures should be informative references. _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 10:41:25 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F1A28CA51; Thu, 21 Feb 2008 10:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEMU9cRYkI-h; Thu, 21 Feb 2008 10:41:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989EF28C3CA; Thu, 21 Feb 2008 10:41:21 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4ADD28C65C for ; Thu, 21 Feb 2008 10:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3Ay9h6wGh37 for ; Thu, 21 Feb 2008 10:41:15 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CEF993A6CFA for ; Thu, 21 Feb 2008 10:41:14 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 18:41:10 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp044) with SMTP; 21 Feb 2008 19:41:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18c3zMz3WQcT2O/mExg0JzaRLc0wLnXxCQBioKLbV BRqg9CGydshDab Message-ID: <47BDC5C2.4010600@gmx.net> Date: Thu, 21 Feb 2008 20:41:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: COMMENT: draft-ietf-ecrit-mapping-arch] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: COMMENT: draft-ietf-ecrit-mapping-arch Date: Thu, 21 Feb 2008 08:29:07 -0800 (PST) From: Jari Arkko To: iesg@ietf.org CC: christian.vogt@ericsson.com,ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-mapping-arch@tools.ietf.org Comment: Christian Vogt's review: This document describes an architecture for location based service discovery. The architecture resolves location information into URLs. The document is well written and about ready for publication. One thing that I would have wished as a reader is more clarity on the organization of mapping information at the beginning of the document. The described architecture uses "forest guides" and trees of LoST servers for mapping resolution. It would be helpful for the reader if the document would define forest guides as the top level of a single conceptual hierarchy, which, at lower levels, branches into what is called "trees" in the document. A smaller nit: The reader may wonder why the forest guides in figure 1 are interconnected. It may be worthwhile to explicitly state that these connections symbolize the optional synchronization protocol that may be executed between them. _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 10:47:16 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2DC28CABB; Thu, 21 Feb 2008 10:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.567 X-Spam-Level: X-Spam-Status: No, score=-0.567 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfa-4g9h-RYk; Thu, 21 Feb 2008 10:47:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBFD3A6D0E; Thu, 21 Feb 2008 10:47:14 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCFF928C9DE for ; Thu, 21 Feb 2008 10:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLJHmVg9YyAC for ; Thu, 21 Feb 2008 10:47:10 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 567DA28CA3F for ; Thu, 21 Feb 2008 10:47:09 -0800 (PST) Received: (qmail invoked by alias); 21 Feb 2008 18:47:05 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp053) with SMTP; 21 Feb 2008 19:47:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX195zSET3BN5feA9eHShszkUPHalC3kl7MJ0duStmn RL4zY9mrmvsmxs Message-ID: <47BDC726.60203@gmx.net> Date: Thu, 21 Feb 2008 20:47:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: DISCUSS and COMMENT: draft-ietf-ecrit-dhc-lost-discovery] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: DISCUSS and COMMENT: draft-ietf-ecrit-dhc-lost-discovery Date: Thu, 21 Feb 2008 08:26:21 -0800 (PST) From: Jari Arkko To: iesg@ietf.org CC: christian.vogt@ericsson.com,ecrit-chairs@tools.ietf.org, draft-ietf-ecrit-dhc-lost-discovery@tools.ietf.org Discuss: Section 5 (DHCPv6) talks about how DHCPv4 clients can request options. Is this text in the right place? Section 4 seems the correct place. David Hankins' comments on Section 3 limit "254" have not been addressed. David sent his comments on the DHC WG list on April 27, 2007. Comment: Like David Hankins, I wondered about the expression "Only onee domain name MUST be present ...". I would suggest a rewrite to "Exactly one domain MUST be present ...", possibly followed by the explanation that anything after the last zero by should be ignored. By the way, I was confused about the level of DHC WG review, because (a) the writeup did not say anything about it and (2) the mails about the WGLC on DHC WG did not have the draft or even WG name on the title. I found the mails eventually, but... Christian Vogt's review: This document defines a DHCP-based mechanism for LoST server discovery. LoST server discovery is unspecified by the LoST protocol, but is an important complement to it in scenarios where client pre-configuration is infeasible. LoST server discover in this document is realized through new DHCPv4/v6 options that carry a LoST server's domain name. Summary: The document is well-written and -- after a revision addressing the comments below -- will be ready for publication. (1) Specification clarity Authors should clarify how the domain name encoding specified in section 3 fits into the encoding of the DHCPv4 option specified in section 4. Specifically: - How does the length fields in the domain name encoding relate to the length field in the DHCPv4 option? Clarification is needed that the latter is the length of the entire domain name encoding, whereas the former is the length of a single domain name label. - It should be stated that the values s1, s2, s3, ... in the DHCPv4 option represent the domain name labels in the domain name encoding. (2) Relationship to LoST Protocol Security The security considerations of this document do not address how the specified LoST server discovery procedure supports the security mechanisms suggested for the LoST protocol. E.g., one way to protect LoST is via TLS. This requires knowledge of a LoST server's public key in addition to its domain name or IP address. The discovery mechanism described in this document cannot provide both: The public key would have to be either pre-configured into a host, or be verifiable via a trusted 3rd party. The security considerations should therefore state that, to bootstrap LoST in a secure manner, client pre-configuration or further infrastructure may be necessary besides DHCP. (3) Editorial comments: - 2nd paragraph in section 1: s/LoST server DHCP/LoST server, DHCP/ - Move 3rd-to-last paragraph in section 5 to section 4 because it is DHCPv4-specific. - 1st paragraph in section 5: s/This document defines/This section defines/ - 1st paragraph in section 5: s/DHCPv6 options/DHCPv6 option/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 23:02:54 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436573A6C39; Thu, 21 Feb 2008 23:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[AWL=-1.892, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e28orTOHokYp; Thu, 21 Feb 2008 23:02:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0593A6C09; Thu, 21 Feb 2008 23:02:51 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF3A3A68D9 for ; Thu, 21 Feb 2008 23:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3T3pvrer0Yn for ; Thu, 21 Feb 2008 23:02:46 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F387D3A6C1C for ; Thu, 21 Feb 2008 23:02:03 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1M71wie027737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Feb 2008 08:01:58 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1M71pbI032285 for ; Fri, 22 Feb 2008 08:01:57 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 08:01:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 08:01:52 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB0555F7@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-ecrit-lost Thread-Index: Ach0sqdW/PwpiZh0SESiO0ekHPrJHQAImOnQ From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 22 Feb 2008 07:01:52.0322 (UTC) FILETIME=[CD439220:01C87520] Subject: [Ecrit] WG: DISCUSS: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI = -----Urspr=FCngliche Nachricht----- Von: ext Ted Hardie [mailto:hardie@qualcomm.com] = Gesendet: Donnerstag, 21. Februar 2008 19:53 An: Lisa Dusseault Cc: iesg@ietf.org; ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-lost@tools= .ietf.org Betreff: Re: DISCUSS: draft-ietf-ecrit-lost At 8:57 AM -0800 2/21/08, Lisa Dusseault wrote: >On Feb 20, 2008, at 2:56 PM, Ted Hardie wrote: > >>At 1:49 PM -0800 2/20/08, Lisa Dusseault wrote: >> >>>Discuss: >>> >>>1. Redirects >>> >>... >> >>Would adding the following change meet the need: >> >> A LoST server can respond indicating that the querier should redirect >> the query to another server, using the element. The >> element includes a 'target' attribute indicating the LoST application >> unique string (see Section 4) that the client SHOULD be contacting >> next, as well as the 'source' attribute indicating the server that >> generated the redirect response and a 'message' attribute explaining >> the reason for the redirect response. During a recursive query, a >> server receiving a response can decide whether it wants to >> follow the redirection or simply return the response to its upstream >> querier. The "expires" value in the response returned by the server >> handling the redirected query indicates the earliest time at which >> a new query might be needed (see section 5.2). The same query >> SHOULD NOT be directed to the server which gave redirect prior to >> that time. >> > >Referring to the "expires" value here is most helpful. I forgot about tha= t attribute when I read this section. > >I'm still confused about the way this is a redirect "for a specific query"= . Until I saw that phrase elsewhere in your response, I missed the specifi= city: I thought that the agent (isn't it a client, not necessarily a server= ) receiving a response would send all queries to the new redirec= ted server. No, it is specific to a particular query. Take the case where a jurisdicti= on is having a major event like the Olympics in a specific area. During the course of that event, the jurisdiction may redirect certain services (like= the top level sos, police or ambulance services) to special LoST servers when = the query is from the area of the event. Other services, like sos.gas, sos.physician or sos.poison, might not be redirected. = >The text has "the query" and "the same query" but this doesn't say what sh= ould be done about other queries. = Here's a full, proposed RFC editor note: OLD A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. During a recursive query, a server receiving a response can decide whether it wants to follow the redirection or simply return the response to its upstream querier. NEW A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. During a recursive query, a server receiving a response can decide whether it wants to follow the redirection or simply return the response to its upstream querier. The "expires" value in the response returned by the server handling the redirected query indicates the earliest time at which the response would need to be refreshed (see section 5.2). A query for the same tuple of location and service SHOULD NOT be directed to the server which gave redirect prior to that time. > >> >>>I'm inferring from section 14. that HTTP redirects MUST be supported by = clients as well as LoST redirects. Can that be made a normative requiremen= t? >>> >> >>The document refers to RFC 2616, which gives these as SHOULD requirements= in >>10.3.X. I do not believe it is appropriate to shift the requirement from= the SHOULD >>in HTTP to a MUST here. Can you describe any reason why this should be s= tronger? >> > >Fair enough. It's been my experience (e.g. in WebDAV interop tests) that = some servers fully expect all clients to handle these, and treat these as i= f they were a MUST, when in fact clients can choose not to follow them. > >> >>>2a. Open-ended URI types >>>I'd like to see more guidance on what URIs are returned. The risk that = the LoST server will return a URI that can't be used by the seeker is a bad= risk to take when it comes to emergency services. >>> >> >>I think we have to be careful about this. The base aim here is to make s= ure that the >>contact URIs returned are those provisioned by those responsible for the = jurisdiction. >>We can provide advice on that, but it is ultimately up to those with the = legal >>responsibility to provide the records. The working group chose to split = the >>advice (which is in draft-ietf-ecrit-phonebcp) from the protocol semantic= s exactly >>because some jurisdiction may choose to use URIs that are specific to the= ir >>conditions. Mailto may be reasonable in the eyes of some jurisdiction, i= n other >>words, and the protocol should not eliminate it as a possibility. >> > >You've definitely thought about this in the WG but a new reader of the doc= ument has to work to figure out where responsibility for being able to inte= rconnect with the service URI might lie, and whether interoperability probl= ems with certain URI types is likely. Is there something about this in ano= ther document? = > >A non-normative note on "Interoperability Concerns with Service URIs" woul= d be very good here if it's not elsewhere, containing just the kind of info= rmation on how URIs are provisioned and how one might try to ensure lowest-= common-denominator interoperability. I propose to add this to the end of Section 3. Here is a proposed RFC Edit= or's note: OLD: A service-specific Best Current Practice (BCP) document, such as [20], governs whether a client is expected to invoke the mapping service just before needing the service or whether to rely on cached answers. Cache entries expire at their expiration time (see Section 5.2), or they become invalid if the caller's device moves beyond the boundaries of the service region. NEW: A service-specific Best Current Practice (BCP) document, such as [20], governs whether a client is expected to invoke the mapping service just before needing the service or whether to rely on cached answers. Cache entries expire at their expiration time (see Section 5.2), or they become invalid if the caller's device moves beyond the boundaries of the service region. Service-specific Best Curent Practice documents may also provide guidance on the contact URI schemes most appropriate to the service. As a general set of guidelines, URI schemes that do not provide mechanisms for actually initiating a contact method should be avoided (e.g. data, i= nfo, cid, tag) as transforming those references into contact mechanisms requires a layer of indirection that makes the overall mechanism more fragile. Provisionally registered URI schemes should also be carefully considered before use, because they are subject to change in core semantics. >The non-normative note could also mention the element and = how to use it as a backup to ensure the end-user can reach the service. > > >There's also an opportunity, not ruled out by your response, to require Lo= ST clients to handle certain URIs. Since SIP URIs appear in all the exampl= es, one might require or strongly recommend LoST clients should be able to = handle all types of SIP URIs. In the long run, it would be good to spread = awareness about what types of URIs are most commonly supported and used by = clients. An IANA registry may be too much for that purpose, but there ough= t to be something ecrit can do... There is certainly a strong expectation in the working group that SIP will be common. But what a LoST client can do to "handle" SIP URIs is limited. It must be able to handle the full URI syntax and thus any URI scheme or production returned. But once that URI has been returned, it is up to other code to invoke SIP (or XMPP or any other protocol). = We also cannot require, at a protocol level, that a LoST client should alwa= ys have access to a SIP stack. There are valid deployment scenarios here that have nothing but Tel URIs/serviceNumbers. For non-emergency uses of LoST the appropriate URIs may also be completely different. >I still disagree about certain URIs. You may be right about mailto: but t= hat's stretching it; the data: URI is really harmful, not just "likely usel= ess". I won't insist on this however. I hope the text proposed above handles this issue for you. > >> >> >>>- limit the types used: no data or mailto URIs; better yet have a regist= ry of types that *can* be used >>>- In the case of SIP URIs, what kind of contact can be made? Can this U= RI get a human voice, a voice mailbox, a presentity or other? >>> >> >>Can you rephrase this question? I do not understand how the URI will det= ermine >>the method, which it sounds like is the root of the question. Can you gi= ve a >>further example here? >> > >In theory the URI does not determine whether you'll get a human operator o= r a voice mailbox or a presentity; in practice, however, services often def= ine different URIs for these things or have available specific URIs as well= as generic ones. = > >The information about what the URI is likely to get you would have to be p= rovided by the jurisdiction providing the service, along with the URI. > >Here's one thing I imagined might be done to address this issue: > > sip://switchboard.police.muenchen.de > sip://deafservice.police.muenchen.de > > > >> >> >>>- Differentiate between contact and resource URIs? A resource URI obtai= ns something static, a contact URI may be able to begin a conversation... >>> >> >>This service returns contact URIs, as the abstract and Overview of Protoc= ol usage >>(section 3) make clear. >> > >Yes, and that's all right as far as it goes. I note that's descriptive te= xt, not normative or even guidance text. > >> >>>I'd like a little discussion of the requirement that each URI scheme may= appear only once. That seems to prevent some fairly common use cases like= providing one number for voice mail and one number to reach an operator. = The proliferation of http URIs makes this even worse -- many different kind= s of services can be hosted on http URIs. The Atom link rel provides an ex= ample of how one might deal with this problem. >>> >> >>This was discussed extensively in the working group. The aim here is to = avoid the >>end user having to select among choices which are equivalent at the proto= col level >>while they have an emergency. If the system returns 5 sip contact URIs, = the user >>should not have to select among them while simultaneously beating back the >>flames in their car. If a jurisdiction needs to arrange failover, it sho= uld do that >>using a URI to a system capable of dispatch or failover (the NENA and ETS= I folks >>have a whole set of models of how that works using Emergency Service Rout= ing >>Proxies (ESRPs) ) >> > >That's an excellent goal and one I didn't think of when reading the docume= nt. > >Perhaps instead of annotating URIs with what kind of link they are (as in = my example above), better guidance would be for jurisdictions to provide a = small number of general-purpose URIs ? Can one hope to provide a single SI= P URI for both voice and text, and allow the user agent to automatically br= ing the caller to the correct service version? I believe any guidance to jurisdictions on this point should be in phonebcp. >> >>>2b. IRIs >>> >>>Is support for IRIs explicitly not desired? >>> >> >>As the Internationalization Considerations notes, this is primarily inten= ded >>for machine-to-machine communications. The URI form of IRIs is preferred >>for this purpose in general, and it specifically preferred. We did inclu= de >>complex types for displayName and message, since those are not >>machine-to-machine. >> >> >> >>>2c. URI security/privacy >>> >>>I assume both LoST URIs (found in NAPTR) and service URIs can contain an= ything allowed by the URI scheme; long paths, query elements, anchor points= . I can see a slight privacy issue here, because the URIs can contain token= s allowing communication from the LoST server that provided the URI to the = service hosting that URI. >>> >> >>This question is not clear to me. There are no tokens that allow communi= cation from >>the LoST server; there are tokens like the "sourceId", which identifies a= particular >>mapping? Are you concerned that the requirement that it be unique has >>some privacy consequence? The current text there is: >> >>The 'sourceId' attribute identifies a particular mapping and contains >> an opaque token that MUST be unique among all different mappings >> maintained by the authoritative source for that particular service. >> For example, a Universally Unique Identifier (UUID) is a suitable >> format. >> >>Do you wish to suggest additional text here? >> > >No, I thought about this one overnight and I realized that this situation = is just what it is; URIs (particularly HTTP URIs) can contain all kinds of = used and unused parameters and tokens, and they will be supported, and any = possible fallout from that is already a concern. > >> >>>This document doesn't talk about preserving URIs end-to-end. What if a = LoST resolver were to "helpfully" try to change URIs before passing them on= to seekers? Is there some other document that covers this? >>> >> >>The LoST resolver returns whatever was provisioned; if it changes the URI= s that >>were provisioned, it is not behaving according to the spec. >> > >I agree that's correct, I'm not sure it's required by the spec. I may be = too paranoid here. > >> >> >>> >>>3. Overlooked HTTP features. >>> >>>A number of features that are commonly overlooked when using HTTP this w= ay are not mentioned. I like that HTTP caching is disabled but it looks li= ke there's a cut-and-paste error in that part of the spec: >>> >>> The HTTP request MUST use the Cache-Control response >>> directive "no-cache" to HTTP-level "caching even by caches that have >>> been configured to return stale responses to client requests." >>> >> >> >>You are right; sorry about the error. I suggest the following RFC Editor= note: >> >>OLD >>The HTTP request MUST use the Cache-Control response >> directive "no-cache" to HTTP-level "caching even by caches that have >> been configured to return stale responses to client requests." >> >>NEW >> >>The HTTP request MUST use the Cache-Control response >> directive "no-cache" to disable HTTP-level caching even by caches that= have >> been configured to return stale responses to client requests. >> >> >>>For the rest I suggest adding: >>> >>>"LoST servers MUST handle the Expect header, conditional headers and Con= tent-* headers on requests according to HTTP requirements (possibly by fail= ing the request). They MUST also handle OPTIONS and HEAD and GET requests = even if it's by responding with canned 200 responses. >>> >>>"LoST clients MUST include a Host header and MUST handle all possible HT= TP response codes. >>> >>>"Both LoST clients and servers MUST handle chunked transfer-encoded mess= age bodies." >>> >> >>My personal preference is to retain the reference to 2616 and assume that= the LoST >>server and client will use the available HTTP servers and clients as sour= ces. My concern >>is that buy calling out these, the casual reader may assume that other HT= TP >>requirements do not apply. >> >>I would be more supportive of language like "Client and server developers >>are reminded that full support of RFC 2616 HTTP facilities is expected. = Among >>those commonly missed are X, Y, Z. If LoST Client or Servers re-implement >>HTTP, rather using available servers or client code as a base, careful at= tention >>must be paid to full interoperability". >> >>Would that work for you? >> > >That would work for me very nicely, thanks -- a definite improvement. A m= inor nit is that one of the reasons these are commonly overlooked is not be= cause the software is re-implementing HTTP, but because the software uses a= library or extension mechanism that encourages the service to ignore these= required features because that's the default. = Proposed RFC Editor Note: In Section 14. OLD: LoST needs an underlying protocol transport mechanisms to carry requests and responses. This document defines the use of LoST over HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future documents. The available transport mechanisms are determined through the use of the LoST U-NAPTR application. In protocols that support content type indication, LoST uses the media type application/ lost+xml. NEW: LoST needs an underlying protocol transport mechanisms to carry requests and responses. This document defines the use of LoST over HTTP and LoST over HTTP-over-TLS. Client and server developers are reminded that full support of RFC 2616 HTTP facilities is expected. If LoST Client or Servers re-implement HTTP, rather using available servers or client code as a base, careful attention must be paid to full interoperability. Other transport mechanisms are left to future documents. The available transport= mechanisms are determined through the use of the LoST U-NAPTR application. In protoco= ls that support content type indication, LoST uses the media type application/lost+xml. Thanks for your review, Ted >Lisa _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Feb 21 23:03:00 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7164628C0F9; Thu, 21 Feb 2008 23:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KraFDzDIXgEK; Thu, 21 Feb 2008 23:02:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5554E3A6C21; Thu, 21 Feb 2008 23:02:51 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739EB3A68D9 for ; Thu, 21 Feb 2008 23:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK9zPvnSR4TI for ; Thu, 21 Feb 2008 23:02:46 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id F1BFE3A6C17 for ; Thu, 21 Feb 2008 23:02:03 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m1M71veC027734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Feb 2008 08:01:58 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m1M71pbG032285 for ; Fri, 22 Feb 2008 08:01:57 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 08:01:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Feb 2008 08:01:51 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB0555F6@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-ecrit-lost Thread-Index: Ach0qvbt28YuHqUeQUG4ZNNh1Qe3EAAKeZFA From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 22 Feb 2008 07:01:51.0697 (UTC) FILETIME=[CCE43410:01C87520] Subject: [Ecrit] WG: DISCUSS: draft-ietf-ecrit-lost X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0116985713==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0116985713== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87520.CD020336" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87520.CD020336 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI ________________________________ Von: ext Lisa Dusseault [mailto:lisa@osafoundation.org]=20 Gesendet: Donnerstag, 21. Februar 2008 18:58 An: Ted Hardie Cc: iesg@ietf.org; ecrit-chairs@tools.ietf.org; draft-ietf-ecrit-lost@tools.ietf.org Betreff: Re: DISCUSS: draft-ietf-ecrit-lost On Feb 20, 2008, at 2:56 PM, Ted Hardie wrote: At 1:49 PM -0800 2/20/08, Lisa Dusseault wrote: Discuss: 1. Redirects ... =09 Would adding the following change meet the need: A LoST server can respond indicating that the querier should redirect the query to another server, using the element. The element includes a 'target' attribute indicating the LoST application unique string (see Section 4) that the client SHOULD be contacting next, as well as the 'source' attribute indicating the server that generated the redirect response and a 'message' attribute explaining the reason for the redirect response. During a recursive query, a server receiving a response can decide whether it wants to follow the redirection or simply return the response to its upstream querier. The "expires" value in the response returned by the server handling the redirected query indicates the earliest time at which a new query might be needed (see section 5.2). The same query SHOULD NOT be directed to the server which gave redirect prior to that time. Referring to the "expires" value here is most helpful. I forgot about that attribute when I read this section. I'm still confused about the way this is a redirect "for a specific query". Until I saw that phrase elsewhere in your response, I missed the specificity: I thought that the agent (isn't it a client, not necessarily a server) receiving a response would send all queries to the new redirected server.=20 The text has "the query" and "the same query" but this doesn't say what should be done about other queries. =20 I'm inferring from section 14. that HTTP redirects MUST be supported by clients as well as LoST redirects. Can that be made a normative requirement? The document refers to RFC 2616, which gives these as SHOULD requirements in 10.3.X. I do not believe it is appropriate to shift the requirement from the SHOULD in HTTP to a MUST here. Can you describe any reason why this should be stronger? Fair enough. It's been my experience (e.g. in WebDAV interop tests) that some servers fully expect all clients to handle these, and treat these as if they were a MUST, when in fact clients can choose not to follow them. 2a. Open-ended URI types I'd like to see more guidance on what URIs are returned. The risk that the LoST server will return a URI that can't be used by the seeker is a bad risk to take when it comes to emergency services. I think we have to be careful about this. The base aim here is to make sure that the contact URIs returned are those provisioned by those responsible for the jurisdiction. We can provide advice on that, but it is ultimately up to those with the legal responsibility to provide the records. The working group chose to split the advice (which is in draft-ietf-ecrit-phonebcp) from the protocol semantics exactly because some jurisdiction may choose to use URIs that are specific to their conditions. Mailto may be reasonable in the eyes of some jurisdiction, in other words, and the protocol should not eliminate it as a possibility.=20 You've definitely thought about this in the WG but a new reader of the document has to work to figure out where responsibility for being able to interconnect with the service URI might lie, and whether interoperability problems with certain URI types is likely. Is there something about this in another document? =20 A non-normative note on "Interoperability Concerns with Service URIs" would be very good here if it's not elsewhere, containing just the kind of information on how URIs are provisioned and how one might try to ensure lowest-common-denominator interoperability. The non-normative note could also mention the element and how to use it as a backup to ensure the end-user can reach the service. There's also an opportunity, not ruled out by your response, to require LoST clients to handle certain URIs. Since SIP URIs appear in all the examples, one might require or strongly recommend LoST clients should be able to handle all types of SIP URIs. In the long run, it would be good to spread awareness about what types of URIs are most commonly supported and used by clients. An IANA registry may be too much for that purpose, but there ought to be something ecrit can do... I still disagree about certain URIs. You may be right about mailto: but that's stretching it; the data: URI is really harmful, not just "likely useless". I won't insist on this however. - limit the types used: no data or mailto URIs; better yet have a registry of types that *can* be used - In the case of SIP URIs, what kind of contact can be made? Can this URI get a human voice, a voice mailbox, a presentity or other? Can you rephrase this question? I do not understand how the URI will determine the method, which it sounds like is the root of the question. Can you give a further example here? In theory the URI does not determine whether you'll get a human operator or a voice mailbox or a presentity; in practice, however, services often define different URIs for these things or have available specific URIs as well as generic ones. =20 The information about what the URI is likely to get you would have to be provided by the jurisdiction providing the service, along with the URI. Here's one thing I imagined might be done to address this issue: sip://switchboard.police.muenchen.de sip://deafservice.police.muenchen.de - Differentiate between contact and resource URIs? A resource URI obtains something static, a contact URI may be able to begin a conversation... This service returns contact URIs, as the abstract and Overview of Protocol usage (section 3) make clear.=20 Yes, and that's all right as far as it goes. I note that's descriptive text, not normative or even guidance text. I'd like a little discussion of the requirement that each URI scheme may appear only once. That seems to prevent some fairly common use cases like providing one number for voice mail and one number to reach an operator. The proliferation of http URIs makes this even worse -- many different kinds of services can be hosted on http URIs. The Atom link rel provides an example of how one might deal with this problem. This was discussed extensively in the working group. The aim here is to avoid the end user having to select among choices which are equivalent at the protocol level while they have an emergency. If the system returns 5 sip contact URIs, the user should not have to select among them while simultaneously beating back the flames in their car. If a jurisdiction needs to arrange failover, it should do that using a URI to a system capable of dispatch or failover (the NENA and ETSI folks have a whole set of models of how that works using Emergency Service Routing Proxies (ESRPs) ) That's an excellent goal and one I didn't think of when reading the document. Perhaps instead of annotating URIs with what kind of link they are (as in my example above), better guidance would be for jurisdictions to provide a small number of general-purpose URIs ? Can one hope to provide a single SIP URI for both voice and text, and allow the user agent to automatically bring the caller to the correct service version? 2b. IRIs Is support for IRIs explicitly not desired? As the Internationalization Considerations notes, this is primarily intended for machine-to-machine communications. The URI form of IRIs is preferred for this purpose in general, and it specifically preferred. We did include complex types for displayName and message, since those are not machine-to-machine. 2c. URI security/privacy I assume both LoST URIs (found in NAPTR) and service URIs can contain anything allowed by the URI scheme; long paths, query elements, anchor points. I can see a slight privacy issue here, because the URIs can contain tokens allowing communication from the LoST server that provided the URI to the service hosting that URI. This question is not clear to me. There are no tokens that allow communication from the LoST server; there are tokens like the "sourceId", which identifies a particular mapping? Are you concerned that the requirement that it be unique has some privacy consequence? The current text there is: The 'sourceId' attribute identifies a particular mapping and contains an opaque token that MUST be unique among all different mappings maintained by the authoritative source for that particular service. For example, a Universally Unique Identifier (UUID) is a suitable format. Do you wish to suggest additional text here? No, I thought about this one overnight and I realized that this situation is just what it is; URIs (particularly HTTP URIs) can contain all kinds of used and unused parameters and tokens, and they will be supported, and any possible fallout from that is already a concern. This document doesn't talk about preserving URIs end-to-end. What if a LoST resolver were to "helpfully" try to change URIs before passing them on to seekers? Is there some other document that covers this? The LoST resolver returns whatever was provisioned; if it changes the URIs that were provisioned, it is not behaving according to the spec. I agree that's correct, I'm not sure it's required by the spec. I may be too paranoid here. 3. Overlooked HTTP features. A number of features that are commonly overlooked when using HTTP this way are not mentioned. I like that HTTP caching is disabled but it looks like there's a cut-and-paste error in that part of the spec: The HTTP request MUST use the Cache-Control response directive "no-cache" to HTTP-level "caching even by caches that have been configured to return stale responses to client requests." You are right; sorry about the error. I suggest the following RFC Editor note: OLD The HTTP request MUST use the Cache-Control response directive "no-cache" to HTTP-level "caching even by caches that have been configured to return stale responses to client requests." NEW The HTTP request MUST use the Cache-Control response directive "no-cache" to disable HTTP-level caching even by caches that have been configured to return stale responses to client requests. For the rest I suggest adding: "LoST servers MUST handle the Expect header, conditional headers and Content-* headers on requests according to HTTP requirements (possibly by failing the request). They MUST also handle OPTIONS and HEAD and GET requests even if it's by responding with canned 200 responses. "LoST clients MUST include a Host header and MUST handle all possible HTTP response codes. "Both LoST clients and servers MUST handle chunked transfer-encoded message bodies." My personal preference is to retain the reference to 2616 and assume that the LoST server and client will use the available HTTP servers and clients as sources. My concern is that buy calling out these, the casual reader may assume that other HTTP requirements do not apply. I would be more supportive of language like "Client and server developers are reminded that full support of RFC 2616 HTTP facilities is expected. Among those commonly missed are X, Y, Z. If LoST Client or Servers re-implement HTTP, rather using available servers or client code as a base, careful attention must be paid to full interoperability". Would that work for you? That would work for me very nicely, thanks -- a definite improvement. A minor nit is that one of the reasons these are commonly overlooked is not because the software is re-implementing HTTP, but because the software uses a library or extension mechanism that encourages the service to ignore these required features because that's the default. =20 Lisa ------_=_NextPart_001_01C87520.CD020336 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
FYI

Von: ext Lisa Dusseault=20 [mailto:lisa@osafoundation.org]
Gesendet: Donnerstag, 21. = Februar=20 2008 18:58
An: Ted Hardie
Cc: iesg@ietf.org;=20 ecrit-chairs@tools.ietf.org;=20 draft-ietf-ecrit-lost@tools.ietf.org
Betreff: Re: DISCUSS:=20 draft-ietf-ecrit-lost


On Feb 20, 2008, at 2:56 PM, Ted Hardie wrote:
At 1:49 PM -0800 2/20/08, Lisa Dusseault = wrote:
Discuss:

1. Redirects

...
Would adding the following change meet the=20 need:

  =20 A LoST server can respond indicating that the querier should=20 redirect
  =20 the query to another server, using the <redirect> = element.  The
  =20 element includes a 'target' attribute indicating the LoST=20 application
  =20 unique string (see Section 4) that the client SHOULD be=20 contacting
  =20 next, as well as the 'source' attribute indicating the server=20 that
  =20 generated the redirect response and a 'message' attribute=20 explaining
  =20 the reason for the redirect response.  During a recursive query, = a
  =20 server receiving a <redirect> response can decide whether = it=20 wants to
  =20 follow the redirection or simply return the response to its=20 upstream
  =20 querier.  The = "expires"=20 value in the response returned by the server
  =20 handling the redirected query indicates the earliest time at=20 which
  =20 a new query might be needed (see section 5.2).  The same query
  =20 SHOULD NOT be directed to the server which gave redirect prior = to
  =20 that time.

Referring to the "expires" value here is most helpful.  I = forgot about=20 that attribute when I read this section.

I'm still confused about the way this is a redirect "for a specific = query".  Until I saw that phrase elsewhere in your response, I = missed the=20 specificity: I thought that the agent (isn't it a client, not = necessarily a=20 server) receiving a <redirect> response would send all queries to = the new=20 redirected server. 

The text has "the query" and "the same query" but this doesn't say = what=20 should be done about other queries.  


I'm inferring from section 14. that HTTP = redirects=20 MUST be supported by clients as well as LoST redirects.  Can that be made a = normative=20 requirement?

The document refers to RFC 2616, which = gives these as=20 SHOULD requirements in
10.3.X. =20 I do not believe it is appropriate to shift the requirement = from the=20 SHOULD
in HTTP to a MUST here.  Can you describe any = reason why this=20 should be stronger?

Fair enough.  It's been my experience (e.g. in WebDAV interop = tests)=20 that some servers fully expect all clients to handle these, and treat = these as=20 if they were a MUST, when in fact clients can choose not to follow=20 them.


2a. =20 Open-ended URI types
I'd like to see more guidance on what = URIs are=20 returned.  The risk = that the=20 LoST server will return a URI that can't be used by the seeker is a = bad risk=20 to take when it comes to emergency services.

I think we have to be careful about = this.  The base aim here is to = make sure=20 that the
contact URIs returned are those provisioned = by those=20 responsible for the jurisdiction.
We can provide advice on that, but it is = ultimately=20 up to those with the legal
responsibility to provide the records.  The working group chose to = split=20 the
advice (which is in = draft-ietf-ecrit-phonebcp) from=20 the protocol semantics exactly
because some jurisdiction may choose to use = URIs that=20 are specific to their
conditions. =20 Mailto may be reasonable in the eyes of some jurisdiction, in=20 other
words, and the protocol should not = eliminate it as a=20 possibility. 

You've definitely thought about this in the WG but a new reader of = the=20 document has to work to figure out where responsibility for being able = to=20 interconnect with the service URI might lie, and whether = interoperability=20 problems with certain URI types is likely.  Is there something = about=20 this in another document?  

A non-normative note on "Interoperability Concerns with Service = URIs" would=20 be very good here if it's not elsewhere, containing just the kind of = information=20 on how URIs are provisioned and how one might try to ensure=20 lowest-common-denominator interoperability.

The non-normative note could also mention the <serviceNumber> = element=20 and how to use it as a backup to ensure the end-user can reach the=20 service.


There's also an opportunity, not ruled out by your response, to = require=20 LoST clients to handle certain URIs.  Since SIP URIs appear in all = the=20 examples, one might require or strongly recommend LoST clients should be = able to=20 handle all types of SIP URIs.  In the long run, it would be good to = spread=20 awareness about what types of URIs are most commonly supported and used = by=20 clients.  An IANA registry may be too much for that purpose, but = there=20 ought to be something ecrit can do...

I still disagree about certain URIs.  You may be right about = mailto:=20 but that's stretching it; the data: URI is really harmful, not just = "likely=20 useless".  I won't insist on this however.




- limit the types used: no data or mailto = URIs;=20 better yet have a registry of types that *can* be used
- In the case of SIP URIs, what kind of = contact can=20 be made?  Can this = URI get a=20 human voice, a voice mailbox, a presentity or = other?

Can you rephrase this question?  I do not understand how = the URI will=20 determine
the method, which it sounds like is the = root of the=20 question.  Can you = give a
further example here?

In theory the URI does not determine whether you'll get a human = operator or=20 a voice mailbox or a presentity; in practice, however, services often = define=20 different URIs for these things or have available specific URIs as well = as=20 generic ones.  

The information about what the URI is likely to get you would have = to be=20 provided by the jurisdiction providing the service, along with the = URI.

Here's one thing I imagined might be done to address this = issue:

<uri=20 rel=3D"operator">sip://switchboard.police.muenchen.de</uri>
<uri=20 rel=3D"text">sip://deafservice.police.muenchen.de</uri>





- Differentiate between contact and = resource=20 URIs?  A resource = URI obtains=20 something static, a contact URI may be able to begin a=20 conversation...

This service returns contact URIs, as the = abstract=20 and Overview of Protocol usage
(section 3) make clear. 

Yes, and that's all right as far as it goes.  I note that's=20 descriptive text, not normative or even guidance text.


I'd like a little discussion of the = requirement=20 that each URI scheme may appear only once.  That seems to prevent = some fairly=20 common use cases like providing one number for voice mail and one = number to=20 reach an operator.  = The=20 proliferation of http URIs makes this even worse -- many different = kinds of=20 services can be hosted on http URIs. =20 The Atom link rel provides an example of how one might deal = with this=20 problem.

This was discussed extensively in the = working=20 group.  The aim here = is to avoid=20 the
end user having to select among choices = which are=20 equivalent at the protocol level
while they have an emergency.  If the system returns 5 = sip contact=20 URIs, the user
should not have to select among them while=20 simultaneously beating back the
flames in their car.  If a jurisdiction needs to = arrange=20 failover, it should do that
using a URI to a system capable of dispatch = or=20 failover (the NENA and ETSI folks
have a whole set of models of how that = works using=20 Emergency Service Routing
Proxies (ESRPs) )

That's an excellent goal and one I didn't think of when reading the = document.

Perhaps instead of annotating URIs with what kind of link they are = (as in=20 my example above), better guidance would be for jurisdictions to provide = a small=20 number of general-purpose URIs ?  Can one hope to provide a single = SIP URI=20 for both voice and text, and allow the user agent to automatically bring = the=20 caller to the correct service version?


2b. IRIs

Is support for IRIs explicitly not=20 desired?

As the Internationalization Considerations = notes,=20 this is primarily intended
for machine-to-machine communications.  The URI form of IRIs is=20 preferred
for this purpose in general, and it = specifically=20 preferred.  We did = include
complex types for displayName and message, = since=20 those are not
machine-to-machine.



2c. URI security/privacy

I assume both LoST URIs (found in NAPTR) = and=20 service URIs can contain anything allowed by the URI scheme; long = paths,=20 query elements, anchor points. I can see a slight privacy issue = here,=20 because the URIs can contain tokens allowing communication from the = LoST=20 server that provided the URI to the service hosting that=20 URI.

This question is not clear to me.  There are no tokens that = allow=20 communication from
the LoST server; there are tokens like the=20 "sourceId", which identifies a particular
mapping? =20 Are you concerned that the requirement that it be unique = has
some privacy consequence?  The current text there = is:

The 'sourceId' attribute identifies a = particular=20 mapping and contains
  =20 an opaque token that MUST be unique among all different = mappings
  =20 maintained by the authoritative source for that particular=20 service.
  =20 For example, a Universally Unique Identifier (UUID) is a = suitable
  =20 format.

Do you wish to suggest additional text=20 here?

No, I thought about this one overnight and I realized that this = situation=20 is just what it is; URIs (particularly HTTP URIs) can contain all kinds = of used=20 and unused parameters and tokens, and they will be supported, and any = possible=20 fallout from that is already a concern.


This document doesn't talk about = preserving URIs=20 end-to-end.  What if = a LoST=20 resolver were to "helpfully" try to change URIs before passing them = on to=20 seekers?  Is there = some other=20 document that covers this?

The LoST resolver returns whatever was = provisioned;=20 if it changes the URIs that
were provisioned, it is not behaving = according to the=20 spec.

I agree that's correct, I'm not sure it's required by the = spec.  I may=20 be too paranoid here.




3. =20 Overlooked HTTP features.

A number of features that are commonly = overlooked=20 when using HTTP this way are not mentioned.  I like that HTTP caching = is=20 disabled but it looks like there's a cut-and-paste error in that = part of the=20 spec:

 The=20 HTTP request MUST use the Cache-Control response
 =20 directive "no-cache" to HTTP-level "caching even by caches = that=20 have
 =20 been configured to return stale responses to client=20 requests."


You are right; sorry about the error.  I suggest the following = RFC Editor=20 note:

OLD
The HTTP request MUST use the Cache-Control = response
  =20 directive "no-cache" to HTTP-level "caching even by caches that = have
  =20 been configured to return stale responses to client = requests."

NEW

The HTTP request MUST use the Cache-Control = response
  =20 directive "no-cache" to disable HTTP-level caching even by = caches that=20 have
  =20 been configured to return stale responses to client = requests.


For the rest I suggest adding:

"LoST servers MUST handle the Expect = header,=20 conditional headers and Content-* headers on requests according to = HTTP=20 requirements (possibly by failing the request).  They MUST also handle = OPTIONS and=20 HEAD and GET requests even if it's by responding with canned 200=20 responses.

"LoST clients MUST include a Host header = and MUST=20 handle all possible HTTP response codes.

"Both LoST clients and servers MUST = handle chunked=20 transfer-encoded message bodies."

My personal preference is to retain the = reference to=20 2616 and assume that the LoST
server and client will use the available = HTTP servers=20 and clients as sources.  = My=20 concern
is that buy calling out these, the casual = reader may=20 assume that other HTTP
requirements do not apply.

I would be more supportive of language like = "Client=20 and server developers
are reminded that full support of RFC 2616 = HTTP=20 facilities is expected. =20 Among
those commonly missed are X, Y, Z.  If LoST Client or Servers=20 re-implement
HTTP, rather using available servers or = client code=20 as a base, careful attention
must be paid to full = interoperability".

Would that work for = you?

That would work for me very nicely, thanks -- a definite = improvement. =20 A minor nit is that one of the reasons these are commonly overlooked is = not=20 because the software is re-implementing HTTP, but because the software = uses a=20 library or extension mechanism that encourages the service to ignore = these=20 required features because that's the default.  

Lisa


------_=_NextPart_001_01C87520.CD020336-- --===============0116985713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit --===============0116985713==-- From ecrit-bounces@ietf.org Mon Feb 25 15:09:02 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8651028D571; Mon, 25 Feb 2008 15:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eHPQ7e0qeHN; Mon, 25 Feb 2008 15:09:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804EA28C7DC; Mon, 25 Feb 2008 14:00:13 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E7E4028C6BC; Mon, 25 Feb 2008 14:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225220001.E7E4028C6BC@core3.amsl.com> Date: Mon, 25 Feb 2008 14:00:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-04.txt Pages : 43 Date : 2008-02-25 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-phonebcp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-phonebcp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25135837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-phonebcp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25135837.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Mon Feb 25 15:09:28 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDDF28D7A4; Mon, 25 Feb 2008 15:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsITxq-9pdkY; Mon, 25 Feb 2008 15:09:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A60A28D404; Mon, 25 Feb 2008 14:15:06 -0800 (PST) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A34E728CCD1; Mon, 25 Feb 2008 14:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225221501.A34E728CCD1@core3.amsl.com> Date: Mon, 25 Feb 2008 14:15:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-05.txt Pages : 37 Date : 2008-02-25 The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-framework-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-framework-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25140709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25140709.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Tue Feb 26 03:43:33 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 669BD28C244; Tue, 26 Feb 2008 03:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wau7QfHUMmPS; Tue, 26 Feb 2008 03:43:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83E23A69AC; Tue, 26 Feb 2008 03:43:29 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793753A6C3C for ; Tue, 26 Feb 2008 03:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t9Bhs7crqHu for ; Tue, 26 Feb 2008 03:43:27 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 71E943A698D for ; Tue, 26 Feb 2008 03:43:27 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 11:43:20 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp056) with SMTP; 26 Feb 2008 12:43:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18hh3gxF30hCyb0Hv1BuipW8QqSwFJJM/zUwfhAHn /UHP5DxvufWc/Y Message-ID: <47C3FB58.3090602@gmx.net> Date: Tue, 26 Feb 2008 13:43:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] ECRIT AGENDA (Proposal) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here is the agenda proposal http://www.ietf.org/proceedings/08mar/agenda/ecrit.txt Feedback is welcome! _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 26 04:11:41 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CD728C32C; Tue, 26 Feb 2008 04:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbxUmK37uHwe; Tue, 26 Feb 2008 04:11:40 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F76A28C26B; Tue, 26 Feb 2008 04:11:40 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BB428C265 for ; Tue, 26 Feb 2008 04:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4Zy3CLcwBhU for ; Tue, 26 Feb 2008 04:11:37 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8D72328C11B for ; Tue, 26 Feb 2008 04:11:37 -0800 (PST) Received: (qmail invoked by alias); 26 Feb 2008 12:11:31 -0000 Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229]) [217.115.75.229] by mail.gmx.net (mp003) with SMTP; 26 Feb 2008 13:11:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+uzfg/rvyuybu/z1OCbCVNAr5yIKaoR8bl4Gd4AF Jb0viUYGi8YbjV Message-ID: <47C401ED.7010208@gmx.net> Date: Tue, 26 Feb 2008 14:11:25 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ECRIT X-Y-GMX-Trusted: 0 Subject: [Ecrit] Phone BCP & Framework Ready for WGLC? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org To Brian, James: Do you believe that the Phone BCP document is ready for WGLC? To Brian, James, Andy, Henning: Do you believe that the framework document is ready for WGLC? _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 26 05:39:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF11F28C466; Tue, 26 Feb 2008 05:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPJjidB7jcye; Tue, 26 Feb 2008 05:39:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7DF28C458; Tue, 26 Feb 2008 05:39:48 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970C128C458 for ; Tue, 26 Feb 2008 05:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFtZOn1eSUQg for ; Tue, 26 Feb 2008 05:39:45 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id D940E28C456 for ; Tue, 26 Feb 2008 05:39:45 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JU01v-0002QJ-Bb; Tue, 26 Feb 2008 07:39:35 -0600 From: "Brian Rosen" To: , "'ECRIT'" References: <47C401ED.7010208@gmx.net> Date: Tue, 26 Feb 2008 08:39:36 -0500 Message-ID: <13b201c8787d$08d597c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47C401ED.7010208@gmx.net> Thread-Index: Ach4cLp1UgHt99L2QXq4LTLFD9w5EAADDx6Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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: Subject: Re: [Ecrit] Phone BCP & Framework Ready for WGLC? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, I do. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, February 26, 2008 7:11 AM > To: ECRIT > Subject: [Ecrit] Phone BCP & Framework Ready for WGLC? > > To Brian, James: Do you believe that the Phone BCP document is ready for > WGLC? > > To Brian, James, Andy, Henning: Do you believe that the framework > document is ready for WGLC? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > http://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 26 10:49:24 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6082128C5FC; Tue, 26 Feb 2008 10:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzk+cd+tRaQs; Tue, 26 Feb 2008 10:49:23 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5B928C70F; Tue, 26 Feb 2008 10:49:19 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1FF3A6825 for ; Tue, 26 Feb 2008 10:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU02qfUuTn0J for ; Tue, 26 Feb 2008 10:49:15 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7DDD228C508 for ; Tue, 26 Feb 2008 10:47:31 -0800 (PST) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2008 10:47:25 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1QIlP6v016737; Tue, 26 Feb 2008 10:47:25 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id m1QIlG5w016487; Tue, 26 Feb 2008 18:47:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:47:20 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 10:47:20 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2008 12:47:19 -0600 To: "Brian Rosen" , , "'ECRIT'" From: "James M. Polk" In-Reply-To: <13b201c8787d$08d597c0$640fa8c0@cis.neustar.com> References: <47C401ED.7010208@gmx.net> <13b201c8787d$08d597c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 26 Feb 2008 18:47:20.0393 (UTC) FILETIME=[0469A390:01C878A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=815; t=1204051645; x=1204915645; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Phone=20BCP=20&=20Framework=2 0Ready=20for=20WGLC? |Sender:=20; bh=MCWvyViyvfex7pAJ+VIHJZJAXAUJCQIK0tmkHub4RQU=; b=qta99Fd5b1Cffgy/uHjlEAsh7fktg4LgUzGnVYKPAJ1zukIuqppdfQK0wh YkRxu9rAsM9bE6jxnkQT2fan12esxjWo3N5Bzjg/B/Bs+TCxCha0COBzpeJw kSpGTSRXjU; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] Phone BCP & Framework Ready for WGLC? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 07:39 AM 2/26/2008, Brian Rosen wrote: >Yes, I do. I agree > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > > Hannes Tschofenig > > Sent: Tuesday, February 26, 2008 7:11 AM > > To: ECRIT > > Subject: [Ecrit] Phone BCP & Framework Ready for WGLC? > > > > To Brian, James: Do you believe that the Phone BCP document is ready for > > WGLC? > > > > To Brian, James, Andy, Henning: Do you believe that the framework > > document is ready for WGLC? > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > http://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >http://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 26 14:39:38 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D4828C2FB; Tue, 26 Feb 2008 14:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdfcj6jMag0U; Tue, 26 Feb 2008 14:39:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5273B3A68A1; Tue, 26 Feb 2008 14:39:37 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D113A67A1; Tue, 26 Feb 2008 14:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lltfV7yu9nrn; Tue, 26 Feb 2008 14:39:34 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D1F8E3A6800; Tue, 26 Feb 2008 14:39:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,409,1199692800"; d="scan'208";a="14809139" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 26 Feb 2008 14:39:28 -0800 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 m1QMdSGK010566; Tue, 26 Feb 2008 14:39:28 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m1QMdOhp012167; Tue, 26 Feb 2008 22:39:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 14:39:24 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 14:39:23 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2008 16:39:23 -0600 To: "Roger Marshall" , "Brian Rosen" , "Dawson, Martin" , "Hannes Tschofenig" , , "ECRIT" From: "James M. Polk" In-Reply-To: <8C837214C95C864C9F34F3635C2A657509178A13@SEA-EXCHVS-2.tele comsys.com> References: <47A186C1.7080004@gmx.net> <005b01c8642a$1bd4bcf0$640fa8c0@cis.neustar.com> <015401c864d6$4ca4d930$640fa8c0@cis.neustar.com> <04b501c86735$b51f3cb0$640fa8c0@cis.neustar.com> <8C837214C95C864C9F34F3635C2A657509178A13@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 26 Feb 2008 22:39:23.0749 (UTC) FILETIME=[6F612950:01C878C8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=609; t=1204065568; x=1204929568; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20[Speermint]=20=20Emergency=20 Calls=20&=20VoIP=20Peering |Sender:=20; bh=i7FKsmi3ZmrEeMkJTOxyulBtDkn8NRbMRn2gcPKQ5ss=; b=FJdY6hS2stbrDrw6372u/i7rKBlpzdns4ysYyJ3Xdo8qEnl0H3vKPpo+S9 DEmewrvagJlOVWFhY3TmwVYRUviij0UNwCFjhAaZeB4WURQsueX2GwFIyL7m cpf8XNlfpHw+dmwNWftlE+x+4MPBQwJ/z9QO+bPCcI7p+lu82iQnU=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] [Speermint] Emergency Calls & VoIP Peering X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 06:29 PM 2/4/2008, Roger Marshall wrote: >built in capabilities could be shown as: > >base_reference_client: >-- includes Location, (either in PIDF-LO or Location URI form), and >-- dial string analysis >-- SIP INVITE Problem: If the client includes location, it does so with the below client's geolocation header >routing_reference_client: >-- does LoST discovery >-- does LoST lookups >-- adds Geolocation header >-- utilizes PSAP URIs >-- places Service URNs > >This offers a way to abstract the application (e.g., VoIP client), which >is going to otherwise be hard to control. _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Feb 26 15:09:24 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BED28C881; Tue, 26 Feb 2008 15:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyI1kpcGeh1T; Tue, 26 Feb 2008 15:09:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484B328C843; Tue, 26 Feb 2008 15:09:12 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880E728C547 for ; Tue, 26 Feb 2008 15:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfsp+Sv7VjPk for ; Tue, 26 Feb 2008 15:09:09 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 876A328C832 for ; Tue, 26 Feb 2008 15:08:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,409,1199692800"; d="scan'208";a="7238916" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2008 15:08:43 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id m1QN8hN4022176; Tue, 26 Feb 2008 15:08:43 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1QN8hDP019254; Tue, 26 Feb 2008 23:08:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 15:08:43 -0800 Received: from jmpolk-wxp.cisco.com ([171.70.229.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Feb 2008 15:08:42 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2008 17:08:41 -0600 To: Hannes.Tschofenig@gmx.net, ECRIT From: "James M. Polk" In-Reply-To: <47C3FB58.3090602@gmx.net> References: <47C3FB58.3090602@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 26 Feb 2008 23:08:42.0627 (UTC) FILETIME=[87C0A530:01C878CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=571; t=1204067323; x=1204931323; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=20AGENDA=20(Proposal) |Sender:=20; bh=QxmUBa+lFO6kuQQidcYqx/6XTbNWwxM/5seCNvkikUk=; b=MLVPuBMmPCkj3RGxHuQZw6QTwuD+MGLQJ9PPFAFmcQg8zxp+EloCysEEAe 2eGpW9TV2nOY14rC22D5XrgSS2mzhI6btGWgSNdGlD0prmlqQIDMHTPVa764 LkmmLFjdIe; Authentication-Results: sj-dkim-7; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); Cc: Robert Sparks Subject: Re: [Ecrit] ECRIT AGENDA (Proposal) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 05:43 AM 2/26/2008, Hannes Tschofenig wrote: >Here is the agenda proposal >http://www.ietf.org/proceedings/08mar/agenda/ecrit.txt " -- Interim meeting together with GEOPRIV along with the ESW 2008? " Given the ESW is Tuesday (April 22) - Thurs (April 24), when do you expect to have the time for two WGs to discuss their respective IDs? If forced in, doesn't this make for a very long week? >Feedback is welcome! > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >http://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org http://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Feb 29 13:15:28 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D7628C8E6; Fri, 29 Feb 2008 13:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.293 X-Spam-Level: ** X-Spam-Status: No, score=2.293 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_BACKHAIR_24=1, J_BACKHAIR_44=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLFiGJgR0OSA; Fri, 29 Feb 2008 13:15:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FDF28C8EC; Fri, 29 Feb 2008 13:15:20 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025EE28C8D0 for ; Fri, 29 Feb 2008 13:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAi6CHSmgsci for ; Fri, 29 Feb 2008 13:15:17 -0800 (PST) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by core3.amsl.com (Postfix) with ESMTP id 9542128C714 for ; Fri, 29 Feb 2008 13:15:14 -0800 (PST) Received: by rv-out-0910.google.com with SMTP id l15so2456378rvb.49 for ; Fri, 29 Feb 2008 13:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=9c5Chf5xWAcCky9ZY3h+h6H4CkKdPgCyHSEblAlkofM=; b=ngkJ+2rHHrOqWYRuMGw3kjTuOw4LC9w1Cupx2CC8GZIfkCbScI+CqH82jnrTCAsxubRBJP1v9fk/mnQMRO01gGZeEbGgy43vsaUBupUxkM3SeIXD3evipwmW4aZNbdcG/UlJy3Y9ZVmrUE7R8ifE69NSEfrEk/baih/rJLP46qA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=VaZMQXO2kkyTeX6BLKcEFZS5/+jp8YZh6jtDbiDw+k6o3qse+YNUdDE9rOwqJqE0IV/1h3UJKooVYwHlP+rTNKW2Ely5x1fo2yKWu9gwLx88ZTbndnLUZtZSdwez0/qEY/AubGZCjSPHh6pUcce7LwLFU3N0njjfptnAeZ7aqDw= Received: by 10.140.141.15 with SMTP id o15mr6746850rvd.2.1204319706848; Fri, 29 Feb 2008 13:15:06 -0800 (PST) Received: by 10.140.208.7 with HTTP; Fri, 29 Feb 2008 13:15:06 -0800 (PST) Message-ID: <91d266200802291315m33ce8f7brd4c51814959f1c7b@mail.gmail.com> Date: Fri, 29 Feb 2008 16:15:06 -0500 From: "NC Reddy" To: ecrit@ietf.org MIME-Version: 1.0 Cc: Sip-implementors@lists.cs.columbia.edu Subject: [Ecrit] Query: How to derive Emergency Call from SIP INVITE Message X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1287464020==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --===============1287464020== Content-Type: multipart/alternative; boundary="----=_Part_10855_2593587.1204319706858" ------=_Part_10855_2593587.1204319706858 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have the following queries regarding emergency call interpretation at SIP Application Server (SIP-AS). scenario: ======== AP- Access Point AS - SIP Application server MGCF - Media Gateway Control Function (Softswitch ) PSAP - *Public Safety Answering Point *AP<----SIP--->AS<---SIP----->MGCF<----Non-SIP---->PSAP Use case1 : When subscriber(AP) makes emergency call to PSAP (AP ------->PSAP) Use case2 : When PSAP callbacks to subscriber. (PSAP ------->AP) Now Questions related the mechanisms for analyzing the emergency calls at SIP Application Server. By considering the cases of emergency call numbers are different in different countries and context. Option 1: SIP-AS can do the digit analysis from request uri of the userpart (ex: 911) and figureout the call as emeregncy and handle the call. Option 2 : If the AP/MGCF done the digit analysis and add the "priority : emergency" header, SIP-AS can rely on that header and route the call. So which option is suitable in context of SIP-AS implementation for emeregency calls. Thanks in advance. Regards Channa ------=_Part_10855_2593587.1204319706858 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
    I have the following queries regarding emergency call interpretation at SIP Application Server (SIP-AS).

scenario:
========
AP-  Access Point
AS - SIP Application server
MGCF - Media Gateway Control Function (Softswitch )
PSAP -  Public Safety Answering Point

AP<----SIP--->AS<---SIP----->MGCF<----Non-SIP---->PSAP

Use case1 : When subscriber(AP) makes emergency call to PSAP (AP  ------->PSAP)
Use case2 : When PSAP callbacks to subscriber.  (PSAP ------->AP)

Now Questions related the mechanisms for analyzing the emergency calls at SIP Application Server. By considering the cases of emergency call numbers are different in different countries and context.

Option 1:  SIP-AS can do the digit analysis from request uri of the userpart (ex: 911) and figureout the call as emeregncy and handle the call.
Option 2 :  If the AP/MGCF done the digit analysis and add the "priority : emergency" header, SIP-AS can rely on that header and route the call.

So which option is suitable in context of SIP-AS implementation for emeregency calls.


Thanks in advance.

Regards
Channa


------=_Part_10855_2593587.1204319706858-- --===============1287464020== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1287464020==-- From ecrit-bounces@ietf.org Fri Feb 29 13:44:48 2008 Return-Path: X-Original-To: ietfarch-ecrit-archive@core3.amsl.com Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6C728C810; Fri, 29 Feb 2008 13:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[AWL=-1.894, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_22=1, J_BACKHAIR_24=1, J_BACKHAIR_44=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyTmpW15hYS0; Fri, 29 Feb 2008 13:44:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B233A6E45; Fri, 29 Feb 2008 13:44:44 -0800 (PST) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57CF3A6E45 for ; Fri, 29 Feb 2008 13:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU0rZ7hOcWxO for ; Fri, 29 Feb 2008 13:44:38 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 6AF813A6E84 for ; Fri, 29 Feb 2008 13:44:38 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JVD1k-0007Fk-4V; Fri, 29 Feb 2008 15:44:24 -0600 From: "Brian Rosen" To: "'NC Reddy'" , References: <91d266200802291315m33ce8f7brd4c51814959f1c7b@mail.gmail.com> Date: Fri, 29 Feb 2008 16:44:27 -0500 Message-ID: <024e01c87b1c$43c00ea0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach7GHRCZxxcwit0TmiArpYceAwdsgAAm3yw In-Reply-To: <91d266200802291315m33ce8f7brd4c51814959f1c7b@mail.gmail.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: Cc: Sip-implementors@lists.cs.columbia.edu Subject: Re: [Ecrit] Query: How to derive Emergency Call from SIP INVITE Message X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Generally, the IETF has not spent a lot of time on the specifics of how a PSAP without an IP connection handles a call that originated in an IP network. So, the IETF documents would just treat the =93MGCF=94 in your di= agram as the PSAP, and whatever it does to get to the PSTN connected PSAP is up to it. = The ecrit LoST protocol describes how the AP learns the dialing sequence for its location. We have another document that describes how emergency calls are marked (=91urn:service:sos where there is a single emergency number). LoST also describes how calls should route to the proper PSAP. = So if the AP does digit analysis, it would obtain the dialing string(s) to look for from LoST. Once it found one, it would signal with the service URN (in the R-URI) and the PSAP URI obtained from LoST in a Route header. It is difficult for the AS (or MGCF) to do the digit analysis, because it would need to know the location of the AP to determine what to look for. If the network forces the AS to be in a =93visited=94 network, that may not be= so hard, but few networks can guarantee that will always be the case. That is why the IETF recommends the AP do the digit analysis and provides the LoST dial =93Service number=94 mechanism. Brian ________________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of NC Reddy Sent: Friday, February 29, 2008 4:15 PM To: ecrit@ietf.org Cc: Sip-implementors@lists.cs.columbia.edu Subject: [Ecrit] Query: How to derive Emergency Call from SIP INVITE Message Hi, =A0=A0=A0 I have the following queries regarding emergency call interpretat= ion at SIP Application Server (SIP-AS). scenario: =3D=3D=3D=3D=3D=3D=3D=3D AP-=A0 Access Point AS - SIP Application server MGCF - Media Gateway Control Function (Softswitch ) PSAP -=A0 Public Safety Answering Point AP<----SIP--->AS<---SIP----->MGCF<----Non-SIP---->PSAP Use case1 : When subscriber(AP) makes emergency call to PSAP (AP=A0 ------->PSAP) Use case2 : When PSAP callbacks to subscriber.=A0 (PSAP ------->AP) Now Questions related the mechanisms for analyzing the emergency calls at SIP Application Server. By considering the cases of emergency call numbers are different in different countries and context. Option 1:=A0 SIP-AS can do the digit analysis from request uri of the userp= art (ex: 911) and figureout the call as emeregncy and handle the call. Option 2 :=A0 If the AP/MGCF done the digit analysis and add the "priority : emergency" header, SIP-AS can rely on that header and route the call. So which option is suitable in context of SIP-AS implementation for emeregency calls. Thanks in advance. Regards Channa _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit