Subject: RE: Lack of activity in the group...

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 May 2002 08:27:40 -0400

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:[email-masked]]
> Sent: Wednesday, May 22, 2002 3:18 PM
> To: [email-masked]
> 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.

---

From: "Howard J. Eland" <[email-masked]>
Date: Thu, 23 May 2002 08:54:45 -0400

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

---

From: Ed Lewis <[email-masked]>
Date: Thu, 23 May 2002 08:58:05 -0400 (EDT)

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.

---

From: "Jordyn A. Buchanan" <[email-masked]>
Date: Thu, 23 May 2002 17:57:16 -0400

> 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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 28 May 2002 11:22:46 -0400

> beep documents,

------- Forwarded Message

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

Hello,

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

Internet-Drafts Administrator

------- End of Forwarded Message

One down.

Editorial changes prompted by Marshall Rose.

One to go.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 28 May 2002 11:24:59 -0400

> activity on the other drafts.

Agree.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 29 May 2002 14:14:23 -0400

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

Hello,

Two down.

Minor editorial changes.

Eric

---

From: Ed Lewis <[email-masked]>
Date: Thu, 30 May 2002 10:08:07 -0400 (EDT)

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

> submission (or message) to [email-masked]

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

Date: Thu, 30 May 2002 10:08:07 -0400 (EDT)
From: Ed Lewis <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: Lack of activity in the group... 
Sender: [email-masked]

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

> submission (or message) to [email-masked]

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

To: Ed Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Lack of activity in the group... 
Date: Wed, 29 May 2002 14:14:23 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hello,

Two down.

Minor editorial changes.

Eric

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-container-02.txt
Date: Thu, 30 May 2002 07:28:03 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-beep-02.txt
Date: Wed, 29 May 2002 07:33:26 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Edmon Chung" <[email-masked]>
To: "Robert Burbidge" <[email-masked]>, "Ietf-Provreg \(E-mail\)" <[email-masked]>
Subject: Re: EPP and verification processes
Date: Tue, 28 May 2002 11:42:43 -0400
Sender: [email-masked]

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" <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
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
>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Robert Burbidge'" <[email-masked]>, "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: RE: EPP and verification processes
Date: Tue, 28 May 2002 11:41:15 -0400
Sender: [email-masked]

> From: Robert Burbidge [mailto:[email-masked]]
> 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-

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Ed Lewis'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Lack of activity in the group... 
Date: Tue, 28 May 2002 11:24:59 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Agree.

Eric

To: Ed Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Lack of activity in the group... 
Date: Tue, 28 May 2002 11:22:46 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Hello,

One down.

One to go.

Eric

From: Robert Burbidge <[email-masked]>
To: "Ietf-Provreg (E-mail)" <[email-masked]>
Subject: EPP and verification processes
Date: Tue, 28 May 2002 16:05:26 +0100
Sender: [email-masked]

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

Date: Thu, 23 May 2002 17:57:16 -0400
Subject: Re: Lack of activity in the group...
From: "Jordyn A. Buchanan" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Ed Lewis'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Jordyn

Date: Thu, 23 May 2002 08:58:05 -0400 (EDT)
From: Ed Lewis <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: RE: Lack of activity in the group...
Sender: [email-masked]

> activity on the other drafts.

Reply-To: "Howard J. Eland" <[email-masked]>
From: "Howard J. Eland" <[email-masked]>
To: <[email-masked]>
Subject: Re: Lack of activity in the group...
Date: Thu, 23 May 2002 08:54:45 -0400
Organization: Afilias
Sender: [email-masked]

Scott,

Howard

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Ed Lewis'" <[email-masked]>, [email-masked]
Subject: RE: Lack of activity in the group...
Date: Thu, 23 May 2002 08:27:40 -0400
Sender: [email-masked]

Ed,

-Scott-

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

Date: Wed, 22 May 2002 15:18:16 -0400 (EDT)
From: Ed Lewis <[email-masked]>
To: [email-masked]
Subject: Lack of activity in the group...
Sender: [email-masked]

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.

Date: Thu, 9 May 2002 08:13:00 -0700 (PDT)
From: Rick Wesson <[email-masked]>
To: Chandra Talluri <[email-masked]>
cc: <[email-masked]>
Subject: Re: Is there a javacc grammar for epp
Sender: [email-masked]

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
>

Date: Thu, 09 May 2002 11:25:49 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Is there a javacc grammar for epp
Sender: [email-masked]

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
>
>  
>

Reply-To: <[email-masked]>
From: "Chandra Talluri" <[email-masked]>
To: <[email-masked]>
Subject: Is there a javacc grammar for epp
Date: Thu, 9 May 2002 10:41:07 -0400
Importance: Normal
Sender: [email-masked]

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

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-jseng-idn-admin-00.txt
Date: Thu, 09 May 2002 07:53:49 -0400
Sender: [email-masked]

--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 [email-masked].

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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: Administrative note -- springcleaning is here
Date: Tue, 07 May 2002 15:07:58 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

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).

Date: Mon, 06 May 2002 15:42:52 -0400
From: Andrew Newton <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: RE: XML Digital Signatures for EPP.
Sender: [email-masked]

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

--=_zark.ecotroph.net-29453-1020709110-0001-2--

Date: Mon, 6 May 2002 06:45:10 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Update on group's status & Preparation for Yokohama
Cc: [email-masked]
Sender: [email-masked]

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