Re: Lack of activity in the group...

[Ed Lewis <[e-mail]>]

This is one way to make a WG chair smile...

On Wed, 29 May 2002, Eric Brunner-Williams in Portland Maine wrote:
> ------- Forwarded Message
> From: [e-mail] (Internet Draft Submission Manager)
> 
> This message is being sent to acknowledge receipt of your
> submission (or message) to [e-mail]
> 

...the other is to get commentary flowing on the mailing list. :)




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4UE8Aa4004204 for <[e-mail]>; Thu, 30 May 2002 16:08:10 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4UE8Ajm004203 for ietf-provreg-outgoing; Thu, 30 May 2002 16:08:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4UE89a4004198 for <[e-mail]>; Thu, 30 May 2002 16:08:09 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id KAA01086; Thu, 30 May 2002 10:08:08 -0400 (EDT)
Received: from localhost (edlewis@localhost) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA24796; Thu, 30 May 2002 10:08:07 -0400 (EDT)
Date: Thu, 30 May 2002 10:08:07 -0400 (EDT)
From: Ed Lewis <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
cc: [e-mail]
Subject: Re: Lack of activity in the group... 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

This is one way to make a WG chair smile...

On Wed, 29 May 2002, Eric Brunner-Williams in Portland Maine wrote:
> ------- Forwarded Message
> From: [e-mail] (Internet Draft Submission Manager)
> 
> This message is being sent to acknowledge receipt of your
> submission (or message) to [e-mail]
> 

...the other is to get commentary flowing on the mailing list. :)



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4UDA6a4003007 for <[e-mail]>; Thu, 30 May 2002 15:10:06 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4UDA6Jo003006 for ietf-provreg-outgoing; Thu, 30 May 2002 15:10:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4UDA4a4003001 for <[e-mail]>; Thu, 30 May 2002 15:10:05 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.3/8.11.6) with ESMTP id g4TIEN7f018358; Wed, 29 May 2002 14:14:23 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Ed Lewis <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Lack of activity in the group... 
In-Reply-To: Your message of "Thu, 23 May 2002 08:58:05 EDT." <[e-mail]> 
Date: Wed, 29 May 2002 14:14:23 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> So far I've been promised new versions of the now-expired containers and
> beep documents,

------- Forwarded Message

Date: Wed, 29 May 2002 14:16:31 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: PROVREG I-D: draft-ietf-provreg-epp-container-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-URL: http://www.ietf.org/
Reply-to: [e-mail]
Subject: Autoreply from Internet Draft Submission Manager
From: [e-mail] (Internet Draft Submission Manager)

Hello,

This message is being sent to acknowledge receipt of your
submission (or message) to [e-mail]

Internet-Drafts Administrator

------- End of Forwarded Message

Two down.

Minor editorial changes.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4UCToa4001411 for <[e-mail]>; Thu, 30 May 2002 14:29:50 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4UCToYe001410 for ietf-provreg-outgoing; Thu, 30 May 2002 14:29:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4UCTna4001405 for <[e-mail]>; Thu, 30 May 2002 14:29:49 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29486; Thu, 30 May 2002 07:28:09 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-container-02.txt
Date: Thu, 30 May 2002 07:28:03 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Container
	Author(s)	: E. Brunner-Williams
	Filename	: draft-ietf-provreg-epp-container-02.txt
	Pages		: 41
	Date		: 29-May-02
	
This memo defines an extension to EPP objects.  The extension
supports hierarchy and inheritance amongst EPP objects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-container-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-container-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-container-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-container-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-container-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4TBZEXY018696 for <[e-mail]>; Wed, 29 May 2002 13:35:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g4TBZE13018695 for ietf-provreg-outgoing; Wed, 29 May 2002 13:35:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4TBZ8XY018690 for <[e-mail]>; Wed, 29 May 2002 13:35:13 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11164; Wed, 29 May 2002 07:33:27 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-provreg-epp-beep-02.txt
Date: Wed, 29 May 2002 07:33:26 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Transport Over BEEP
	Author(s)	: E. Brunner-Williams
	Filename	: draft-ietf-provreg-epp-beep-02.txt
	Pages		: 10
	Date		: 28-May-02
	
