Re: [eppext] EPP Extension Registration Requests from DK-Hostmaster

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 09 September 2015 11:20 UTC

Return-Path: <shollenbeck@verisign.com>
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 5F4961B2B7D for <eppext@ietfa.amsl.com>; Wed, 9 Sep 2015 04:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 pma0Njo0w9pr for <eppext@ietfa.amsl.com>; Wed, 9 Sep 2015 04:20:15 -0700 (PDT)
Received: from mail-oi0-f98.google.com (mail-oi0-f98.google.com [209.85.218.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02951B2D49 for <eppext@ietf.org>; Wed, 9 Sep 2015 04:20:14 -0700 (PDT)
Received: by oixx17 with SMTP id x17so279441oix.2 for <eppext@ietf.org>; Wed, 09 Sep 2015 04:20:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=qZgohEyLVoWaHlAe1fIiWYtOJjhYf5YFe6iee8r8pW8=; b=LHWD51L9p6LW6SpR6aazdRtgP0GlqY9L2uYseBwvRKPowprwx41hKdNWm4saF18Xd6 ODTFUFMJnB45DSMQIw3aLIzfplFRYwx8U6AyOREu5Oi+knFQXcUIv6Q/ugkYKCx5TH2W Lbk/rsK5m0tGQY55Xqx8eqoNoMvPdg2SDrPW5R7QxZQcPh0pLP5CiP7j5kc0o1KfoUxC s03x2bmmkndfWFNmW5hgYv3C2FxRE4m44P3ZzRX6tFjxyipauFpxffYEduAyojt9YhJ8 +qVFlQxwowMSSBDsb1y8DkVTmyPXmp9dA6KR98km7vWxwlTT0MPhsmDxNvd7Zn15Lq5F 34hQ==
X-Gm-Message-State: ALoCoQn8ZRxo59mP+Vut04inSkk7rW0ce0p3hOddGUuDMr/2cKz1e77p1GE4QMfrHZ70KdkFVYkK646IIbMAHy+EbpkiNobe2g==
X-Received: by 10.140.92.54 with SMTP id a51mr31941883qge.105.1441797614230; Wed, 09 Sep 2015 04:20:14 -0700 (PDT)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id b67sm580458qka.7.2015.09.09.04.20.14 for <eppext@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Sep 2015 04:20:14 -0700 (PDT)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t89BKDJO005622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <eppext@ietf.org>; Wed, 9 Sep 2015 07:20:13 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 9 Sep 2015 07:20:13 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: EPP Extension Registration Requests from DK-Hostmaster
Thread-Index: AdDq7urJYTp6HZLPTQ+N25QbSe00ZQAAJM1w
Date: Wed, 9 Sep 2015 11:20:12 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A07F88E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <831693C2CDA2E849A7D7A712B24E257F4A07F79A@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A07F79A@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/MlxXfGMhXFRUBh716PRf9jYpdto>
Subject: Re: [eppext] EPP Extension Registration Requests from DK-Hostmaster
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 09 Sep 2015 11:20:17 -0000

> -----Original Message-----
> From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Hollenbeck,
> Scott
> Sent: Wednesday, September 09, 2015 7:02 AM
> To: eppext@ietf.org
> Subject: [eppext] EPP Extension Registration Requests from DK-
> Hostmaster
> 
> Yesterday I received 10 requests from IANA to review EPP extensions
> submitted by DK-Hostmaster. I'll forward each of them to this list
> momentarily. I've reviewed all of them and I'm going to suggest that
> they be considered as one request since each describes an element that
> is part of the same schema and the same specification.

More detail:

The specification for each of the registration requests can be found here:

https://github.com/DK-Hostmaster/epp-service-specification

The current version of the schema can be found here:

https://github.com/DK-Hostmaster/epp-xsd-files/blob/master/dkhm-1.4.xsd

Each of the registration requests refers to an element that is defined in this schema:

<element name="userType" type="dkhm:userType" /> 
<element name="EAN" type="dkhm:EAN" /> 
<element name="CVR" type="dkhm:CVR" /> 
<element name="pnumber" type="dkhm:pnumber" /> 
<element name="contact" type="dkhm:contact" /> 
<element name="trackingNo" type="dkhm:trackingNo" /> 
<element name="domainAdvisory" type="dkhm:domainAdvisory" /> 
<element name="orderconfirmationToken" type="dkhm:orderconfirmationToken" /> 
<element name="domain_confirmed" type="dkhm:domain_confirmed" /> 
<element name="contact_validated" type="dkhm:contact_validated" /> 
<element name="registrant_validated" type="dkhm:registrant_validated" />

Each of these elements ultimately refers to an XML schema simpleType that includes a restriction for a base of type token. Based on my reading of the specification I believe the last three elements could be more efficiently represented as booleans, but what's there certainly works.

As I said in my first message in this thread I'd like to recommend to IANA that they process these requests as a single addition to the registry since each request describes an XML element that is part of the same schema and namespace. Could the other DEs please share your thoughts?

Scott