Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels)

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 19 March 2013 19:27 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C51721F8FE3 for <ecrit@ietfa.amsl.com>; Tue, 19 Mar 2013 12:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+CKO8jUjRYs for <ecrit@ietfa.amsl.com>; Tue, 19 Mar 2013 12:27:24 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4345521F8FDD for <ecrit@ietf.org>; Tue, 19 Mar 2013 12:27:23 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2JJRMG2013939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2013 14:27:22 -0500 (CDT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r2JJRLDs017856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 15:27:22 -0400
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 19 Mar 2013 15:27:21 -0400
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 19 Mar 2013 20:27:18 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Martin Thomson <martin.thomson@gmail.com>, "Rosen, Brian" <Brian.Rosen@neustar.biz>
Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels)
Thread-Index: AQHOJMMH2o3AEBawjEWvWcnSLNjkW5itZMDQ
Date: Tue, 19 Mar 2013 19:27:17 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <CD6E08DB.3F093%mlinsner@cisco.com> <B321B1C2-086E-441B-B7C5-D0130587B851@neustar.biz> <CABkgnnVkgE8d=iKz2PY4tGaZxvHFoauPP53rM0zTyrB3Ef70vA@mail.gmail.com>
In-Reply-To: <CABkgnnVkgE8d=iKz2PY4tGaZxvHFoauPP53rM0zTyrB3Ef70vA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2013 19:27:25 -0000

Martin Thomson wrote:

> I agree with Brian, "local" is not just ambiguous, it's redundant.
> "urn:service:sos.police.local" is semantically equivalent to
> "urn:service:sos.police".
>

I disagree with the last part of this. It is only semantically equivalent if the PSAP assigned to handle .local calls is the same as the one assigned to handle .police. It could equally be that .police and .national are handed by the same PSAP, or there could be three sets of PSAPs. So it depends on how the PSAPs are arranged and supported in any particular administration.

I'd also stress that we are setting this up to cover real need examples. Therefore if a country doesn't currently have a PSAP handling of emergency calls at these levels, it should advertise .police and handle the subtypes as .police.

I personally would like these subtypes to be reasonably meaningful, i.e. English words rather than codes.

Keith



> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
> Martin Thomson
> Sent: 19 March 2013 16:58
> To: Rosen, Brian
> Cc: ecrit@ietf.org
> Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-
> serviceid-labels)
> 
> I agree with Brian, "local" is not just ambiguous, it's redundant.
> "urn:service:sos.police.local" is semantically equivalent to
> "urn:service:sos.police".
> 
> Regarding "national" and "country", there's a subtlety that might be
> relevant.  To my mind, "country" is a location-based designation,
> whereas "national" implies an ownership-based distinction.  This might
> be a peculiarity of Australian English.  To give a concrete example,
> local councils in Australia are often given money under a "national
> black-spot programme" to repair problem sections of local roadways -
> the effect is local (i.e., A3-ish), but the designation is "national"
> due to the nature of the sponsor.  I prefer the location-based label
> for that reason.
> 
> On 19 March 2013 09:46, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
> > Yes
> >
> > In my opinion, urn:service:sos.police.national should be registered,
> although I would prefer the term "country" for reasons detailed below.
> >
> > I do not believe urn:service:sos.police.local should be registered,
> because the term "local" is ambiguous in many countries and regions.  In
> some areas, there are multiple levels of "local" that may have separate
> service URLs.  For example, you could have state, county and municipal
> police agencies, any of which could be considered "local".
> >
> > While an expert does not usually supply alternatives, I think the ecrit
> work group has considered the suggestion to use the "A" levels in PIDF-LO
> to denote the levels of "local".  So, for example,
> urn:service:sos.police.a2 would be the county police, assuming A1 was
> state, A2 was county and A3 was city.  One could speculate whether
> urn:service:sos.police.a6 (neighborhood) was useful for anything, but
> there are "neighborhood watch" organizations that might qualify, and
> "vigilante" is probably not a good registration.
> >
> > Using the "A" levels leads you to use "country" as that is the top level
> name for the field in PIDF-LO.  "national" is an obvious synonym, and I
> think it's okay to use it.
> >
> > However, "local" is ambiguous.
> >
> > Brian
> >
> > On Mar 19, 2013, at 12:32 PM, Marc Linsner <mlinsner@cisco.com>
> >  wrote:
> >
> >> Brian,
> >>
> >> Would you please provide a review of this IANA request for
> registrations.
> >>
> >> Thanks,
> >>
> >> Marc & Roger
> >>
> >> -----Original Message-----
> >> From: Amanda Baber via RT <iana-prot-param-comment@iana.org>
> >> Reply-To: <iana-prot-param-comment@iana.org>
> >> Date: Friday, February 15, 2013 6:34 PM
> >> Cc: <ecrit-chairs@tools.ietf.org>
> >> Subject: [IANA #658921] General Request for Assignment
> >> (urn-serviceid-labels)
> >> Resent-From: <wg-alias-bounces@tools.ietf.org>
> >> Resent-To: <rmarshall@telecomsys.com>, <marc.linsner@cisco.com>
> >> Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000
> >>
> >>> Dear Marc and Roger,
> >>>
> >>> IANA just received a request for two registrations in the 'sos'
> >>> Sub-Services registry at
> >>> http://www.iana.org/assignments/urn-serviceid-labels, which has the
> ECRIT
> >>> working group listed as its expert reviewer.
> >>>
> >>> Can you ask the working group to review the request below? If these
> are
> >>> OK, how should we fill out the Description fields in the registry?
> >>>
> >>> thanks,
> >>>
> >>> Amanda Baber
> >>> IANA Request Specialist
> >>> ICANN
> >>>
> >>> ===
> >>>
> >>> Contact Name:
> >>> Ivo Sedlacek
> >>>
> >>> Contact Email:
> >>> ivo.sedlacek@ericsson.com
> >>>
> >>> Type of Assignment:
> >>> Assignment of an service URN with the 'sos' service type as specified
> in
> >>> RFC5031, section 4.2.
> >>>
> >>> The following service URNs are proposed to be registered:
> >>> - urn:service:sos.police.local - The 'police.local' service refers to
> the
> >>> emergency service offered by the police department or other law
> >>> enforcement authorities of the local or municipal authorities.
> >>> - urn:service:sos.police.national - The 'police.national' service
> refers
> >>> to the emergency service offered by the police department or other law
> >>> enforcement authorities of the national government.
> >>>
> >>> Registry:
> >>> Service URN Labels, 'sos' Sub-Services as shown at
> >>> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-
> labels.
> >>> xml
> >>>
> >>> Description:
> >>> In the Czech republic and Poland, there are two public safety
> answering
> >>> points (PSAP) offering the police related emergency services. The PSAP
> of
> >>> the municipal police and the PSAP of the national police. There is
> >>> currently no way how to distinguish whether the user wishes to contact
> >>> the PSAP of the municipal police or the PSAP of the national police.
> >>>
> >>> In Czech, the related regulation is
> >>> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=c&id=5134
> pages
> >>> 9 and 10 section 4.5 which lists the number 156 for "Obecní policie"
> (=
> >>> municipal police) and the numbers 158 for "Policie České republiky" (=
> >>> Czech republic police). Both numbers are listed with note 2) which
> states
> >>> "Číslo je národním číslem pro tísňové volání" (= the number is a
> national
> >>> number for emergency calls).
> >>>
> >>> In Poland,
> >>> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 lists
> >>> the number 986 for "straż miejska" (= municipal police) and the number
> >>> 997 for Policja (= police) as "numery alarmowe" (= emergency numbers).
> >>>
> >>> Additional Info:
> >>> The registry is defined by RFC5031, section 4.2
> >>
> >>
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit