Re: [eppext] Minutes for our meeting in Yokohama IETF94

"Gould, James" <> Thu, 05 November 2015 13:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 078F41B2D11 for <>; Thu, 5 Nov 2015 05:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c-kUNvsBns3l for <>; Thu, 5 Nov 2015 05:58:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E67D1B2D13 for <>; Thu, 5 Nov 2015 05:58:25 -0800 (PST)
Received: by oiww189 with SMTP id w189so1055980oiw.2 for <>; Thu, 05 Nov 2015 05:58:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=Cnqau7D9+Z8K9KZhxfctqLEpuxMdWhJhJ+sEgLg5ynQ=; b=jrpzNhRqU5HLRIpsVVXPddWdC90thsa9hpBTQi88MoDTlR/S/cybboKXM3MCvjICcq sKfsMY7P5c4uSJgtHDTwoO/COaRMsUp6OD8u4GHFjUKhRyR8A5dQvQ+X8670YQ3xncJ7 so2zBEqjiU277pVjXvDY87EzksX7G0nlOsTO/vw6USqnHP+OZg1gTYZMaBMKgvQVJgm/ W/PDQdWEj+tc78tUr1vLowFGOduymM0XMUO9mzY3RKtLkIHaRD/s/47+x+7C15S8Yx+b KJQEBst2UcbWObNWz5pzjAInR+wnFpJehbx8kT6/CT8GUnCkuX5buDeDUnEjXKvuwKRo EPYw==
X-Gm-Message-State: ALoCoQlT2Cj3XM/Kmqw5zAE2JBCvVTp4ZwE9dadgZ6+kr42+8+BURI3pR6TEw51Qym8TlE+Ovs1BtD6Z2Qkt18Wh0nqSfAApNA==
X-Received: by with SMTP id u137mr7143426qka.94.1446731904295; Thu, 05 Nov 2015 05:58:24 -0800 (PST)
Received: from ( []) by with ESMTPS id v12sm744594qka.13.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 05:58:24 -0800 (PST)
Received: from (brn1wnexchm01 []) by (8.13.8/8.13.8) with ESMTP id tA5DwNjP013606 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 08:58:23 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Thu, 5 Nov 2015 08:58:22 -0500
From: "Gould, James" <>
To: Linlin Zhou <>
Thread-Topic: [eppext] Minutes for our meeting in Yokohama IETF94
Thread-Index: AQHRF6m9eK/y8o0l60m7mZABbgQMIp6NON3PgAB7sYCAAA5mgIAABZmA
Date: Thu, 05 Nov 2015 13:58:22 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_1CE7A0FEDAC84757A131340047FAB812verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Cc: Ulrich Wisser <>, "" <>
Subject: Re: [eppext] Minutes for our meeting in Yokohama IETF94
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2015 13:58:28 -0000


I really don’t understand the concern related to passing large image files via EPP.  There is no technical reason why EPP cannot include elements that happen to contain a large amount of data to satisfy a specific provisioning use case.   In this case the client is attempting to create a signed code based on the verification of the input, which can include information like scanned images.

Do you have any specific technical limitation with EPP that will not work for this?

Do you know of a standards track HTTP interface for Chinese verification that can be used to help with what is defined in the nv draft?

Do you have any specific feedback on the elements that are passed with the nv draft other then the size of the image files?

Any feedback is welcome to help ensure that the nv draft covers what is needed for Chinese verification.  The fact that we’re discussing the interface that is needed for Chinese verification is a positive step in helping meet the goals of the working group.





James Gould
Distinguished Engineer

12061 Bluemont Way
Reston, VA 20190<>

On Nov 5, 2015, at 8:38 AM, Linlin Zhou <<>> wrote:

Dear James,

On Nov 5, 2015, at 5:24 AM, Linlin Zhou <<>> wrote:

Dear Ulrich,
Thanks for the hardwork for taking meeting minutes. However, I feel that two points may be missed.
1. We have hum for adopting informational drafts in WG charter, but to the particular two drafts of verification signedcode and nv document, the WG seems having no clear cosensus on adopting them. Although it showed up in the milestone slide.

The hum’s where associated with the informational drafts, which does not include the verificationcode draft since it is defined as standards track.  There was no expressed issue with the WG adopting the verificationcode draft.  It was agreed that informational track drafts can be brought into the WG.

Sorry, my mistake. Verificationcode draft is standards track. So we have not reached consensus on the nv draft adoption.

2. I recalled my memory that several people have comments on nv draft and it seems not be fully supported. Minutes does not include these records.

There was not clear consensus on the nv draft since it was defined as informational and there was the question of applicability for the WG.  The verificationcode draft defines a standard framework for applying local verification policies where the nv draft defines a concrete use case for China.  Based on the number of registrars and registries that will need to address the verification regulations in China and potentially in other countries, I believe that it’s important for the WG to address the standards track verificationcode draft as well as the concrete use case for China with the nv draft.

I feel that verificationcode draft is more like a general method which could be used for real name verification or anything else verification. But the local verification policies in China is really somthing complex that the nv draft may not be the best choice. Many Chinese registrars and registries already implemented some other interface based on HTTP. If WG indeed wants some standards to address this scenario over EPP, I am skepticle on whether EPP is appropriate to transfer large image files as I said in the Jabber room.

EppExt mailing list<>