[art] Registering the 'LoST-Validation' NAPTR Service Tag
"Randall Gellens" <rg+ietf@randy.pensive.org> Sat, 18 January 2020 20:05 UTC
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28B0120019 for <art@ietfa.amsl.com>; Sat, 18 Jan 2020 12:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.597
X-Spam-Level: *
X-Spam-Status: No, score=1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_RELAY_MUA_TO_MX=3.498, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmi-F9_XlLv3 for <art@ietfa.amsl.com>; Sat, 18 Jan 2020 12:05:29 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A381B120043 for <art@ietf.org>; Sat, 18 Jan 2020 12:05:29 -0800 (PST)
Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 18 Jan 2020 12:05:29 -0800
From: Randall Gellens <rg+ietf@randy.pensive.org>
To: art@ietf.org
Cc: Brian Rosen <br@brianrosen.net>
Date: Sat, 18 Jan 2020 12:05:28 -0800
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <26C2AFDA-6CC1-4345-9978-1E2392750F94@randy.pensive.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; markup="markdown"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/Ws7PKkXncPPCYpOVD9mI8PjcLvU>
Subject: [art] Registering the 'LoST-Validation' NAPTR Service Tag
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jan 2020 20:05:31 -0000
Working in NENA, we've identified a need to register a new S-NAPTR service tag 'LoST-Validation'. Background: as some may recall, the key motivator for LoST was emergency services, primarily the ability to lookup a service URN for a location (i.e., map "URN:SERVICE:SOS" to a SIP URI for a PSAP for a specific location), and secondarily the ability to validate a civic location (i.e., validate that a civic address is unique, dispatchable, and meets the requirements for the area). LoST provides the ability to do both. NENA i3 (which defines NG9-1-1) makes extensive use of LoST. One thing NENA i3 does that was not originally contemplated when LoST was developed is to allow separation of the core mapping function of LoST from the validation function. NENA i3 allows (but does not require) these two services to be provided separately (with the motivation that mapping is a time-crucial service done during emergency call setup, while validation is performed as data is provisioned into entities and is not time-crucial, so a provider might potentially provision and operate these two services differently). LoST uses U-NAPTR Application Unique Strings rather than URIs to refer to other LoST servers. There is currently one U-NAPTR service tag for LoST ("LoST"). In order to be able to separate service mapping from location validation, a second service tag is needed. Otherwise an entity can't tell from an Application Unique String which service is available and can't resolve an Application Unique String into a URI for a LoST server that assuredly is willing to perform location validation. We therefore propose to define "LoST-Validation" as a service tag. This will allow an entity to locate a LoST server willing to perform civic location validation, leaving "LoST" as the service tag for core service mapping. (Of course, a LoST server located using the 'LoST' service tag might offer both mapping and validation, but the ability to use 'LoST-Validation' in NAPTR records makes explicit which LoST servers are willing to do validation.) The Service Tags registry rules that require an RFC to add a tag, so I have submitted a small RFC to do this: https://www.ietf.org/internet-drafts/draft-gellens-lost-validation-00.txt Comments, feedback, etc. are appreciated. --Randall
- [art] Registering the 'LoST-Validation' NAPTR Ser… Randall Gellens
- Re: [art] Registering the 'LoST-Validation' NAPTR… Ted Hardie
- Re: [art] Registering the 'LoST-Validation' NAPTR… Randall Gellens