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

First of all, +1 on the extension!

Alex, I would be concerned that your method would create too much 
flexibility which would defeat the purpose of the extension as the 
registry & registrar would still need to customise in order to 
implement. I would think it better to create a defined extension that 
would cover "everything", and all unused fields get ignored by server. 
So the registrar would collect all of (or as much of) the information 
from the registrant as normal even if it is not required for a 
particular TLD, but the same contact details would be used later for the 
next TLD the registrant registers in. A registrar would therefore not 
need to add/change their system to integrate with a new registry (or 
perhaps just ticking required fields list).

..... server MUST ignore unused fields; in the case the registry doesn't 
care about trading_name & trademark so the server ignores them. A rough 
example of what's in my head.

<contactext:org>
   <contactext:type>limited</contactext:type>
   <contactext:vat_no>AT123123123</contactext:vat_no>
   <contactext:org_no>ABC11231</contactext:org_no>
   <contactext:trading_name>123 Org</contactext:trading_name>
   <contactext:trademark>BNX1234123<contactext:trademark>
</contactext:org>

Open to suggestion though. In the mean time, to start a list of fields - 
all of the below are required by a registry somewhere. There are a few 
very unique cases that I have omitted.

Contact Type [registrant, admin, tech, bill, onsite, zone, ...], Language, Mobile Number, Secondary Email, URL, SIP, Remarks
Organisation Type [person, company]
--Company-- Type [LTD,PLC,NGO...], Organisation/Company Number, VAT Number, Trading Name, Trademark [do we want to go down this road :)?]
--Person-- Nationality, Identification Type [passport, id, ...], Identification Number, Birth Date, Birth Place

Cheers,
*Michael Holloway
Senior Systems Administrator**| Com Laude*
E: michael.holloway@comlaude.com <mailto:michael.holloway@comlaude.com>

On 16.06.2015 10:01, Alexander Mayrhofer wrote:
>> 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
>
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext