Subject: RE: EPP Schema and Example Instance Files
From: "Damaraju, Ayesha" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Thu, 31 May 2001 09:43:42 -0500

Scott,

One more..

For Contact/host objects.
"ok" status MUST NOT be combined with any other status. 

-- I believe... it can be combined with "linked" status

Thanks
-A
---------------

Scott,

Few questions/comments on new schemas...

1. Moved the <roid> element out of the response data for <create> and <info>
   command, and now is in the <response> element as an optional element.

- Please verify....This will complicate the XML validation process as this
element needs to be tested
  explicitly for create and info. We prefer them being part of create & info
response data to simplify 
  validations and object mappings.

2. Added an <id> element into the <create> for creating contacts.

- Please confirm....<id> is provided by the Registrar with a <create>
command.
  It is a server-unique id (though generated by Registrar). Server will
reject <create> command
  with existing <id> element.

Thanks
-Ayesha
  
-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 5:21 PM
To: [email-masked]'
Subject: EPP Schema and Example Instance Files

EPP-02 schemas and example XML instances in .zip and .tar.gz formats are
available via anonymous ftp for anyone who prefers to avoid copying and
pasting text from the I-Ds.  I've confirmed that all of the examples work
just fine with Xerces-J 1.4.0.

You can find the files on two different servers:

ftp://nic-naa.net/incoming/epp_053001/ (thanks to Eric Brunner-Williams)

and

ftp://ftp.verisign.com/pub/epp/20010530/

It may help to have "enable folder view for ftp" enabled if you're using MS
IE and the link above doesn't work for you.

<Scott/>

From: "Damaraju, Ayesha" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: EPP Schema and Example Instance Files
Date: Thu, 31 May 2001 09:39:22 -0500
Sender: [email-masked]

Scott,

Few questions/comments on new schemas...

1. Moved the <roid> element out of the response data for <create> and <info>
   command, and now is in the <response> element as an optional element.

- Please verify....This will complicate the XML validation process as this
element needs to be tested
  explicitly for create and info. We prefer them being part of create & info
response data to simplify 
  validations and object mappings.

2. Added an <id> element into the <create> for creating contacts.

- Please confirm....<id> is provided by the Registrar with a <create>
command.
  It is a server-unique id (though generated by Registrar). Server will
reject <create> command
  with existing <id> element.

Thanks
-Ayesha
  
-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 5:21 PM
To: [email-masked]'
Subject: EPP Schema and Example Instance Files

EPP-02 schemas and example XML instances in .zip and .tar.gz formats are
available via anonymous ftp for anyone who prefers to avoid copying and
pasting text from the I-Ds.  I've confirmed that all of the examples work
just fine with Xerces-J 1.4.0.

You can find the files on two different servers:

ftp://nic-naa.net/incoming/epp_053001/ (thanks to Eric Brunner-Williams)

and

ftp://ftp.verisign.com/pub/epp/20010530/

It may help to have "enable folder view for ftp" enabled if you're using MS
IE and the link above doesn't work for you.

<Scott/>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-tcp-00.txt
Date: Thu, 31 May 2001 06:59:45 -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 TCP
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-tcp-00.txt
	Pages		: 9
	Date		: 30-May-01
	
This document describes how an Extensible Provisioning Protocol (EPP)
session is mapped onto a single Transmission Control Protocol (TCP)
connection.  This mapping requires use of the Transport Layer Security
(TLS) Protocol to protect information exchanged between an EPP client
and an EPP server.

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

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-tcp-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-ietf-provreg-epp-tcp-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-ietf-provreg-epp-tcp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-tcp-00.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-host-00.txt
Date: Thu, 31 May 2001 06:59:40 -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 Host Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-host-00.txt
	Pages		: 26
	Date		: 30-May-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet host names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to host names.

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

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-host-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-ietf-provreg-epp-host-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-ietf-provreg-epp-host-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-host-00.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-domain-00.txt
Date: Thu, 31 May 2001 06:59:35 -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 Domain Name Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-domain-00.txt
	Pages		: 35
	Date		: 30-May-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet domain names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names.

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

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-domain-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-ietf-provreg-epp-domain-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-ietf-provreg-epp-domain-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-domain-00.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-contact-00.txt
Date: Thu, 31 May 2001 06:59:29 -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 Contact Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-contact-00.txt
	Pages		: 37
	Date		: 30-May-01
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of individual or
organizational social information identifiers (known as 'contacts')
stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to contacts.

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

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-contact-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-ietf-provreg-epp-contact-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-ietf-provreg-epp-contact-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-contact-00.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-02.txt
Date: Thu, 31 May 2001 06:59:08 -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
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-02.txt
	Pages		: 63
	Date		: 30-May-01
	
This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository.  Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects.

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

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-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-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-02.txt

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

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

--OtherAccess--

--NextPart--

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Temporary EPP TCP Port Assignment from IANA
Date: Wed, 30 May 2001 21:59:04 -0400
Sender: [email-masked]

Anyone interested in playing with EPP with TCP/TLS transport should note
that IANA has been kind enough to provide temporary user port assignments.
These assignments provide a higher degree of assurance of avoiding conflicts
with undocumented port use.

It's kind of funny that this showed up today, AFTER I sent in the document
updates.  Oh, well, I'll get it into the next version of the TCP draft.

<Scott/> 

-----Original Message-----

Dear Scott,

We have assigned the following user port number with 
you as the point of contact:

epp-temp        3121/tcp   Extensible Provisioning Protocol
epp-temp        3121/udp   Extensible Provisioning Protocol
#                          Scott Hollenbeck <[email-masked]>

Please notify the IANA if there is a change in contact
information.  When a system port number is assigned after your
document has been approved by the IESG, please notify the IANA
and we will retract this assignment and assign the system port
number.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP Schema and Example Instance Files
Date: Wed, 30 May 2001 17:20:30 -0400
Sender: [email-masked]