This memo defines a BEEP channel profile for EPP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-beep-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-beep-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-beep-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-beep-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-beep-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SFi1XY011778 for <[e-mail]>; Tue, 28 May 2002 17:44:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g4SFi1hI011777 for ietf-provreg-outgoing; Tue, 28 May 2002 17:44:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com ([66.48.4.181]) by nic.cafax.se (8.12.3/8.12.3) with SMTP id g4SFi0XY011772 for <[e-mail]>; Tue, 28 May 2002 17:44:00 +0200 (MEST)
Message-ID: <01cb01c2065e$4f50e7f0$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Robert Burbidge" <[e-mail]>, "Ietf-Provreg \(E-mail\)" <[e-mail]>
References: <[e-mail]>
Subject: Re: EPP and verification processes
Date: Tue, 28 May 2002 11:42:43 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Our implementation at SGNIC also required verification of contact similar to
your situation.
Currently, the gateway returns a particular response code to the client
notifying them that additional verification will be required (based on the
automated screening process result).  The status of the domain name will be
on Pending Verification, and the registrar is required to check on the
status and update the registrant regularly, by policy.  It also supports
revoking of previous decisions whether it was an approval or rejection.
Since the registry itself is responsible for the verification and not the
registrar, these operations are done within the registry system and will not
be necessary for the registrar to update the registry via EPP.  Although the
project did not mandate, but we also experimented with having the registrar
complete the verification and update the registry.  In that case, the
registrar will do a domain status update via EPP for the domain name to
change it from pending verification to Active.
Edmon


----- Original Message -----
From: "Robert Burbidge" <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Sent: Tuesday, May 28, 2002 11:05 AM
Subject: EPP and verification processes


> As we are making good progress on our generic epp implementation, we need
to
> finalise the verification extensions. How is EPP expected to be used for a
> domain that verifies registrants? I have the .coop TLD in mind, as you
might
> expect. Here's a summary of the salient points of the .coop registrant
> validation process. The real process is a little more subtle than I have
> described it, but it is sufficient to explain the background of my
question.
>
> * When creating a new registrant, the .coop registry requires contact
> details for the registrant (as with any other domain), and also contact
> details for two sponsor organisations. These sponsors can be used to
verify
> the status of the registrant as a bona fide cooperative organisation. Some
> sponsors are associated with particular countries, and some are
> international bodies.
> * Registrants are allocated an initial status based on their country
> of origin.
> * During the next few days, the relevant sponsoring organisations are
> contacted and as a result the registrant's status may be amended. A
> registrant may be rejected if not holding cooperative status. A registrant
> who has been rejected will have its domains revoked.
> * There is an appeals procedure which may result in a registrant being
> re-verified. Domains that had previously been revoked may be restored to
the
> registrant.
>
> How would you suggest that EPP should handle registrant verification?
>
> * We could ignore the verification process in EPP, and create all
> registrants when EPP commands reach the registry. Any subsquent
> investigation and revocation can be handled through out-of-band channels
> such as email or fax. This is not ideal, as the registry will then be
> responsible for manual collection of sponsor data, and makes the
> verification process very slack.
> * I note that there is a "pendingValidation" status for domains.
> However the one-line explanation doesn't actually mention validation,
there
> is no suggestion of the validation procedures, and (crucially) there is no
> validationFailed status. I wonder what the purpose of this status is.
> Incidentally, from our point of view we validate registrants, not domains.
> It's arguable that there are two different kinds of validation for a
domain
> name (a) this domain name is under review because of registry policy (b)
> this domain name is under review because the nominated registrant is under
> review. I am concerned that there is not enough flexibility to handle the
> two cases.
> * Should we use <poll> as a mechanism for notifying registrars that a
> registrant has been investigated etc?
> * Contact status values do not include any validation status codes.
> That's reasonable, because contacts are not always registrants. Only when
a
> domain is created does a contact become a registrant. However, our
workflow
> is based around validating the registrant, and subsequent domain
validation
> is dependent on registrant validation.
>
> Your thoughts and suggestions are of course welcome.
>
> Rob Burbidge
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SFfOXY011737 for <[e-mail]>; Tue, 28 May 2002 17:41:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4SFfOcT011736 for ietf-provreg-outgoing; Tue, 28 May 2002 17:41:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SFfNXY011731 for <[e-mail]>; Tue, 28 May 2002 17:41:24 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA05175; Tue, 28 May 2002 11:41:47 -0400 (EDT)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <KVF5XCCW>; Tue, 28 May 2002 11:41:16 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Robert Burbidge'" <[e-mail]>, "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: RE: EPP and verification processes
Date: Tue, 28 May 2002 11:41:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Robert Burbidge [mailto:[e-mail]]
> Sent: Tuesday, May 28, 2002 11:05 AM
> To: Ietf-Provreg (E-mail)
> Subject: EPP and verification processes
> 
> 
> As we are making good progress on our generic epp 
> implementation, we need to
> finalise the verification extensions. How is EPP expected to 
> be used for a
> domain that verifies registrants? I have the .coop TLD in 
> mind, as you might
> expect. Here's a summary of the salient points of the .coop registrant
> validation process. The real process is a little more subtle 
> than I have
> described it, but it is sufficient to explain the background 
> of my question.

