PP6: LoST, location based routing, and application Infrastructure.
Lisa Dusseault <firstname.lastname@example.org> Fri, 18 January 2008 18:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwQL-000764-BQ; Fri, 18 Jan 2008 13:58:41 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1JFwQK-00075x-7A for email@example.com; Fri, 18 Jan 2008 13:58:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwQJ-00075p-Tk for firstname.lastname@example.org; Fri, 18 Jan 2008 13:58:39 -0500
Received: from laweleka.osafoundation.org ([18.104.22.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFwQH-0001dp-I6 for email@example.com; Fri, 18 Jan 2008 13:58:39 -0500
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 59711142201 for <firstname.lastname@example.org>; Fri, 18 Jan 2008 10:58:39 -0800 (PST)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAGTUDuIG5AD for <email@example.com>; Fri, 18 Jan 2008 10:58:32 -0800 (PST)
Received: from [192.168.1.101] (unknown [22.214.171.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B5EB2142274 for <firstname.lastname@example.org>; Fri, 18 Jan 2008 10:58:32 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Apps Discuss <email@example.com>
From: Lisa Dusseault <firstname.lastname@example.org>
Subject: PP6: LoST, location based routing, and application Infrastructure.
Date: Fri, 18 Jan 2008 10:58:28 -0800
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: -4.0 (----)
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:firstname.lastname@example.org?subject=subscribe>
LoST, location based routing, and application Infrastructure. Ted Hardie Work done in the ECRIT working group to support location-based routing of emergency calls has resulted in LoST (A Location to Service Translation protocol). The current draft, draft-ietf-ecrit-lost, will be revised in the next few weeks to handle Last Call comments, and then submitted to the IESG. Assuming there is no major architectural issues raised, it will become part of the toolkit available for applications. This position paper discusses who might use it and why. Basic LoST protocol transactions start with a location expressed in XML (using either a civic or geolocation profile) and a service URN; one or more contact URIs is returned along with the boundaries for which that contact URI is valid, if that information is available. The protocol also supports getting the service boundaries as a direct query, as well as a request to list the services supported. LoST servers are identified using U-NAPTR, and there is a mechanism for tree traversal and referral for finding the server authoritative for a particular location, service tuple. The infrastructure deployment needed for a new LoST service currently involves registering an appropriate service URN, deploying the servers which map locations to specific URIs, and making clients aware of the service. While clients can discover supported services using the listService command, this carries no direct information about the nature of the service, so some out-of-band information channel is needed to explain the value of any new service. It also requires that the service be delivered in a way that has location-specific catchment areas. Delivery of emergency services has this because of a mapping of PSAPs (public safety access points) and emergency responders to specific areas by public safety officials. Some other industries have delineated areas which are associated with specific providers. In the U.S., for example, Major League Baseball has delineated areas which are associated with specific teams; while anyone can be a fan of any team from anywhere, there are rules which relate to specific territories and a default team for that territory. In most cases, though, this is not done through industry-scale cooperative agreements; a particular provider may divide up the territory associated with their stores, but the same division is unlikely to hold for other providers, absent regulation. So Pizza Igloo and Pizza Lean-to are both likely to divide up their territories, but the division will likely not match. Taxi services, on the other hand, might match because of licensing regulations, but this is likely due to the aggregation of specific local licenses rather than an industry-wide delineation or large catchment-area assignment. There are three main branches of deployment, in other words. The first is for services where catchment areas have been assigned by jurisdiction, as PSAPs are assigned. Identifying the post office responsible for mail delivery to a specific address, for example, would be jurisdictionally determined. The second is for services delivered by specific branches of a single provider. These might be physical services (the Pizza Lean-to which will deliver to an address) or online services (World of Statecraft might offer to associate new players with political parties forming in their local areas in order to foster team creation, even though the team's efforts in WoS would not be locally bound). The third is deployment using aggregators who determine what services from various providers are available in specific areas and make that available; such an aggregator might get the service areas for Pizza Lean-to, Pizza Igloo, and Pizza Yurt, then provide any salient contact URIs when a lookup for pizza services occurs. An architectural problem which arises with each of these three models sharing a protocol is a strong possibility of namespace partition at the URN level. For the jurisdictional services like sos or postal, it is easy to see how to resolve what the service names should be and how registration can proceed. But should it be urn:service:pizza or urn:service:food.delivery.pizza? Should individual providers' lost services be urn:service:Pizza- Leanto.delivery or urn:service:food.delivery.Pizza-Leanto? Having IANA organize this set of namespaces for all services which might be delivered anywhere seems like a non-starter. Having a small set of widely agreed services registered under urn:service seems possible, but IANA doesn't have the time, attention, or expertise to act as Linnaeus to the service world. That, in turn, tends to imply that there will be multiple trees, each run by a different organization, if LoST becomes common; the other option, of course, is that LoST stays in the jurisdictional space and other mechanisms become popular for the other two. Practically speaking, the tuple of location and any service- identifying URI is sufficient once an appropriate LoST server has been found, so the problem devolves to one of configuration/ discovery. That problem, though, could hit us hard in retaining user control. Current location-based service delivery mechanisms have a strong flavor of provider lock-in, especially on the ISP side; moving to LoST could move to a more fully independent LBS industry, but that will not work if the only LoST server discovery mechanisms rely on ISP deployments to maintain. Further work on discovery, in other words, may be needed to maintain end-user independence of operator control.
- PP6: LoST, location based routing, and applicatio… Lisa Dusseault