EPP-02 schemas and example XML instances in .zip and .tar.gz formats are
available via anonymous ftp for anyone who prefers to avoid copying and
pasting text from the I-Ds.  I've confirmed that all of the examples work
just fine with Xerces-J 1.4.0.

You can find the files on two different servers:

ftp://nic-naa.net/incoming/epp_053001/ (thanks to Eric Brunner-Williams)

and

ftp://ftp.verisign.com/pub/epp/20010530/

It may help to have "enable folder view for ftp" enabled if you're using MS
IE and the link above doesn't work for you.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: EPP Document Updates 
Date: Wed, 30 May 2001 14:01:05 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

Now that I've got some time on my hands I'll work on the data collection
policy, the beep mapping, and an event model draft. I'll send you drafts
in a week's time.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP Document Updates
Date: Wed, 30 May 2001 13:38:05 -0400
Sender: [email-masked]

Earlier today I sent document updates to the I-D administrator and our WG
chairs.  The EPP-02 document should be published shortly.  All of the
mapping documents have be renamed to initial submission WG drafts, so those
require chair approval before they'll get published.  If they don't get
announced at the same time it should just be a matter of approval from Ed or
Jaap.

There's one requirement that I still haven't addressed in the contact
mapping: data protection and privacy specifications.  Eric sent a sketch of
a proposal based on P3P to the list last month, and I just haven't had a
chance to digest it in detail.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: VeriSign EPP IPR Statement 
Date: Tue, 22 May 2001 09:53:12 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Xerces-J 1.4.0 is supposed to be released today

Yeah, I'm on the edge of my chair on this one also. Just-in-time parsers, neh?

Two weeks is good, we will have a mapping-over-BEEP out for review within this
period.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: VeriSign EPP IPR Statement 
Date: Tue, 22 May 2001 09:08:01 -0400
Sender: [email-masked]

-02 document updates should happen in the next two weeks.  I still need to
confirm schema changes with updated XML parsers that support the W3C's May
2001 XML Schema Recommendation.  Xerces-J 1.4.0 is supposed to be released
today; once I have proper tools to confirm the validity of schema updates
the writing will be completed ASAP.

<Scott/>

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Tuesday, May 22, 2001 8:23 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]'; [email-masked]
>Subject: Re: VeriSign EPP IPR Statement 
>
>
>Thank you Scott, Verisign, and the Secretariat.
>
>Please post our recent work, reflected in your draft -02 
>documents, to the
>provreg list, as soon as any remaining editorial issues are resolved.
>
>Eric
>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: VeriSign EPP IPR Statement 
Date: Tue, 22 May 2001 08:22:31 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Thank you Scott, Verisign, and the Secretariat.

Please post our recent work, reflected in your draft -02 documents, to the
provreg list, as soon as any remaining editorial issues are resolved.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: VeriSign EPP IPR Statement
Date: Tue, 22 May 2001 07:18:40 -0400
Sender: [email-masked]

Yesterday I sent the IETF Secretariat an attorney-blessed IPR statement
describing VeriSign's lack of IPR claims for EPP.  It's now visible here:

http://www.ietf.org/ietf/IPR/VERISIGN-EPP

<Scott/>

To: [email-masked]
cc: [email-masked]
Subject: Re: Epp - Contacts 
Date: Thu, 17 May 2001 07:59:08 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ross,

I appreciate that there are registrars, and there are registrars. Some will
insist upon a unique end-point identifier for <insert communication layer>,
for <insert reason>, some will not. The same applies to registries. It is
a business, not a protocol design, decision, which entities will or won't
proffer or accept multiple instances of contact data.

How difficult is multiple, ordered, instances of end-point identifiers for
<insert communication layer> operationally? That depends on the operational
requirement, neh?

	- if for "validation" (lowest cost to assert opt-in to some policy,
	  or discard), then unique beats non-unique, though none has some
	  advantages over unique,

	- if for "contact" (discard avoidance communication set-up), then
	  unique constrains registrants to "address transparency" [1], and
	  violates the principle of informed consent to bind registrants
	  to registry policy.

If the point isn't to "contact" the registrant, but to "validate", then the
change required is renaming the draft from "contact" to "validate", and to
make the corresponding changes to the text of the draft.

If it is contact, then it is a business decision how sloppy anyone in the
provreg chain gets, and who deals with marginal or simply bizarre middlemen
or the odd registry.

It is commic that ISP failures, or area code renumbering, or "forwarding"
offered by postal system, should have MANDITORY TO IMPLEMENT contact data
invalidation semantics.

The handwaving was nice, and I especially enjoyed the bit about subtle thin
lines and etiquette, but try to address the protocol problem:

	is there a case for uniqueness? (clearly there is for finiteness)
	if so, offer it. if not, then the upper limit on multiple instances
	of foo is tbd, by working group process.

The issue I see as controlling is the use case -- upon policy condition,
e.g., legal requirement in some jusrisdiction, operator must perform bulk
contact. For every thousand {s-mail,e-mail,voice,fax} items sent there are
returns. A brain-dead "protocol" requirement that no alternate address can
exist means the operator must terminate or otherwise modify service to the
registrant, pursuant to the original policy condition.

This imports all the marginal service already available to data and postal
carrier customers into the DNS, making name resolution less reliable, for
reasons entirely external to the catanet model.

The second controlling use case is a truely authenticating end-point
identifier, which may have little semblance to the ordinary contact
end-point identifier, resembling more the legally required agent for
a corporation. In this case the (brain-dead "protocol") uniqueness
requirement prevents registrants from providing authenticating contact
addresses, similar to the pgp public key servers, or other means to
authenticate, though not necessarily to directly communicate with, a
registrant.

Eric

[1]	a "service" offered by carriers, also a form of denial of service.

P.S.	NeuLevel may drop Tucows tickets in the bit-bucket for reasons other
	than marginal quality, which would solve your problem, neh?

From: "Ross Wm. Rader" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Epp - Contacts 
Date: Thu, 17 May 2001 01:56:36 -0400
Sender: [email-masked]

> could you provide a use case for the utility of many addresses. If
> registrars use these addresses for verification shich one should be chosen
> so send corispondance if they all have an equal weight.

If my perception of Rick's implication is correct, I think I agree ;)

As a registrar, I need one authoritative address, not 1 or 3 or 7 or 2
(depending on philosophy ;) maybe addresses...

In my mind, this request seems to cross the subtle, thin line between
technical requisites and social niceties. While I completely appreciate your
etiquette, it appears, at first blush, to make my life hellish from a
registrar operations POV.

In other words, this appears to be dealt with easily by a) the application
or b) registrant responsibility - but certainly not the protocol.

-rwr

To: Rick H Wesson <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Damaraju, Ayesha'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Epp - Contacts 
Date: Wed, 16 May 2001 19:55:58 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Rick,

> could you provide a use case for the utility of many addresses

Sure. From about two hours ago ...

: I'd like to give my telephone number (which doubles as a fax), but in case
: I'm not in, I'd like my answering service (paid professional) to pick up,
: and I don't want my local "Intelligent Network" to do call forwarding, as
: that is insufficiently deterministic (to put it mildly).
: 
: So, there's the motivation. The ordering is (reverse of the surprising postal
: bottom-up reading) order of incidence (which places a no-reordering on second
: and subsequent element list members requirment). Repeat for fax, my answering
: service (lady down the street) got the same model I did (I bought it for her
: as partial payment for professional services).
: 
: I've a lot of email addresses, the one I'm using today is subject to the
: whims of a DSL vendor (now that's chancy, neh?), and if the wire or the host
: goes south, my primary alternate is pretty damn stable (world.std.com), but
: I could have used a TimeWarnerAOL dhcp'd and mailbox hosted bit-bucket, and
: that too can vanish (like a DSL vendor) without even a .vacation forwarder.
: 
: So, there's the motivation. The ordering is (reverse of the surprising postal
: bottom-up reading) order of incidence (which places a no-reordering ...).

In the same vein, I've a three-season address (in Maine) and a winter address
(in Florida), or I may when my blood thins. But I'll probably pick Cuba, and
the postal service won't a) spring for the international postage to forward
my mail, or b) send a kleenex to the commies. Again, "public infrastructure"
is less deterministic than the registrant's express preference, and without
a secondary a registrant is forced to deal with a "unique, not necessarily
functional" address.

> If
> registrars use these addresses for verification shich one should be chosen
> so send corispondance if they all have an equal weight.

We're going to use them all if attempting to reach the registrant. The point
of the contact info isn't to have something that doesn't work, it is to have
something that does work, and it hasn't (yet) if we haven't reached them (and
we really want to).

"we" here is .biz

Keep in mind the construction in Scott's present draft -- a registrant MUST
NOT offer (or a registrar MUST NOT accept, or at least MUST NOT try to fob
off on the registry) a secondary {postal address, voice number, fax number,
email addr, ... }. As a registry operator I don't win by having a (large)
fraction of my registrants unreachable. I don't imagine that the unreachable
or uncomforably constrained-to-unique-[post,voice,fax,email]-address are big
winners either.

I'm the agent of record for the Anansaguntacook Corporation. Maine law
requires corporations to have addressable agents, in addition to any random
address the corporation may use from time to time.

Thanks for asking,
Eric

Date: Wed, 16 May 2001 16:05:22 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Damaraju, Ayesha'" <[email-masked]>, <[email-masked]>
Subject: Re: Epp - Contacts 
Sender: [email-masked]

eric,

could you provide a use case for the utility of many addresses. If
registrars use these addresses for verification shich one should be chosen
so send corispondance if they all have an equal weight.

thanks,

-rick

On Wed, 16 May 2001, Eric Brunner-Williams in Portland Maine wrote:

> Will, that's an improvement over insisting on a rational for any number
> other than one. Lacking a counter (and I'm in no unseemly haste) we're
> just dickering over which small int to elect.
>
> Eric
>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "'Damaraju, Ayesha'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Epp - Contacts 
Date: Wed, 16 May 2001 18:56:19 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Will, that's an improvement over insisting on a rational for any number
other than one. Lacking a counter (and I'm in no unseemly haste) we're
just dickering over which small int to elect.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "'Damaraju, Ayesha'" <[email-masked]>, [email-masked]
Subject: RE: Epp - Contacts 
Date: Wed, 16 May 2001 18:40:21 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2001 6:02 PM
> To: Hollenbeck, Scott
> Cc: 'Eric Brunner-Williams in Portland Maine'; 'Damaraju, Ayesha';
> [email-masked]; [email-masked]
> Subject: Re: Epp - Contacts 

[snip]

> Anyone got a case against? A case for necessity of 
> uniqueness? Impossiblity
> (or difficulty) of ordering? Lacking that, its just a matter of taste.

The only way I can define "its just a matter of taste" in XML Schema is by
not defining an upper bound on the number of elements.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "'Damaraju, Ayesha'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Epp - Contacts 
Date: Wed, 16 May 2001 18:01:53 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

As a mathematician, the distinction between "two" and "many" seems a bit
mystical, but the real issue here is non-uniqueness, ordering, necessity,
consequence, and then any (finite) number that makes consensus.

What's your favorite number between 1 and card(integers)?

I'm partial to 4, though 7 works for me too. Dualists usually go for 2.
Christians for 3. ...  and cognitive types remind us that 7 is about as
much as a mind can hold.

The nice thing about integers is that there are so many to choose from.

What Ayesha was fishing for was a case against, not an assertion of
non-necessity, which we didn't apply to the first (and therefore simple,
elegant, unique, and potentially wrong) instance of numerous contact
elements.

Anyone got a case against? A case for necessity of uniqueness? Impossiblity
(or difficulty) of ordering? Lacking that, its just a matter of taste.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "'Damaraju, Ayesha'" <[email-masked]>, [email-masked]
Subject: RE: Epp - Contacts 
Date: Wed, 16 May 2001 17:34:32 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2001 5:13 PM
> To: Hollenbeck, Scott
> Cc: 'Damaraju, Ayesha'; [email-masked]; [email-masked]
> Subject: Re: Epp - Contacts 
> 

[snip]

> Unbounded seems kind of goofy, picking a bound is going to be 
> an exercise in
> engineering arbitrariness, and 1 is just as arbitrary as 2 or 
> 0, though the
> last has the same ordering properties as the first.

The problem, though, is that the protocol can't be ambiguous in this regard.
We have to specify one instance, a defined number of instances, or no upper
bound on the number of instances.  "multiple" doesn't narrow down the last
two options precisely enough.

<Scott/> 

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Damaraju, Ayesha'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Epp - Contacts 
Date: Wed, 16 May 2001 17:13:14 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

As Dave pointed out, there is ambiguity in <contact:addr>, and the order (read
from the bottom) of multiple PO Boxes, Private Bags, Rurual Routes, and Street
Addresses (as many as fit into a 6x30), is last one wins.

As is, in either version of draft-hollenbeck-epp-contact-* that I'm aware of,
we don't guarentee uniqueness, nor ordering, though finitness appears to come
dead cheap. With a little ingenuity at least two postal addrs could fit in a
6x30 (I've lived with a Rural Rte #, a Private Bag, and a PO Box, all at the
same offset from US 101 in S. Humbolt Co., CA US).

I'd like to give my telephone number (which doubles as a fax), but in case
I'm not in, I'd like my answering service (paid professional) to pick up,
and I don't want my local "Intelligent Network" to do call forwarding, as
that is insufficiently deterministic (to put it mildly).

So, there's the motivation. The ordering is (reverse of the surprising postal
bottom-up reading) order of incidence (which places a no-reordering on second
and subsequent element list members requirment). Repeat for fax, my answering
service (lady down the street) got the same model I did (I bought it for her
as partial payment for professional services).