[snip]

> Your thoughts and suggestions are of course welcome.

It sounds like you need to define a contact object extension (or extensions)
for the needs of your particular registry.  As you noted there's nothing in
the protocol to deal with registrant "verification", and that's because
verification is a very registry-specific thing.

You can see some examples of extension mappings in some I-Ds I've written.
There's one in the ENUM WG, and another individual submission under my name.
I'm not recommending that you write an I-D; it might be wise to consider if
such a document is really of interest to the IETF as a whole or if it's
really needed only by your customers.  If it's only needed by your customers
your best bet might be to craft your own document using the I-D as a
template, but to publish the document in whatever format and venue makes
sense for you and your customers.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SFVCXY011636 for <[e-mail]>; Tue, 28 May 2002 17:31:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4SFVCtc011635 for ietf-provreg-outgoing; Tue, 28 May 2002 17:31:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SFVBXY011630 for <[e-mail]>; Tue, 28 May 2002 17:31:11 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.3/8.11.6) with ESMTP id g4SFOx7f012603; Tue, 28 May 2002 11:24:59 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Ed Lewis'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Lack of activity in the group... 
In-Reply-To: Your message of "Thu, 23 May 2002 08:27:40 EDT." <[e-mail]6> 
Date: Tue, 28 May 2002 11:24:59 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I see little reason to meet in the absence of feedback from them IESG on the
> documents that have been through WG and IETF last calls, and the lack of
> activity on the other drafts.

Agree.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SFT0XY011588 for <[e-mail]>; Tue, 28 May 2002 17:29:00 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4SFT0Sg011587 for ietf-provreg-outgoing; Tue, 28 May 2002 17:29:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SFSxXY011582 for <[e-mail]>; Tue, 28 May 2002 17:28:59 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.3/8.11.6) with ESMTP id g4SFMk7f012588; Tue, 28 May 2002 11:22:46 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Ed Lewis <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Lack of activity in the group... 
In-Reply-To: Your message of "Thu, 23 May 2002 08:58:05 EDT." <[e-mail]> 
Date: Tue, 28 May 2002 11:22:46 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> So far I've been promised new versions of the now-expired containers and
> beep documents,

------- Forwarded Message

Date: Tue, 28 May 2002 11:21:48 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: PROVREG I-D: draft-ietf-provreg-epp-beep-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-URL: http://www.ietf.org/
Reply-to: [e-mail]
Subject: Autoreply from Internet Draft Submission Manager
From: [e-mail] (Internet Draft Submission Manager)

Hello,

This message is being sent to acknowledge receipt of your
submission (or message) to [e-mail]

Internet-Drafts Administrator

------- End of Forwarded Message

One down.

Editorial changes prompted by Marshall Rose.

