[eppext] VAT / National identifier (Was: [IANA #826994] Registration request for EPP extension)

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Tue, 16 June 2015 08:01 UTC

Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11191B3379 for <eppext@ietfa.amsl.com>; Tue, 16 Jun 2015 01:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.741
X-Spam-Level:
X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Tf3ktuKM6nbd for <eppext@ietfa.amsl.com>; Tue, 16 Jun 2015 01:01:16 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8751B336F for <eppext@ietf.org>; Tue, 16 Jun 2015 01:01:16 -0700 (PDT)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Tue, 16 Jun 2015 10:01:14 +0200
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Tue, 16 Jun 2015 10:01:13 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: Patrick Mevzek <pm@dotandco.com>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: VAT / National identifier (Was: [eppext] [IANA #826994] Registration request for EPP extension)
Thread-Index: AdCoCaUdX18KMUMjSZWCX6eBuE5QNg==
Date: Tue, 16 Jun 2015 08:01:11 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE07546832006@NICS-EXCH2.sbg.nic.at>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.163]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/ECi5BaGF8cPKRZwLpaauBU0tSjQ>
Subject: [eppext] VAT / National identifier (Was: [IANA #826994] Registration request for EPP extension)
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 08:01:18 -0000

> Von: EppExt [mailto:eppext-bounces@ietf.org] Im Auftrag von Patrick
> Mevzek
> Based on the (mostly ccTLDs) EPP extensions I have seen working with
> this kind of data, I was planning to write after the Stockholm EPP
> workshop an extension to handle that,
> and then starting the hard part on seeing how it could get implemented
> by registries…

As i mentioned during the Stockholm meeting, i think the "proper" approach to all those "external identifier" problems could be an extension that allows for association of:

  - identifier "type"
  - identifier "value" 

For registry objects. For identifiers which have already an URN namespace, the "value" could then be an URN (in which case the "space" descriptor would probably not be needed). An example could be

<referenceID type="vat:at">ATU2423424324</referenceID>

or

<referenceID type="ssn:fi">PERSON34534XTZ</referenceID>

We would then, though, probably need a "meta-registry" with to register all the possible "types" and definitions for those. 

> I have not started that work yet, and if anyone has ideas and/or want
> to help write the I-D, he/she is welcome.

A first step could be to collect the various use cases of external identifiers used in registries. I think a large a-z Registrar would be the prime candidate for providing most of the information, because they typically have the best  "market overview".

Though, as always, there's the tradeoff between flexibility and ambiguity when starting to define a "key / value" type extension...

Alex