I've a lot of email addresses, the one I'm using today is subject to the
whims of a DSL vendor (now that's chancy, neh?), and if the wire or the host
goes south, my primary alternate is pretty damn stable (world.std.com), but
I could have used a TimeWarnerAOL dhcp'd and mailbox hosted bit-bucket, and
that too can vanish (like a DSL vendor) without even a .vacation forwarder.

So, there's the motivation. The ordering is (reverse of the surprising postal
bottom-up reading) order of incidence (which places a no-reordering ...).

Unbounded seems kind of goofy, picking a bound is going to be an exercise in
engineering arbitrariness, and 1 is just as arbitrary as 2 or 0, though the
last has the same ordering properties as the first.

Cheers, Greetings, Regards, ...
Eric

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: <[email-masked]>
Subject: RE: WHOIS Terminology and draft-ietf-provreg-dn-defn-01.txt
Date: Wed, 16 May 2001 16:55:34 -0400
Importance: Normal
Sender: [email-masked]

>
> The last two lines make it clear that there is confusion about the term
> WHOIS. Making a terminology document would be the opportunity to clarify
> things.
>
> Since later down you introduce the terms 'Registry and Registrar
> Whois', we
> have two terms for the service part. We could then restrict the meaning of
> 'Whois' to the TCP based query/response protocol.
> Maybe 'Registrar Whois Service' is a better description and the meaning
> more obvious?

Well taken. Would it perhaps make more sense to keep the definition of
"Whois" as it currently stands but add "Whois Service" and "Whois Protocol"
in addition? Part of my goal with this document is to "bridge the gap"
between those that know better and those that don't. The term "SLD Holder"
is a great example of a legally concise word that has found it's way into
our lexicon but holds no meaning for 99% of the rest of the world who have
latched onto the terms "registrant", "domain holder" or "domain owner".

>
> Often the term 'Whois Database' is heared. I'm happy that you do not have
> it in your list, because it makes no sense.  ;-)

This is DNS, none of it makes sense. ;)

-rwr

Date: Wed, 16 May 2001 15:03:54 +0300
From: Urs Eppenberger <[email-masked]>
To: [email-masked]
Subject: WHOIS Terminology and draft-ietf-provreg-dn-defn-01.txt
Sender: [email-masked]

Clarifying terminology in our area is very helpful. Just consider the
thin/fat registry discussions.

> Whois: a TCP transaction based query/response server, that providing 
> netwide directory service to network users. The Whois Protocol was 
> originally defined in RFC 954. The initial domain name related 
> application layer implementations were centralized systems run by 
> SRC-NIC and then later InterNIC/Network Solutions. The SRI-NIC and 
> InterNIC implementations are more formally referred to as 
> "NICNAME/Whois" services. Whois is not purely a domain name or IP 
> address directory service, but has been deployed for a wide variety 
> of uses, both public and private. Other variants of this service 
> include RWhois and the newer Verisign Referral LDAP Whois service. 
> Whois can refer to the protocol defined in RFC 954 or the generic 
> application service described above. 

The last two lines make it clear that there is confusion about the term
WHOIS. Making a terminology document would be the opportunity to clarify
things.

Since later down you introduce the terms 'Registry and Registrar Whois', we
have two terms for the service part. We could then restrict the meaning of
'Whois' to the TCP based query/response protocol.
Maybe 'Registrar Whois Service' is a better description and the meaning
more obvious?

Often the term 'Whois Database' is heared. I'm happy that you do not have
it in your list, because it makes no sense.  ;-)

Kind regards,

Urs.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Damaraju, Ayesha'" <[email-masked]>, [email-masked]
Subject: RE: Epp - Contacts
Date: Wed, 16 May 2001 15:21:10 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Damaraju, Ayesha [mailto:[email-masked]]
>Sent: Wednesday, May 16, 2001 2:59 PM
>To: [email-masked]
>Subject: Epp - Contacts
>
>
>
>I like to propose multiple voice, fax and email elements for
>Epp-contact object.
>
>I appreciate your feedback.

Rationale, please?  By "multiple" do you just mean "more than one with a
fixed upper bound", or "unbounded"?  Does there need to be some semblance of
priority among the multiple values?

<Scott/>