One to go.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SF5cXY011320 for <[e-mail]>; Tue, 28 May 2002 17:05:38 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g4SF5cjI011319 for ietf-provreg-outgoing; Tue, 28 May 2002 17:05:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from popintmanex.poptel.org.uk (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4SF5aXY011314 for <[e-mail]>; Tue, 28 May 2002 17:05:37 +0200 (MEST)
Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id <LXX6SJ8K>; Tue, 28 May 2002 16:05:35 +0100
Message-ID: <[e-mail]>
From: Robert Burbidge <[e-mail]>
To: "Ietf-Provreg (E-mail)" <[e-mail]>
Subject: EPP and verification processes
Date: Tue, 28 May 2002 16:05:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

As we are making good progress on our generic epp implementation, we need to
finalise the verification extensions. How is EPP expected to be used for a
domain that verifies registrants? I have the .coop TLD in mind, as you might
expect. Here's a summary of the salient points of the .coop registrant
validation process. The real process is a little more subtle than I have
described it, but it is sufficient to explain the background of my question.

*	When creating a new registrant, the .coop registry requires contact
details for the registrant (as with any other domain), and also contact
details for two sponsor organisations. These sponsors can be used to verify
the status of the registrant as a bona fide cooperative organisation. Some
sponsors are associated with particular countries, and some are
international bodies.
*	Registrants are allocated an initial status based on their country
of origin.
*	During the next few days, the relevant sponsoring organisations are
contacted and as a result the registrant's status may be amended. A
registrant may be rejected if not holding cooperative status. A registrant
who has been rejected will have its domains revoked.
*	There is an appeals procedure which may result in a registrant being
re-verified. Domains that had previously been revoked may be restored to the
registrant.

How would you suggest that EPP should handle registrant verification?

*	We could ignore the verification process in EPP, and create all
registrants when EPP commands reach the registry. Any subsquent
investigation and revocation can be handled through out-of-band channels
such as email or fax. This is not ideal, as the registry will then be
responsible for manual collection of sponsor data, and makes the
verification process very slack.
*	I note that there is a "pendingValidation" status for domains.
However the one-line explanation doesn't actually mention validation, there
is no suggestion of the validation procedures, and (crucially) there is no
validationFailed status. I wonder what the purpose of this status is.
Incidentally, from our point of view we validate registrants, not domains.
It's arguable that there are two different kinds of validation for a domain
name (a) this domain name is under review because of registry policy (b)
this domain name is under review because the nominated registrant is under
review. I am concerned that there is not enough flexibility to handle the
two cases.
*	Should we use <poll> as a mechanism for notifying registrars that a
registrant has been investigated etc?
*	Contact status values do not include any validation status codes.
That's reasonable, because contacts are not always registrants. Only when a
domain is created does a contact become a registrant. However, our workflow
is based around validating the registrant, and subsequent domain validation
is dependent on registrant validation.

Your thoughts and suggestions are of course welcome.

Rob Burbidge



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NLtqXY010036 for <[e-mail]>; Thu, 23 May 2002 23:55:52 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4NLtqM9010035 for ietf-provreg-outgoing; Thu, 23 May 2002 23:55:52 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from total.confusion.net (buchanan.nac.net [209.123.121.74]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NLtpXY010030 for <[e-mail]>; Thu, 23 May 2002 23:55:51 +0200 (MEST)
Received: from [216.21.238.2] (helo=[10.10.20.157]) by total.confusion.net with asmtp (Exim 3.34 #1) id 17B0Yj-0003Dg-00; Thu, 23 May 2002 17:55:45 -0400
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 23 May 2002 17:57:16 -0400
Subject: Re: Lack of activity in the group...
From: "Jordyn A. Buchanan" <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>, "'Ed Lewis'" <[e-mail]>, <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]6>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk

On 5/23/02 8:27 AM, "Hollenbeck, Scott" <[e-mail]> wrote:

> Ed,
> 
> The first draft of EPP-BEEP has been out for some time.  A better question
> relates to when it might be updated.
> 
> At the Minneapolis meeting Hong mentioned that the original authors of the
> containers draft had decided to not pursue it further.  Have no editors been
> found, or have the original authors changed their minds?
> 
> Has anyone stepped up to write an EPP-over-email I-D?

I'd be willing to do this, as we may actually need this sometime in the
not-so-distant future.  I could probably have something done in time for
Yokohama, although it would be a close thing given the I-D deadline.

Jordyn



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NCwAXY007021 for <[e-mail]>; Thu, 23 May 2002 14:58:10 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4NCwAZf007020 for ietf-provreg-outgoing; Thu, 23 May 2002 14:58:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NCw9XY007015 for <[e-mail]>; Thu, 23 May 2002 14:58:09 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id IAA29905; Thu, 23 May 2002 08:58:06 -0400 (EDT)
Received: from localhost (edlewis@localhost) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA23189; Thu, 23 May 2002 08:58:05 -0400 (EDT)
Date: Thu, 23 May 2002 08:58:05 -0400 (EDT)
From: Ed Lewis <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: [e-mail]
Subject: RE: Lack of activity in the group...
In-Reply-To: <[e-mail]6>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

About the "first" BEEP draft milestone, that was a typo.  (I thought I had
cleared that up with the secreteriate.  Oops.)

So far I've been promised new versions of the now-expired containers and
beep documents, but none have appeared.  No one has volunteered to write
the SMTP transport draft.

On Thu, 23 May 2002, Hollenbeck, Scott wrote:

> Ed,
> 
> The first draft of EPP-BEEP has been out for some time.  A better question
> relates to when it might be updated.
> 
> At the Minneapolis meeting Hong mentioned that the original authors of the
> containers draft had decided to not pursue it further.  Have no editors been
> found, or have the original authors changed their minds?
> 
> Has anyone stepped up to write an EPP-over-email I-D?
> 
> I see little reason to meet in the absence of feedback from them IESG on the
> documents that have been through WG and IETF last calls, and the lack of
> activity on the other drafts.
> 
> -Scott-
> 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NCroXY006993 for <[e-mail]>; Thu, 23 May 2002 14:53:50 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4NCroEN006992 for ietf-provreg-outgoing; Thu, 23 May 2002 14:53:50 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ns01.afilias.info (ns01.afilias.info [66.45.25.225]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NCrmXY006987 for <[e-mail]>; Thu, 23 May 2002 14:53:49 +0200 (MEST)
Received: from beast (ctt185126.ceinetworks.com [216.169.185.126]) (authenticated) by ns01.afilias.info (8.11.2/8.11.2) with ESMTP id g4NCrkG02172 for <[e-mail]>; Thu, 23 May 2002 08:53:47 -0400
Message-ID: <003f01c20259$04487ec0$a6d6fea9@beast>
Reply-To: "Howard J. Eland" <[e-mail]>
From: "Howard J. Eland" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]6>
Subject: Re: Lack of activity in the group...
Date: Thu, 23 May 2002 08:54:45 -0400
Organization: Afilias
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: [e-mail]
Precedence: bulk

Scott,

I was under the impression that Eric is going to write this, but Dan Manley
and myself would be more than happy to work on it, if indeed there is an
interest in the group to have an SMTP transport.

If I don't hear anything by June 10th, we'll get to work...

Howard


----- Original Message -----
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Ed Lewis'" <[e-mail]>; <[e-mail]>
Sent: Thursday, May 23, 2002 8:27 AM
Subject: RE: Lack of activity in the group...


> Ed,
>
> The first draft of EPP-BEEP has been out for some time.  A better question
> relates to when it might be updated.
>
> At the Minneapolis meeting Hong mentioned that the original authors of the
> containers draft had decided to not pursue it further.  Have no editors
been
> found, or have the original authors changed their minds?
>
> Has anyone stepped up to write an EPP-over-email I-D?
>
> I see little reason to meet in the absence of feedback from them IESG on
the
> documents that have been through WG and IETF last calls, and the lack of
> activity on the other drafts.
>
> -Scott-
>




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NCSKXY006842 for <[e-mail]>; Thu, 23 May 2002 14:28:20 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g4NCSKt7006841 for ietf-provreg-outgoing; Thu, 23 May 2002 14:28:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4NCSGXY006836 for <[e-mail]>; Thu, 23 May 2002 14:28:19 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA11064; Thu, 23 May 2002 08:28:10 -0400 (EDT)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19) id <2WF6GDCN>; Thu, 23 May 2002 08:27:41 -0400
Message-ID: <[e-mail]6>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Ed Lewis'" <[e-mail]>, [e-mail]
Subject: RE: Lack of activity in the group...
Date: Thu, 23 May 2002 08:27:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Ed,

The first draft of EPP-BEEP has been out for some time.  A better question
relates to when it might be updated.

At the Minneapolis meeting Hong mentioned that the original authors of the
containers draft had decided to not pursue it further.  Have no editors been
found, or have the original authors changed their minds?

Has anyone stepped up to write an EPP-over-email I-D?

I see little reason to meet in the absence of feedback from them IESG on the
documents that have been through WG and IETF last calls, and the lack of
activity on the other drafts.

-Scott-

> -----Original Message-----
> From: Ed Lewis [mailto:[e-mail]]
> Sent: Wednesday, May 22, 2002 3:18 PM
> To: [e-mail]
> Subject: Lack of activity in the group...
> 
> 
> 
> Eyeing the IETF meeting in Yokohama, its about time to decide 
> on whether
> we should meet.  It would be good to have a meeting there to at least
> bring EPP to the region, but there's no sense "forcing" a meeting.
> 
> There's been a lack of activity in the group.  We have three
> milestones to meet this month:
>  MAY 02 Second draft of Containers
>  MAY 02 First draft of EPP over BEEP
>  MAY 02 First draft of EPP over SMTP
> 
> I'd like to hear WG comments on meeting/not meeting.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4MJIKXY001986 for <[e-mail]>; Wed, 22 May 2002 21:18:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g4MJIK3H001985 for ietf-provreg-outgoing; Wed, 22 May 2002 21:18:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g4MJIIXY001980 for <[e-mail]>; Wed, 22 May 2002 21:18:19 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id PAA28664 for <[e-mail]>; Wed, 22 May 2002 15:18:17 -0400 (EDT)
Received: from localhost (edlewis@localhost) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA06997 for <[e-mail]>; Wed, 22 May 2002 15:18:17 -0400 (EDT)
Date: Wed, 22 May 2002 15:18:16 -0400 (EDT)
From: Ed Lewis <[e-mail]>
To: [e-mail]
Subject: Lack of activity in the group...
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Eyeing the IETF meeting in Yokohama, its about time to decide on whether
we should meet.  It would be good to have a meeting there to at least
bring EPP to the region, but there's no sense "forcing" a meeting.

There's been a lack of activity in the group.  We have three
milestones to meet this month:
 MAY 02 Second draft of Containers
 MAY 02 First draft of EPP over BEEP
 MAY 02 First draft of EPP over SMTP

I'd like to hear WG comments on meeting/not meeting.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49FD8XY012932 for <[e-mail]>; Thu, 9 May 2002 17:13:08 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g49FD8ib012931 for ietf-provreg-outgoing; Thu, 9 May 2002 17:13:08 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49FD6XY012926 for <[e-mail]>; Thu, 9 May 2002 17:13:07 +0200 (MEST)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.2/8.12.0) with ESMTP id g49FD0IL003055; Thu, 9 May 2002 08:13:01 -0700 (PDT)
Date: Thu, 9 May 2002 08:13:00 -0700 (PDT)
From: Rick Wesson <[e-mail]>
To: Chandra Talluri <[e-mail]>
cc: <[e-mail]>
Subject: Re: Is there a javacc grammar for epp
In-Reply-To: <001201c1f767$8e7e2b50$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Chandra,

i think most folks use an xml parser instead of a LALR grammar, i'd suggest
just using xerces.

i have personally been waiting for castor to be able to handle our
schemas.... http://www.castor.org but now with JAXB around the corner we
will be able to marshal the XML to/from the registry and java objects.


-rick


On Thu, 9 May 2002, Chandra Talluri wrote:

>
> Is anybody working on javacc grammar for epp? Is it worth developing our own
> parser for epp or should we use already existing xml parsers like xerces.
> Any views are appreciated
>
> -Chandra
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49FAEXY012887 for <[e-mail]>; Thu, 9 May 2002 17:10:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g49FAE0B012886 for ietf-provreg-outgoing; Thu, 9 May 2002 17:10:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from toronto.mail.tucows.com (toronto.mail.tucows.com [207.136.98.42]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49FADXY012881 for <[e-mail]>; Thu, 9 May 2002 17:10:13 +0200 (MEST)
Received: from [10.0.10.19] (helo=tucows.com) by toronto.mail.tucows.com with esmtp (Exim 3.36 #1) id 175pYP-0005R5-00; Thu, 09 May 2002 11:10:01 -0400
Message-ID: <[e-mail]>
Date: Thu, 09 May 2002 11:25:49 -0400
From: Daniel Manley <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Is there a javacc grammar for epp
References: <001201c1f767$8e7e2b50$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

There are already a few client implementations of EPP on sourceforge... 
such as http://epp-rtk.sf.net  -- I think most of the implementations 
use xerces (in java and c++).  It's probably best to stick to something 
like xerces -- tried test and true and (xerces anyhow) supported by 
Jakarta/Apache and developers around the world -- also because most of 
the ready-to-wear parsers include schema validation.

Dan

Chandra Talluri wrote:

>Is anybody working on javacc grammar for epp? Is it worth developing our own
>parser for epp or should we use already existing xml parsers like xerces.
>Any views are appreciated
>
>-Chandra
>
>  
>





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49EfFXY012790 for <[e-mail]>; Thu, 9 May 2002 16:41:15 +0200 (MEST)
Received: by nic.cafax.se (8.12.3/8.12.3/Submit) id g49EfFYo012789 for ietf-provreg-outgoing; Thu, 9 May 2002 16:41:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49EfAXY012784 for <[e-mail]>; Thu, 9 May 2002 16:41:14 +0200 (MEST)
Received: from CHANDRA ([65.203.166.55]) by hvmta01-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020509144109.CYP1815.hvmta01-stg.us.psimail.psi.net@CHANDRA> for <[e-mail]>; Thu, 9 May 2002 10:41:09 -0400
Reply-To: <[e-mail]>
From: "Chandra Talluri" <[e-mail]>
To: <[e-mail]>
Subject: Is there a javacc grammar for epp
Date: Thu, 9 May 2002 10:41:07 -0400
Message-ID: <001201c1f767$8e7e2b50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Is anybody working on javacc grammar for epp? Is it worth developing our own
parser for epp or should we use already existing xml parsers like xerces.
Any views are appreciated

-Chandra



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49Bs2XY012147 for <[e-mail]>; Thu, 9 May 2002 13:54:02 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g49Bs206012145 for ietf-provreg-outgoing; Thu, 9 May 2002 13:54:02 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g49Bs0XY012140 for <[e-mail]>; Thu, 9 May 2002 13:54:01 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16369; Thu, 9 May 2002 07:53:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: [e-mail], [e-mail], [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-jseng-idn-admin-00.txt
Date: Thu, 09 May 2002 07:53:49 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Internationalized Domain Name Administration Guideline
	Author(s)	: J. Seng
	Filename	: draft-jseng-idn-admin-00.txt
	Pages		: 
	Date		: 08-May-02
	
There are many complex issues revolving around the internationalized
access to domain names (IDN) such as the IDN protocol, IDN deployment,
IDN transition and IDN administration.
While the IDN working group focuses on the standard track specification
on access to IDN, the administration guideline is also necessary to
ensure a smooth deployment and transition.
This document provides a guideline for all zone administrators,
including but not limited to registry/registrars operators and all
domain names holders on the administration of these domain names.
Comments on this document can send to the authors at [e-mail].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-jseng-idn-admin-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-jseng-idn-admin-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-jseng-idn-admin-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-jseng-idn-admin-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g47D83XY028796 for <[e-mail]>; Tue, 7 May 2002 15:08:03 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g47D83l7028795 for ietf-provreg-outgoing; Tue, 7 May 2002 15:08:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g47D80XY028790 for <[e-mail]>; Tue, 7 May 2002 15:08:00 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.2/8.12.2) with ESMTP id g47D7wKF069525 for <[e-mail]>; Tue, 7 May 2002 15:07:58 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Administrative note -- springcleaning is here
Date: Tue, 07 May 2002 15:07:58 +0200
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

People tend to move around and have there mail adresses changed but
fail to tell the list they are subscibed on. This causes quite some
bounced mail to list operators. So please change your subscibtion
adress else I'll just remove you from the mailinglist.

	jaap (acting as list maintainer).


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g46Jk5XY024096 for <[e-mail]>; Mon, 6 May 2002 21:46:05 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g46Jk5PK024095 for ietf-provreg-outgoing; Mon, 6 May 2002 21:46:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from zark.ecotroph.net (64.83.37.226.dsl226-static-nova.cavtel.net [64.83.37.226]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g46Jk3XY024090 for <[e-mail]>; Mon, 6 May 2002 21:46:04 +0200 (MEST)
Received: from ecotroph.net ([::ffff:216.168.231.217]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zark.ecotroph.net with esmtp; Mon, 06 May 2002 14:18:30 -0400
Message-ID: <[e-mail]>
Date: Mon, 06 May 2002 15:42:52 -0400
From: Andrew Newton <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-6mdk i686)
X-Accept-Language: en
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="=_zark.ecotroph.net-29453-1020709110-0001-2"
To: [e-mail]
Subject: RE: XML Digital Signatures for EPP.
Sender: [e-mail]
Precedence: bulk

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zark.ecotroph.net-29453-1020709110-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This bounced from the list and I didn't catch it... so here it is again.

> On Thu, 2002-04-18 at 12:06, Hollenbeck, Scott wrote:
> > I don't think canonicalization (c14n) is really an issue since it's a
> > just a process that describes how to produce a consistent representation
> > of a well-formed instance.  Looking at the spec [1] right now I don't
> > see any real issues.
> 
> My rather shallow understanding of this is that as the XML instance
> pases from one parser to another, things that get signed as:
> 
>   <a>
>     <b/>
>   </a>
> 
> can get easily transformed into:
> 
>   <a><b/></a>
> 
> causing the signature to become invalid because the content has indeed
> been changed.  Again, my rather shallow understanding of the issue.
> 
> I do know of one other standards body creating an XML protocol that ran
> head-long into this topic and found that c14n wasn't good enough.
> 
> > On the other hand, you're probably right about trying to provide
> > integrity, authentication, and non-repudiation services at some other
> > layer.  The XML DSIG specs allow multiple transforms (such as c14n and
> > perhaps compression) to be applied prior to signing, but XML signatures
> > add a lot of "wrapper" that add to bandwidth and processing horsepower
> > requirements.
> 
> Interesting about the multiple transforms.  It would seem that you could
> just drop in ZIP or something, but I have been told otherwise.  I'll
> have to go pound on my source for a reason why it wouldn't work.
> 
> -andy
> 
>
--=_zark.ecotroph.net-29453-1020709110-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIII9AYJKoZIhvcNAQcCoIII5TCCCOECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BkYwggMGMIICb6ADAgECAgMHMt4wDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjA0MTAxODU4MjBaFw0wMzA0MTAxODU4MjBa
MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGFu
ZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5Kc4
10hpxiGBE08UE3H/qKMXC/cx3lQeVKk7/dKSUNZkspeOXZiH/oFyl9tQtcIxQ216EvXo53T1
2QBB044fo+CkitDYvt1zZSHLQY9cBDR3s8FqA7HVHOAyC7BMqUPaSBaliaXDOlPbXBxOkuGY
sBdRAzRv51UdW3HoWAhkGBWCzMCVMru7e1ZGrwtrYqaWXJN37spr7QgHdVmXhjOSu7rMmiDC
UW5IneJomR+nHNiFmjqFqMxFpJw/5MmdjPCjS8iVwbSU0QpFepenIc/Fr0pBH/qDlEX1Tawr
sLlRJA+npwO97b2VViAdajF35k+6c7ZMl4C5NAF0fvN6qzEWfQIDAQABozEwLzAfBgNVHREE
GDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAHF4Ljf5CziCiMSNwm++3gO/XyAXz0aPUNoQNtPj+C3CndMZIgKsxIUnYbLM0EYcZFDZ
O2QTpLB53zq2hT1sdPs3YpgXkJY31s+JsT6zOR6zDYYtdqNuE0cb/BzIZIzhRJlcl3M7zHoy
h/0PnY54cc7m6StJtmfbc2n/sCu1YCoyMIIDODCCAqGgAwIBAgIQZkVyt8x09c9jdkWE0C6R
ATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG
A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFp
bEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVowgZIxCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0G
A1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMf
UGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/+TRx
oKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENCUFGH
gzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwxGjAY
BgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEipxL4IpXoG0m3
J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFssBpp0SsSskBd
avl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYICdjCCAnICAQEw
gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl
czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBzLeMAkGBSsO
AwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIw
NTA2MTk0MjUyWjAjBgkqhkiG9w0BCQQxFgQUDoRDBS8gi4yMFGRQ9P8Uu3S7OkIwUgYJKoZI
hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAWU5Q4WZ/TzEciu1B
V6YPTy1nt3DCd804gF9MlX9D3tSfEmyA43rmpLIOFhNpvoJ9tQpGmUqoTtcyf679HYLKCLGl
ZcNg1RSxfrXyWBra9BB/bX5VdGk90yEHBYobp11C4DEsdFEehwQOj4pabPlUJHLvNs0BuiM8
jbAdAJBauJmwYn69h40t82YERfIlGOkEPaO15YCUz3gaHrligWYpPl2CNUNqN9liafL2R7Xp
xXINI2BRK9hO4a0Qer97+PAAmZi8yw93FdJbJFfYe1YDn9RXCm7GsljD7Ftb3gEDuXajfesq
r+AXEYvEnb46SY3Zry7gLijNgAceiJvIzffjLw==
--=_zark.ecotroph.net-29453-1020709110-0001-2--


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g46AjEXY020970 for <[e-mail]>; Mon, 6 May 2002 12:45:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3/8.12.3/Submit) id g46AjERJ020969 for ietf-provreg-outgoing; Mon, 6 May 2002 12:45:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by nic.cafax.se (8.12.3/8.12.3) with ESMTP id g46Aj9XY020964 for <[e-mail]>; Mon, 6 May 2002 12:45:10 +0200 (MEST)
Received: from 208-58-216-182.s182.tnt1.annp.md.dialup.rcn.com ([208.58.216.182]) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.33 #10) id 174fzP-0004rW-00; Mon, 06 May 2002 06:45:08 -0400
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05111700b8fc0d935b89@[208.58.216.112]>
Date: Mon, 6 May 2002 06:45:10 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Update on group's status & Preparation for Yokohama
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

During the last week Jaap and I went through the mail list 
discussions and reported on the working group's status to the CENTR 
Tech Forum and to the RIPE DNR WG.

The only "decision" made is to hold on to the containers document for 
the time being.  Due to an unfortunate incident, I managed to lose 
some data while at the meetings (both held in the same location).  I 
recall sending mail to the editors of the containers and BEEP 
transport document to let them know that the two documents expired 
"April 2002" and are in need of updates to keep them fresh in the ID 
repository.

The other documents in the mill now are the requirements which is in 
front of the IESG and the so-called core documents which are pending 
publication of other docs, which are normative references to our set.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis (home account)              PO Box 214, Glenwood, MD 21738
410-923-4365                                  living in Crownsville, MD