From: "Damaraju, Ayesha" <[email-masked]>
To: [email-masked]
Subject: Epp - Contacts
Date: Wed, 16 May 2001 13:59:12 -0500
Sender: [email-masked]

I like to propose multiple voice, fax and email elements for
Epp-contact object.

I appreciate your feedback.
Thanks
-A

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Edward Lewis" <[email-masked]>, <[email-masked]>
Subject: RE: It's been quiet recently
Date: Wed, 16 May 2001 13:48:24 -0400
Importance: Normal
Sender: [email-masked]

> Since then we have been rather quiet.  I noticed that ICANN made news with
> regards to .info and .biz, so it is evident that something is happening in
> the registration world.

Which I suspect is a big contributor to the quietude. I can't speak for any
of the other participants, but all of our warm bodies have either been
writing, checking or deploying code like mad for the last 30 days. All of
our technically oriented public interactions have suffered.

> My question: is there still a need to speed our work?  If so, why the
> silence?  Is the group meeting (or not) meeting the objectives of the
> participants?

>From our standpoint, it's preferable that the WG remain engaged in
deliberate work. We've seen enough work product come out of this group to
actually produce an application. Our challenge is to now make sure that the
application remains in sync with provreg output. Doing so will be much
easier if we are dealing with deliberate effort regardless of frequency or
velocity.

> As far as the remaining EPP documents, I propose that they be
> accepted into
> the WG.

Concur.

We also look forward to the statements of context you've requested.

-rwr

Reply-To: "Christopher Ambler" <[email-masked]>
From: "Christopher Ambler" <[email-masked]>
To: <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>
Subject: Re: It's been quiet recently
Date: Wed, 16 May 2001 09:47:19 -0700
Organization: Image Online Design, Inc.
Sender: [email-masked]

I've been waiting for the promised cooperation in implementation details
and testbeds. To date, there's been nothing but silence.

I didn't expect otherwise. Nothing changes.

Christopher

----- Original Message ----- 
From: "Edward Lewis" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 16, 2001 8:14 AM
Subject: It's been quiet recently

> About two weeks ago, I sent a message concerning our status.  The archive
> URL for it is
> http://www.cafax.se/ietf-provreg/maillist/2001-05/msg00013.html.  Since
> then, the requirements document has been forwarded to the AD's.  I've
> received no feedback.
> 
> Since then we have been rather quiet.  I noticed that ICANN made news with
> regards to .info and .biz, so it is evident that something is happening in
> the registration world. 

Date: Wed, 16 May 2001 11:14:49 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: It's been quiet recently
Cc: [email-masked]
Sender: [email-masked]

About two weeks ago, I sent a message concerning our status.  The archive
URL for it is
http://www.cafax.se/ietf-provreg/maillist/2001-05/msg00013.html.  Since
then, the requirements document has been forwarded to the AD's.  I've
received no feedback.

Since then we have been rather quiet.  I noticed that ICANN made news with
regards to .info and .biz, so it is evident that something is happening in
the registration world.  Early in our process, comments were made that our
group needed to work quickly to have something in place, principly before
the ICANN seven new gTLD's were set up.

My question: is there still a need to speed our work?  If so, why the
silence?  Is the group meeting (or not) meeting the objectives of the
participants?

Now, turning to documents...

I (Jaap too) have heard no outside comments on the drafts in the previous
message.  We are waiting on an update to Eric's draft before it will be
considered for WG status.  I don't know where James & William's draft
stands.

I have asked both groups to clarify - in text - the context of their
documents.  I think that will help the group justify adopting further
documents.

As far as the remaining EPP documents, I propose that they be accepted into
the WG.  Further, an assignment to write an "EPP on BEEP" has been made
(Dave Crocker) and a request for someone to write a "EPP on Email/SMTP" has
been made.    The EPP on BEEP will become a WG draft, as will the latter if
it ever happens.

Finally, is there a reason to continue the design teams?  Are they adding
value?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-dn-defn-01.txt
Date: Tue, 15 May 2001 07:02:04 -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		: Domain Name and Related Definitions
	Author(s)	: R. Rader
	Filename	: draft-ietf-provreg-dn-defn-01.txt
	Pages		: 8
	Date		: 14-May-01
	
Efforts are currently being undertaken to define and formalize 
registry/registrar communications protocols in light of the current 
and evolving scope and utility of DNS, domain name registries and 
related entities. In order for this work to be truly effective and 
broadly applicable, it is important that accepted definitions act as 
the foundation. This document is an attempt to create a starting 
point for the requisite dialogue that will ultimately foster the 
determination and acceptance of these new protocols. This document 
obsoletes <draft-rader-dnwhois-defn-00.txt>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-dn-defn-01.txt

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-dn-defn-01.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-dn-defn-01.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-dn-defn-01.txt

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

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

--OtherAccess--

--NextPart--

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Dave Crocker'" <[email-masked]>, Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: RE: Mapping EPP onto SMTP?
Date: Fri, 4 May 2001 07:07:40 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Dave Crocker [mailto:[email-masked]]
>Sent: Friday, May 04, 2001 12:16 AM
>To: Edward Lewis
>Cc: [email-masked]
>Subject: Re: Mapping EPP onto SMTP?
>
>
>I presume that the query is about mapping EPP to work over 
>Internet Mail, not specifically or directly over SMTP?
>
>That is, I presume that the task is to define appropriate MIME objects and 
>RFC822 -- oops, RFC 2822 -- addresses?  That way the EPP requests and 
>responses travel as regular email.
>
>If you any other sort of thing in mind, please explain what.  
>And please carefully explain why.
>
>Thanks.
>
>d/
>
>
>At 09:16 AM 5/3/2001, Edward Lewis wrote:
>>Does anyone want to volunteer to edit a draft on mapping EPP onto SMTP?
>>There is already a (as yet still non-WG) draft mapping EPP onto TCP, and a
>>mapping onto BEEP has been informally volunteered to...

Correct presumption, at least it's what I meant (but not what I actually
wrote) when I asked Ed and Jaap to consider the need for such a draft.

<Scott/>

Date: Thu, 03 May 2001 21:15:33 -0700
To: Edward Lewis <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Mapping EPP onto SMTP?
Cc: [email-masked]
Sender: [email-masked]

I presume that the query is about mapping EPP to work over Internet Mail, 
not specifically or directly over SMTP?

That is, I presume that the task is to define appropriate MIME objects and 
RFC822 -- oops, RFC 2822 -- addresses?  That way the EPP requests and 
responses travel as regular email.

If you any other sort of thing in mind, please explain what.  And please 
carefully explain why.

Thanks.

d/

At 09:16 AM 5/3/2001, Edward Lewis wrote:
>Does anyone want to volunteer to edit a draft on mapping EPP onto SMTP?
>There is already a (as yet still non-WG) draft mapping EPP onto TCP, and a
>mapping onto BEEP has been informally volunteered to...

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: Mapping EPP onto SMTP?
Date: Thu, 3 May 2001 18:56:46 -0400 
Sender: [email-masked]

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 12:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Mapping EPP onto SMTP?
> 
> 
> Does anyone want to volunteer to edit a draft on mapping EPP 
> onto SMTP?
> There is already a (as yet still non-WG) draft mapping EPP 
> onto TCP, and a
> mapping onto BEEP has been informally volunteered to...

I would like to see someone else do it, but I'll do it if no one else
volunteers.

<Scott/>

Date: Thu, 3 May 2001 12:16:01 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Mapping EPP onto SMTP?
Cc: [email-masked]
Sender: [email-masked]

Does anyone want to volunteer to edit a draft on mapping EPP onto SMTP?
There is already a (as yet still non-WG) draft mapping EPP onto TCP, and a
mapping onto BEEP has been informally volunteered to...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 3 May 2001 10:56:45 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Movement on the Requirements Document
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At the close of the last call period, there were two remaining unresolved
issues, unresolved in the sense that there was at least one person unhappy
with some text in the requirements document.  Note that consensus does not
mean unanimity, but we do like to see everyone be happy.

The two open issues are:

Whether or not the protocol is to reveal "abstract object relationships."
In our opinion, this (albeit desireable) feature would present a
significant amount of feature creep into our current efforts.   We propose
to let the draft stand as is on this topic.

Whether or not the protocol assumes name servers are linked to their
domains.  It seems wise to accept the restrictive model as proposed,
because of the downside of "orphaned records" when domains are pulled.

The WG chairs, following an update from the author[1], will send the draft
(without another last call to this working group) to the IESG.

We don't see there being a huge amount of controversy with this
requirements document.  Those that feel strongly enough can issue comments
during the IESG last call, but for now the WG chairs feel it is time to
move this document on and get to the matter of defining the protocol.

[1] Which has happened while the chairs were sync'ing on the words here...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

To: Edward Lewis <[email-masked]>
From: [email-masked], "P.E." <[email-masked]>
Subject: RE: VeriSign Patents on Registries/Registrars and other readings
Reply-To: [email-masked]
CC: [email-masked], [email-masked]
Date: Wed, 2 May 2001 08:07:59 -0700
Sender: [email-masked]

Dear All

Filing for a patent does not mean it is approved at all.

If anyone feels that the patent has problems then they should contense 
granting it by submitting sufficient evidence to back up their arguments 
against granting the patent.

Asaad Y. Alnajjar, P.E.
CEO Millennium Inc.
[email-masked]

At Wednesday, 2 May 2001, Edward Lewis <[email-masked]> wrote:

>This thread hasn't been a nuisance yet, but I'd like to take this 
time to
>ask folks to hold off on comments in this area.  Let's avoid rumors and
>innuendo on topics that are best left to other experts (specifically
>lawyers).
>
>As this is not an engineering issue, let's wait and see if we are 
informed
>that we need to pay attention to this.  I don't mind the reporting 
of the
>filings, but let's not draw conclusions from scant facts.
>
>On a side note - Verisign is a large organization.  Scott is just one
>employee, don't expect him to speak for the company as a whole. 
In fact,
>he is probably barred from doing so - as am I for my company, and 
probably
>the same for a lot of others on this list also.
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                                NAI Labs
>Phone: +1 443-259-2352                      Email: [email-masked]
>
>You fly too often when ... the airport taxi is on speed-dial.
>
>Opinions expressed are property of my evil twin, not my employer.
>

PRIVACY POLICY  http://www.Millennium-Inc.ORG/privacypolicy.htm

Date: Wed, 2 May 2001 10:59:57 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Where are we?
Cc: [email-masked]
Sender: [email-masked]

It's been a bit quiet, so I thought I should let the group know what is up.

1) The requirements document is being prepared for the next leg of its
journey.  Jaap and I have been trying to coordinate a response to the
group, but because of our separation (1 ocean, 6 time zones) and other
travel black outs, we haven't "gotten the job done."  You should see
something on this soon, and some document movement - at the latest next
week when he and I get together in person.

2) Design teams?  Are they working?  I haven't heard anything in a few
weeks.  We may have to reshape the teams, given the set of documents below.

3) The next set of documents to focus on are protocol specifications.
Besides the already adopted EPP document there are a few other documents
I'd like to group to consider.  We eventually will need to decide whether
to adopt them into the WG, or let them sit outside.

The candidate documents include:

James Seng's offering:
     http://www.ietf.org/internet-drafts/draft-jseng-provreg-opp-00.txt

Eric Brunner-Williams' current offerring (I believe this is under edit):
     http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt
(a -01 is due soon)

A document found by an alert reader (Urs Eppenberger):
     http://www.ietf.org/internet-drafts/draft-newton-xdap-domdir-00.txt
(Note that this hasn't been proposed by the author for this group, but it
may have some bearing on the rest of our work.)

And finally, the remaining EPP documents:
    http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-contact-01.txt
    http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-domain-01.txt
    http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-host-01.txt
    http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-tcp-01.txt

And, even more finally ;), there are plans for an -epp-beep in the works.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

Date: Wed, 2 May 2001 10:30:55 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: VeriSign Patents on Registries/Registrars and other readings
Cc: [email-masked]
Sender: [email-masked]

This thread hasn't been a nuisance yet, but I'd like to take this time to
ask folks to hold off on comments in this area.  Let's avoid rumors and
innuendo on topics that are best left to other experts (specifically
lawyers).

As this is not an engineering issue, let's wait and see if we are informed
that we need to pay attention to this.  I don't mind the reporting of the
filings, but let's not draw conclusions from scant facts.

On a side note - Verisign is a large organization.  Scott is just one
employee, don't expect him to speak for the company as a whole.  In fact,
he is probably barred from doing so - as am I for my company, and probably
the same for a lot of others on this list also.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Date: Wed, 2 May 2001 08:07:06 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]
>Sent: Tuesday, May 01, 2001 9:20 PM
>To: [email-masked]
>Subject: RE: VeriSign Patents on Registries/Registrars and other
>readings 
>
>
>
>> > There is no bad faith at work here at all.  If you took 
>the time to read the
>> > applications, you would find that they refer to work 
>originally performed
>> > 2-3 years ago related to the current NSI SRS, or they are 
>registrar business
>> > mechanisms, all of which WAS done "in-house entirely with 
>their own clue".
>> > They have NOTHING to do with ANY of the work being 
>performed in this WG.
>
>Scott,
>don't you think that those business mechanisms are so
>natural that there is no newness (great innovation) in it?
>Why patent things that are obvious?
>Don't you think that it is a bad faith?
>
>I like public domain: for the benefit of people.
>People who drive this deserve our respect.
>
>Now, would any of what we are doing (or planning on doing)
>here create a problem for us? (not "respecting" NSI patents?)

I'm not going to debate the merits or detriments of patents.  Each of the
drafts I've written are in full conformance with all provisions of Section
10 of RFC2026, and I continue to claim that there are NO VeriSign or NSI
patent issues that will impede the chartered work of this WG.  Whether or
not the applications have an impact on building registries or registrars is
another matter, and I don't believe that matter is an issue for the WG.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: XML Schema becomes a W3C Recommendation
Date: Wed, 2 May 2001 06:50:59 -0400 
Sender: [email-masked]

FYI.  No we just have to wait for the tools to catch up.

<Scott/>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 1:48 AM
To: XML Developers List; [email-masked]
Subject: XML Schema becomes a W3C Recommendation

Tim Berners-Lee announced the decision in his keynote this morning in
his keynote at WWW10 in Hong Kong.

See the RECs (Primer [1], Structures [2], Datatypes [3]), the press
release [4] and the testimonials [5].

ht

[1] http://www.w3.org/TR/xmlschema-0/
[2] http://www.w3.org/TR/xmlschema-1/
[3] http://www.w3.org/TR/xmlschema-2/
[4] http://www.w3.org/2001/05/xml-schema-pressrelease
[5] http://www.w3.org/2001/05/xml-schema-testimonial
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: [email-masked]
		     URL: http://www.ltg.ed.ac.uk/~ht/

Date: Wed, 2 May 2001 11:48:17 +0900 (JST)
From: Peter Chow <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Sender: [email-masked]

On Wed, 2 May 2001 [email-masked] wrote:

> don't you think that those business mechanisms are so
> natural that there is no newness (great innovation) in it?
> Why patent things that are obvious?

Hindsight is obvious, but would we have designed it the same way
if given no precedent and a clean slate?

--------------------------------------------------------------------
_/_/_/ Peter Chow		Chief Technical Advisor
_/_/_/ [email-masked]	Global Media Online Inc.
_/_/_/				System Division
_/_/_/ ICQ: 41931890		Shibuya Cerulean Tower 10F
_/_/_/ (tel)+81-3-5456-2555	26-1 Sakuragaoka-cho, Shibuya-ku
_/_/_/ (fax)+81-3-5456-2740	Tokyo, Japan
_/_/_/ http://www.gmo.co.jp/	150-8512
--------------------------------------------------------------------

From: [email-masked]
To: <[email-masked]>
Date: Wed, 2 May 2001 08:19:42 +0700
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Sender: [email-masked]

> > There is no bad faith at work here at all.  If you took the time to read the
> > applications, you would find that they refer to work originally performed
> > 2-3 years ago related to the current NSI SRS, or they are registrar business
> > mechanisms, all of which WAS done "in-house entirely with their own clue".
> > They have NOTHING to do with ANY of the work being performed in this WG.

Scott,
don't you think that those business mechanisms are so
natural that there is no newness (great innovation) in it?
Why patent things that are obvious?
Don't you think that it is a bad faith?

I like public domain: for the benefit of people.
People who drive this deserve our respect.

Now, would any of what we are doing (or planning on doing)
here create a problem for us? (not "respecting" NSI patents?)

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Date: Tue, 1 May 2001 13:06:26 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Rick H Wesson [mailto:[email-masked]]
>Sent: Tuesday, May 01, 2001 12:37 PM
>To: Hollenbeck, Scott
>Cc: 'Peter Mott'; [email-masked]
>Subject: RE: VeriSign Patents on Registries/Registrars and other
>readings 
>
>
>
>Scott,
>
>
>> There is no bad faith at work here at all.  If you took the time to read
the
>> applications, you would find that they refer to work originally performed
>> 2-3 years ago related to the current NSI SRS, or they are registrar
business
>> mechanisms, all of which WAS done "in-house entirely with their own
clue".
>> They have NOTHING to do with ANY of the work being performed in this WG.
>
>
>All I had access to were the abstract, could you post refrences to the
>full application?

Not really, I certainly don't have them handy.  However, using the same
search mechanism you cited I followed links on one of the examples to a
"View Images" button that led me to a PDF file containing a copy of an
application:

http://l2.espacenet.com/dips/bnsviewer?CY=wo&LG=en&DB=EPD&PN=0065511&ID=WO++
+0065511A2+I+

I assume the other applications are available using similar searches.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Karl Auerbach'" <[email-masked]>
Cc: [email-masked]
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Date: Tue, 1 May 2001 13:06:06 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Karl Auerbach [mailto:[email-masked]]
>Sent: Tuesday, May 01, 2001 12:28 PM
>To: Hollenbeck, Scott
>Cc: 'Peter Mott'; Rick H Wesson; [email-masked]
>Subject: RE: VeriSign Patents on Registries/Registrars and other
>readings 
>
>
>
>> There is no bad faith at work here at all.  If you took the time to read
the
>> applications, you would find that they refer to work originally performed
>> 2-3 years ago related to the current NSI SRS, or they are registrar
business
>> mechanisms, all of which WAS done "in-house entirely with their own
clue".
>> They have NOTHING to do with ANY of the work being performed in this WG.
>
>Is VRSN willing to issue an irrevocable waiver, enforceable by anyone, of
>any coverage of these patents, worldwide, beyond *the* SRS?

I'll know how to answer that question after I receive a return phone call
from one of our patent attorneys.

<Scott/>

Date: Tue, 01 May 2001 12:55:45 -0400
From: Jordan Glogau <[email-masked]>
Subject: Re: VeriSign Patents on Registries/Registrars and other readings
To: Rick H Wesson <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, "'Peter Mott'" <[email-masked]>, [email-masked]
Sender: [email-masked]

All:

Yes, the abstract is OK but the full application would be helpful. 
Internet business patents tend to be process patents.  Normally there is
more then one way to do the same thing.  If Verisign does things in
A-B-C-D-E order then your company can legally do things in A-B-C-F-E
order (highly over simplified explanation).

Jordan Glogau

Rick H Wesson wrote:
> 
> Scott,
> 
> > There is no bad faith at work here at all.  If you took the time to read the
> > applications, you would find that they refer to work originally performed
> > 2-3 years ago related to the current NSI SRS, or they are registrar business
> > mechanisms, all of which WAS done "in-house entirely with their own clue".
> > They have NOTHING to do with ANY of the work being performed in this WG.
> 
> All I had access to were the abstract, could you post refrences to the
> full application?
> 
> thanks,
> 
> -rick

Date: Tue, 1 May 2001 09:37:28 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Peter Mott'" <[email-masked]>, <[email-masked]>
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Sender: [email-masked]

Scott,

> There is no bad faith at work here at all.  If you took the time to read the
> applications, you would find that they refer to work originally performed
> 2-3 years ago related to the current NSI SRS, or they are registrar business
> mechanisms, all of which WAS done "in-house entirely with their own clue".
> They have NOTHING to do with ANY of the work being performed in this WG.

All I had access to were the abstract, could you post refrences to the
full application?

thanks,

-rick

Date: Tue, 1 May 2001 09:28:20 -0700 (PDT)
From: Karl Auerbach <[email-masked]>
Reply-To: Karl Auerbach <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Peter Mott'" <[email-masked]>, Rick H Wesson <[email-masked]>, <[email-masked]>
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Sender: [email-masked]

> There is no bad faith at work here at all.  If you took the time to read the
> applications, you would find that they refer to work originally performed
> 2-3 years ago related to the current NSI SRS, or they are registrar business
> mechanisms, all of which WAS done "in-house entirely with their own clue".
> They have NOTHING to do with ANY of the work being performed in this WG.

Is VRSN willing to issue an irrevocable waiver, enforceable by anyone, of
any coverage of these patents, worldwide, beyond *the* SRS?

		--karl--

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Peter Mott'" <[email-masked]>, Rick H Wesson <[email-masked]>, [email-masked]
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Date: Tue, 1 May 2001 07:06:35 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Peter Mott [mailto:[email-masked]]
>Sent: Monday, April 30, 2001 7:12 PM
>To: Rick H Wesson; [email-masked]
>Subject: RE: VeriSign Patents on Registries/Registrars and other
>readings 
>
>
>> below are some patents that Verisign has applied for, I thought some of
>> you may be interested in these applications as they may impact some of
>> your businesses if granted.
>
>Such applications demonstrate considerable bad faith on the part of
>Verisign.  It would be ok if the 'inventions' were created in-house
entirely
>with their own clue.
>
>Verisign's big business attempt to patent stuff created using new world
>co-operative effort by small business, individuals and academics is nothing
>less than evil.

There is no bad faith at work here at all.  If you took the time to read the
applications, you would find that they refer to work originally performed
2-3 years ago related to the current NSI SRS, or they are registrar business
mechanisms, all of which WAS done "in-house entirely with their own clue".
They have NOTHING to do with ANY of the work being performed in this WG.

<Scott/>

From: "Peter Mott" <[email-masked]>
To: "Rick H Wesson" <[email-masked]>, <[email-masked]>
Subject: RE: VeriSign Patents on Registries/Registrars and other readings 
Date: Tue, 1 May 2001 11:12:02 +1200
Importance: Normal
Sender: [email-masked]

> below are some patents that Verisign has applied for, I thought some of
> you may be interested in these applications as they may impact some of
> your businesses if granted.

Such applications demonstrate considerable bad faith on the part of
Verisign.  It would be ok if the 'inventions' were created in-house entirely
with their own clue.

Verisign's big business attempt to patent stuff created using new world
co-operative effort by small business, individuals and academics is nothing
less than evil.

Peter Mott
Chief Enthusiast
2day.com
-/-

From: [email-masked]
To: "[email-masked]'" <[email-masked]>
Date: Tue, 1 May 2001 05:50:32 +0700
Subject: Re: VeriSign Patents on Registries/Registrars and other readings 
Sender: [email-masked]

I don't understand why people are so trigger-happy
to patent things :-(

Why can't we make all of this *public domain*, for
the benefit of people all over the world (and perhaps
for people out of this world too ;-) ?

-- budi
--
Homepage: <http://budi.insan.co.id>
my presentation materials, papers, scrapbook, ... and more
What's your "web.id"? Register your web.id @ http://www.idnic.net.id